Announcing Self-Hosted Expanso on Native Kubernetes

We just finished re-architecting Expanso Cloud from the ground up. It now runs on Kubernetes with a cell-based architecture, custom operators, and orchestrator provisioning that takes under ten seconds.

And we’re packaging the whole thing for self-hosted deployment.

Why this matters

If you’ve been using Expanso Cloud as a managed service, you already know the orchestrator never touches your data - it’s purely a coordination layer that tells your Edge nodes what to run and where. Your data stays on your hardware.

But for some organizations, that’s not enough. If you’re in a regulated industry, operating in air-gapped environments, or have data sovereignty requirements that extend to the control plane itself - you need everything running inside your perimeter.

We’ve heard this from enough customers that we decided to solve it properly. Not by building a separate “enterprise edition” that drifts from the managed product, but by making our actual production infrastructure portable.

What we’re shipping

The self-hosted deployment is the same Kubernetes stack that runs Expanso Cloud today:

• A custom operator that provisions and manages orchestrator instances through a CRD called ExpansoCloudNetworkInstance. It handles the full lifecycle - creation, updates, health checks, teardown - using the same level-triggered reconciliation that keeps our managed cells running.

• Helm charts - the same ones we deploy to our own cells. Not a fork, not a simplified version. The same charts.

• Cell-based isolation - each orchestrator gets its own namespace, service accounts, secrets, and network routing. Multiple teams can share a cluster without stepping on each other.

• Direct connectivity - your Edge nodes talk to the orchestrator over NATS with no intermediate routing layer. CLI and API access goes straight to your cluster’s ingress.

What didn’t change

Everything about how Expanso works stays the same. Edge nodes still run on your hardware, still process data locally, still connect inbound to the orchestrator. You still deploy logging pipelines, data extraction jobs, and fleet management the same way - through the orchestrator’s API or the web UI.

The orchestrator still coordinates tens of thousands of Edge nodes per instance. It still handles versioning, rollouts, rollbacks, monitoring. It still never sees your data.

The only difference is where the orchestrator runs. Instead of our managed cells, it runs in yours.

We run what we ship

One thing we’re particular about: every developer at Expanso runs the full cell-based architecture locally. Not a mock, not a Docker Compose stand-in - the actual operator, the actual Helm charts, the actual provisioning flow. When we make changes to the platform, we test against the same topology that runs in production.

The Kubernetes environment we’re recommending for your self-hosted deployment is the one we develop against every day. When we find a bug or improve the operator, the fix goes to both managed and self-hosted in the same release.

What’s improved for everyone

The re-architecture also made managed Expanso Cloud better:

• Provisioning in under 10 seconds - spinning up a new orchestrator used to take minutes. The custom operator and cell architecture got that down to single-digit seconds.

• Cell isolation - problems in one cell don’t cascade to others. Each cell is self-sufficient once provisioned.

• Rolling updates - we can update hundreds of orchestrators across cells without coordinated downtime, and the same applies to your config changes.

• Direct-to-cell routing - no global proxy between you and your orchestrator. Our control plane can go down for maintenance and your running orchestrators don’t notice.

We wrote up the full technical details - the operator design, the controller that manages orchestrator lifecycles across cells, the direct-to-cell networking model - in a separate post.

Get started

If you’re already on Expanso Cloud, nothing changes for you unless you want it to. Managed is still fully supported and just got faster.

If self-hosted is what you need, book a demo and we’ll walk through the deployment model. We’re looking for design partners to work with on early self-hosted deployments - especially teams with strict compliance requirements or air-gapped environments where we can learn the most.

We’ll also be at KubeCon demoing the self-hosted deployment. Come find us.