Three-Plane Model
Status: PUBLIC_CONTRACT_DRAFT — The three-plane architecture is the core design decision that differentiates Zen Mesh from platforms where the SaaS service sits in the delivery path.
See Planes for the current architecture model including Edge Lite.
Why Three Planes?
Most webhook platforms put their SaaS service in the delivery path: Source → SaaS → Your Service. This creates latency, single points of failure, and privacy concerns (your event data flows through a third party).
Zen Mesh splits this into three independent planes:
| Plane | Responsibility | Failure Domain |
|---|---|---|
| Control Plane | Configuration, UI, policy, certificates | If down: no config changes, delivery continues |
| Data Plane | Event routing, retry, backpressure | If down: events queue until recovery |
| Edge Plane | Local delivery, secrets, adapters | If down: only affected edge plane stops receiving |
Control Plane (SaaS)
The control plane is what you see in the dashboard: create edge planes, configure endpoints and targets, manage delivery flows, view delivery logs.
It never sees your event payloads. The control plane handles enrollment and configuration only. Once an edge plane is enrolled and flows are configured, events flow directly through the data plane.
Data Plane
The data plane is the runtime delivery engine:
- zen-ingester receives events from external sources (Stripe, GitHub, etc.)
- zen-egress delivers events to targets
- zen-bridge handles internal data-plane routing
The data plane operates independently of the control plane. If the SaaS dashboard goes down, already-configured delivery continues uninterrupted.
Edge Plane
The edge plane runs in the customer environment:
- zen-agent handles enrollment, heartbeats, and configuration sync
- zen-egress (optional) delivers events to services in your private network
- zen-ingester (optional) receives events locally
- zen-lock manages secrets where applicable
The edge plane is the only component that has direct access to your private services. Everything else stays outside your network boundary.
Edge Plane variants:
- Kubernetes Edge Plane — runs on your Kubernetes cluster
- Edge Lite — lightweight non-Kubernetes runtime
Connection Model
Edge Plane → Control Plane: outbound only (HTTPS + mTLS)
Edge Plane → Data Plane: outbound only (HTTPS + mTLS)
Control Plane → Edge Plane: never initiates
Independence Guarantees
This is fundamentally different from platforms where the SaaS service is the delivery engine. In Zen Mesh, the SaaS is the control panel, not the delivery engine.
Related
Evidence
Don't just take our word for the architecture. Zen's public claims are mapped to machine-readable discovery, security posture, evidence, and non-claim surfaces. Narrative docs are not proof — use the links below to verify scope, maturity, and explicit non-claims.
- llms.txt — discovery index for agents and reviewers
- AI discovery registry — per-surface freshness (security vs capability inventory)
- Claim maturity — what is wired, tested, backlog, or not claimed
- Security primitives — primitive-level posture and boundaries
- Security gaps — visible backlog; gaps are not hidden as product claims
- Capability manifest — proof_status and evidence scope per capability
- Non-claims — what Zen Mesh does not claim
Claim boundaries: Integrity receipts are integrity / tamper evidence only — not authentication, encryption, or replay prevention. Idempotency helps detect and limit duplicates; it is not replay-proof delivery.