For a lot of teams, "just send it to our cloud" is a non-starter. Banks, hospitals, defense contractors and anyone operating under data-residency rules can't ship session recordings and audit logs of their production access to a third party — no matter how good the encryption is. The data simply has to stay inside their boundary.
So when we designed Subnomic's control plane, self-hosting wasn't a checkbox bolted on at the end. It was a constraint from day one: the same product that runs as a managed service has to run, in full, inside a customer's own infrastructure.
What the control plane does
The control plane is the brain of the system. It brokers connections between operators and agents, enforces identity and RBAC policy, and stores the sensitive byproducts of access:
- Session recordings — the full terminal streams for replay.
- Audit logs — who connected to what, when, and under which grant.
- Metrics — the live and historical telemetry from every agent.
- Policy — the identity, host-group and access-rule configuration.
Every one of those is data a regulated customer needs to keep inside their own walls.
Designing for two deployment models
If self-hosting is an afterthought, it ships broken. We made it the same artifact.
The trap most vendors fall into is maintaining two products: a polished SaaS and a neglected "on-prem" fork that lags months behind. We refused to split the codebase. The managed service and the self-hosted deployment are the same artifact, configured differently.
- No hard dependency on managed cloud services. Storage, database and queue interfaces are pluggable, so they can point at the customer's own infrastructure instead of ours.
- Everything ships as containers. The whole control plane runs on a standard container platform — no bespoke installer, no snowflake VM.
- Configuration, not code, is the difference. The same binaries run in both modes; environment and config decide where data lands.
- Outbound agents work identically. Because agents dial out to a control plane, pointing them at a self-hosted one is just a different address.
Keeping the data boundary clean
In a self-hosted deployment, recordings, logs and metrics are written to storage the customer controls. Subnomic operates none of it and sees none of it. The control plane runs where the customer runs it, talks only to their agents, and persists only to their backends. The data boundary is theirs, end to end.
Upgrades without drift
The reason single-artifact matters most is upgrades. Because there's no fork, a self-hosted deployment gets the same releases as the managed service, on the same cadence. Customers pull the new images and roll them out on their own schedule — no special branch, no months of lag, no "that fix is SaaS-only."
Sovereignty without compromise
Self-hosting usually means trading features for control. We built the control plane so you don't have to: the same Zero Trust access, session recording and live observability, running entirely inside your infrastructure, with every sensitive byte under your control.
Want to evaluate a self-hosted deployment? Book a demo or join the waitlist.