The self-hosted spectrum: from BYOC to air-gapped
Self-hosted is the opposite of multi-tenant SaaS. Inside that, there is still a spectrum: BYOC on one end, air-gapped on the other.
In our research on B2B startups shipping self-hosted, more YC-backed companies are offering self-hosted deployment options. That is useful signal. It is also incomplete.
“We do self-hosted” does not tell you much until you know which kind.
Multi-tenant SaaS vs self-hosted
Multi-tenant SaaS means you run one cloud service that serves many customers. Their data and workloads live in your environment. You own uptime, upgrades and most of the security boundary. Customers get speed with less ops, but give up where the data lives.
Self-hosted means the product runs inside the customer’s trust boundary: their cloud account, their data center or a network that never touches the public internet. Data stays with them. That is the contrast that matters.
Self-hosted is not one offering. It is a spectrum.
| Dimension | BYOC | Customer-controlled environment | Air-gapped |
|---|---|---|---|
| Infrastructure | Customer cloud. Vendor often provisions it. | Customer controls the environment. | Customer owns it, fully isolated. |
| Application lifecycle | Vendor operates the app. | Customer or vendor. | Fully customer operated. |
| Vendor access | Scoped. Constrained channel. Feels like SaaS for the buyer. | Negotiated per customer. | None. |
On one end, you still run the product for the customer, just inside their cloud (BYOC). In the middle, the customer controls the environment (the infra); application lifecycle can sit with them or with you. On the other end, air-gapped: fully customer operated, no vendor access. Most deals sit somewhere between.
BYOC: self-hosted that should feel like SaaS
Bring Your Own Cloud means the application (and usually a chunk of the infrastructure around it) runs in the customer’s AWS, GCP or Azure account, often a dedicated sub-account or VPC, while you still operate it.
What the customer expects
- Data never sits in your multi-tenant cloud
- They keep cloud billing, IAM, network policies and residency under their org
- Day-to-day, it still feels managed: someone else handles upgrades, health and a lot of the grunt work
What actually happens under the hood
- Control plane stays with you: console, releases, config, fleet view, entitlements, sometimes billing.
- Data plane lands in the customer’s cloud: the real workloads and the data.
- The customer grants scoped access, usually by accepting a bootstrap stack into their account (CloudFormation, Terraform or equivalent), not by handing over a root user. That creates a management role or trust your controllers can assume.
- From there you (or an agent / management VM running with those permissions inside the customer org) provision what the product needs: VPC pieces or attachment to an existing network, subnets, storage, a Kubernetes cluster or VMs, IAM roles for the app, object storage buckets, then the application itself. In some setups that agent is literally a VM you land first; it then spins up the rest of the stack.
- After bootstrap, day-2 ops run over a constrained channel. Egress-only from the customer environment is common. Broad standing inbound access is what security teams fight and what mature BYOC designs avoid.
BYOC architecture: you operate the product; data and workloads stay in the customer’s cloud. See how Distr implements this pole.
So the customer’s mental model is: “It runs in my cloud.” Yours is: “I still own install, infra bootstrap and day-2 ops, inside someone else’s account.”
Variants matter. Some buyers want you to create the network too. Others already have a locked-down VPC and only want the app and compute inside it (BYOVPC / bring-your-own-network style). Same idea, different shared-responsibility line.
Public docs that show this pattern well (useful references, not required reading): Redpanda BYOC architecture, ClickHouse BYOC architecture.
Air-gapped: the other pole
True air-gapped environments are isolated from untrusted networks, including the public internet. The customer operates everything. You get no vendor access and no reliable path for your SaaS control plane to push an update or pull telemetry live.
That changes packaging completely.
What you have to ship
You cannot “pull latest from our registry” at install time. You typically need an offline bundle that can move across the gap: USB, an exchange server, a data diode or whatever one-way transfer process the customer already trusts. A serious bundle is not just a binary. It usually includes:
- Application container images (often as an OCI layout or image archive)
- Helm charts, Compose files or Kubernetes manifests at a pinned version
- Dependencies the install would otherwise download (operators, sidecars, base images)
- Install / upgrade tooling and release notes
- Checksums or signatures so the customer can verify nothing was tampered with in transit
Updates are the same problem again: a new bundle, a new transfer, a customer-controlled install window.
What support looks like
You will not SSH into the cluster. Debugging often means support bundles the customer generates and sends out (logs, versions and config redacted to their policy), then you diagnose offline and send a fix back the same way. If you say yes to air-gapped, you are signing up for release logistics and support without live access, not for a slightly stricter VPC checkbox.
Because install and update are this cumbersome, tooling matters more here, not less: a way to build air-gapped bundles, licenses that work offline, an overview of which customer is on which version and support without a live connection. Distr’s air-gapped deployment docs cover the product side of that.
Air-gapped deployments are still self-hosted. They are just the end of the spectrum where managed-SaaS habits stop working.
The middle: where most deals actually live
Most conversations are not pure BYOC and not true air-gapped. The customer wants the product in their VPC or on their hardware and then you invent a distribution stack.
A typical vendor-built middle looks like this in practice:
- An install script the customer’s IT runs
- Containers pulled from a mirrored registry you grant them access to (ACR, GAR, ECR, …)
- Config pulled from somewhere you control (often object storage)
- Some customers allow outbound logs; others are closer to air-gapped and need a one-shot support bundle
- You still need licensing: grant and revoke entitlement, control which versions a customer can pull (previews vs GA)
- At dozens of customers, you feel the missing pieces: no fleet view, painful targeted updates, every install a little different
That is a real product surface: registry auth, artifacts, install path, licenses, version channels. It is a lot of moving parts for a team that thought “we already have a Helm Chart.”
On the other side of the middle sit platform-mature buyers. They do not want your installer as the center of the universe. They want:
- Versioned container images and a Helm chart (or Compose)
- Their security pipeline to scan those artifacts
- Promotion into their internal registry
- Deploy through their path, often GitOps (Argo CD / Flux), sometimes plain Helm/CI
You may get zero cluster access. That is still self-hosted. You just ship artifacts and support them without living in their cluster. Distr’s fully self-managed path is built for that “hand me the chart” buyer.
So the muddy middle spans “we run the full distribution stack for less mature buyers” through “hand me the chart.” Same spectrum. Different packaging.
And the fun part is, you might have all of the variations above among your customers.
You can build all of that yourself or use a distribution control plane built for it. That is what Distr is for: ship the same SaaS into customer environments across these postures without a parallel product per deal.
How the words map (roughly)
| What buyers say | Often means |
|---|---|
| BYOC | Vendor operates app (and often infra) in customer cloud |
| VPC / private cloud / on-prem | Customer controls the environment; app lifecycle varies |
| Air-gapped | Fully customer operated, no vendor access |
One product, many postures
The trap is treating each point as a different product: a BYOC fork, an on-prem fork, an air-gapped fork.
The workable model is the opposite of multi-tenant sprawl and the opposite of infinite forks: one product, shipped into the customer’s boundary, with postures you can configure: who operates, what can be seen, how updates arrive.
That is the point of a distribution layer.
