What is BYOC? Bring your own cloud, explained
BYOC stands for bring your own cloud. It is a deployment model where a vendor's software runs inside the customer's cloud account, and the vendor still operates it: deployment, updates, monitoring, debugging, the whole day-2 job.
The second half of that definition is the part people miss. Plenty of software ends up in customer accounts: a Docker image they pull, a Helm chart they install, an AMI they launch. That's self-hosting, not BYOC. The difference is who runs it afterward: in BYOC, the vendor keeps operating the product, the same way they run their own SaaS.
The usual architecture splits the product in two. The control plane stays in the vendor's cloud: dashboard, configuration, orchestration, billing. The data plane, the part that actually touches customer data, runs in the customer's account and connects out.
Architecture diagram. Data plane (Workloads, Customer data) connects outbound to the Control plane (Dashboard, Config, Releases), via outbound https 443.
The customer's data never leaves their account. The vendor's ability to operate never leaves either. Both sides keep the thing they care about most.
BYOC and its neighbors
BYOC keeps getting confused with its neighbors, and the confusion is expensive in sales calls. Cut through it with two questions: does the data stay with the customer, and does the vendor keep operating the product?
Comparison. SaaS: Data stays home — no; Vendor runs it — yes. Single-tenant SaaS: Data stays home — no; Vendor runs it — yes. Self-hosting / on-prem: Data stays home — yes; Vendor runs it — no. BYOC: Data stays home — yes; Vendor runs it — yes.
Single-tenant SaaS gives the customer a dedicated instance: their own VPC, their own database, sometimes a dedicated account. But it is the vendor's account, so the data still leaves — and for the security teams driving these requirements, that is the entire question. It solves noisy neighbors, not data residency. That's why its row above matches SaaS exactly.
Self-hosting puts the software in the customer's environment and the operations on the customer's plate. They install it, they upgrade it, they debug it at 2am. Beyond a simple binary, that asks every customer to become an expert operator of your product. Most won't, and the deployment freezes at whatever version they installed.
On-prem is self-hosting's older form: the customer's physical data center instead of a cloud account. Same operating burden, minus the cloud APIs that make remote management possible at all.
BYOC is the only model that answers yes to both questions. The customer provides the account and the boundary. The vendor provides the software and the operations. That split is what the term means, and losing it is what makes most "BYOC" offerings self-hosting with better marketing.
Why BYOC exists
Three forces, and all three got stronger in the last few years.
Data gravity. The most valuable data does not move. Codebases, internal documents, proprietary databases, systems behind the firewall with no public endpoint. AI made this acute: the data agents need most is exactly the data that cannot leave. If the data won't come to your software, your software goes to the data.
Security review reality. "Your SaaS receives our data" triggers the longest possible review: subprocessor agreements, data flow diagrams, months. "Your software runs in our account, connects outbound only, and here is the exact IAM policy" is a review a security team can actually finish. The approval isn't about trust in the vendor. It's about how small and inspectable the trust has to be.
Cloud commits. BYOC infrastructure runs on the customer's own AWS, GCP, or Azure bill. That spend burns down their committed-use contracts and reserved-instance discounts. Procurement teams sometimes prefer BYOC for this reason alone, before security says a word.
The three trust models
Every BYOC implementation answers one question: how much access does the vendor get to the customer's account? A decade of vendor engineering blogs sorts into three answers.
Cross-account push. The customer creates an IAM role; the vendor's control plane assumes it and drives resources in their account directly. This is how Databricks launched Spark clusters into customer accounts for over a decade, and it is the fastest model to build. It also aged the worst: broad standing access into customer accounts is exactly what security teams have stopped approving, and Databricks itself has spent years migrating compute back out.
Outbound-only agent. A small vendor component inside the customer's environment dials out over HTTPS, pulls desired state, and applies it locally. Nothing dials in. No inbound ports, no VPN, and the customer keeps a kill switch: one firewall rule cuts the vendor off completely. This is where nearly every vendor that iterated on BYOC ended up, from Redpanda's agent to Kong's gateways to ClickHouse's support tunnel, because the direction of the connection is the thing security teams can approve.
Zero-access. Redesign the software so the vendor needs no access at all: stateless components in the customer's account, all state in customer-owned storage, only metadata crossing the boundary. WarpStream is the canonical case. It is the strongest trust story and the hardest to retrofit, because it is an architecture, not a deployment option.
Not sure which model a given customer will accept? Two questions usually settle it:
Model picker
Can the customer grant a scoped cross-account role (or the GCP / Azure equivalent)?
When BYOC is the wrong answer
BYOC is an enterprise deal structure, and it costs like one. Some honest cases against it:
No enterprise pull yet. If no customer has asked, don't build it. BYOC exists to close deals that SaaS cannot close. Just know that when the pull comes, it tends to come from the largest companies first.
One cloud, one customer. A single deployment in a single customer's AWS account doesn't need a platform or a category. It needs a Terraform module and an engineer who answers the phone. The economics change at customer three, when the environments start multiplying.
The reason isn't nameable. If neither you nor the customer can say in one sentence why the data must stay in their account, SaaS is simpler for everyone. An account boundary is not a security guarantee by itself — what matters is who can deploy code and reach data, which is why the trust models above are the real conversation.
What Alien does
BYOC's definition has two halves: the software runs in the customer's account, and the vendor still operates it. Alien is an open-source platform for the second half. You describe your stack in one file, and Alien deploys it into each customer's cloud through whatever their security team will approve — a scoped cross-account role, an outbound-only operator, or an airgapped bundle. From your side, every customer looks the same: one command releases everywhere, health and telemetry come back without customer data, and debugging happens through audited commands instead of SSH. The architecture is in how Alien works.
Most people read the first half of the definition and start writing Terraform. The install is a weekend. It's the second clause, "the vendor still operates it," that takes years, and it's the half that makes BYOC a product instead of a handoff.
The component most teams already ship into customer environments without calling it BYOC is in the agent nobody operates, and the question every BYOC deal eventually hits — where login happens and where user records live — is in authentication for BYOC apps.