Five planes. One binary. A single pane on top.
Zedmos is deliberately small: the engine, a control socket, a log writer, and an identity pull. Everything you see on the UI is a view into this system — not a separate product with its own packet path.
What the admin sees vs what runs
The Console UI (or the Hub UI in SASE mode) is the only knob. Every module below it — NGFW, SD-WAN, SASE, and identity — shares the same engine binary and the same policy file.
One path, eight stages
Every subsystem, in one column
Ingress → shared-memory ring → flow cache → L7 inspection → TLS inspection → policy match → multi-action enforcement. Zero copy, per-core worker, 256-packet batches. Fully userspace, no kernel queue.
A UNIX socket accepts JSON commands — reload policies, swap feeds, change routes. HTTPS API for remote management, signed with the licence authority.
Events land on a single-producer shared-memory ring. A dedicated log writer delivers them to file, syslog, SQLite, and Elasticsearch sinks. A write-ahead log gives durability; adaptive sampling keeps priority traffic under backpressure.
AD DC agent, Microsoft Graph, and SCIM pull directory state into a local store. IP ↔ user ↔ device joins happen on the fast path at policy evaluation time.
Local event storage for single-site deployments, with a structured export pipeline for multi-site SIEM integration. Atomic writes across backends.
The hub backend manages the encrypted overlay mesh, pushes policy to hubs and spokes, aggregates SLA and health, and triggers atomic failover when the primary degrades.