There is an email that arrives at a certain point in every B2B software company’s life. It comes from the security team at the largest deal in your pipeline, and it reads something like: “We would like to proceed, but the platform will need to run inside our own cloud account.” Six months ago that request was rare enough to ignore. In 2026 it is common enough that answering it badly costs you the contract.
The pattern has a name: Bring Your Own Cloud, or BYOC. Your software runs in the customer’s AWS, Azure or Google Cloud account. Their data never crosses into your infrastructure. You still operate the product, ship updates and answer support tickets, but you do it remotely, through a control plane, into an environment you do not own.
It sounds like a deployment detail. It is not. It is a product decision that reshapes your architecture, your pricing, your support model and your engineering roadmap for the next two years.
TL;DR
- BYOC means your software runs in the customer’s cloud account while you continue to operate it remotely, splitting your system into a vendor-hosted control plane and a customer-hosted data plane.
- Demand is being driven by supply chain breaches, EU data residency pressure and procurement policies in financial services, healthcare and the public sector, where BYOC is increasingly written into requirements rather than negotiated.
- BYOC is a spectrum, not a switch: dedicated cloud account, deployment into an existing VPC, Helm charts into a customer-managed Kubernetes cluster, and fully air-gapped delivery. Each rung costs materially more to support.
- The expensive part is not day one. It is day two: upgrades across dozens of environments you cannot see into, telemetry without data leakage, usage metering for billing, secret rotation and support without direct access.
- Say yes when contract values justify a dedicated engineering investment and a real control plane. Say no when the ask is a single mid-market deal and the honest answer is a single-tenant hosted option instead.
What BYOC actually changes
In conventional SaaS you host everything. You have root, you have logs, you can reproduce a bug on the customer’s actual data at three in the morning. BYOC removes all of that.
The architectural move is a hard split between a control plane and a data plane. The control plane stays with you: it manages provisioning, releases, configuration, entitlements and fleet-wide health. The data plane runs inside the customer’s boundary and holds the workload, the data, the network controls, the audit logs and often the cloud bill itself.
The rule that follows is zero inbound access. You do not open a port into a customer’s VPC. Instead, an outbound-only agent inside their environment calls home, receives instructions and reports status. Nothing in your infrastructure initiates a connection into theirs. That single constraint invalidates a surprising amount of tooling that most teams take for granted.
It also collapses assumptions that are baked into almost every SaaS codebase: open outbound internet access, permissive security groups, default DNS resolution, vendor-managed ingress. In a mature enterprise cloud estate, none of those hold. You will meet egress allowlists that need every domain you call declared in writing, private endpoints instead of public APIs, and internal DNS policies that break service discovery in ways your staging environment never will.
Why the request is arriving now
Three forces converged.
The first is supply chain fatigue. A run of vendor compromises taught CISOs a lesson they have not unlearned: every SaaS tool in the stack is an extension of their own attack surface, and a breach at a supplier is a breach at them. Pulling the workload inside their own perimeter does not eliminate that risk, but it makes the blast radius theirs to control.
The second is data residency. With EU-US transfer mechanisms under sustained legal pressure, “the data stays in our tenant, in our region” has become the shortest path through a legal review. We have written before about what the transfer crisis means for development teams, and BYOC is one of the few answers that satisfies a data protection officer without a two-year architectural programme.
The third is regulatory accumulation. The EU Cyber Resilience Act brings reporting obligations from 11 September 2026, the AI Act phases in through August, and sector regulators are increasingly specific about where processing happens. Procurement has responded by turning deployment topology into a scored requirement rather than an implementation detail.
The spectrum, and what each rung costs you
BYOC is not a single model. It is a ladder, and the further you climb the more expensive it gets.
Dedicated cloud account. The customer provisions a clean account or project purely for your product, and grants you scoped IAM roles. This is the cheapest and cleanest option: you get account-level isolation, a predictable environment and a clear boundary of responsibility. If you are going to support BYOC at all, support this first.
Existing VPC. You deploy into infrastructure the customer already runs, which means inheriting their network architecture, private connectivity requirements, DNS policies and egress rules. No public endpoints. Expect to spend real engineering time on PrivateLink-style connectivity and on the long tail of environments where something subtly differs.
Customer-managed Kubernetes. You ship a Helm chart or an operator into a cluster the platform team owns. They enforce admission policies, image scanning and service mesh rules. You gain reach and lose control: your product now has to survive a security policy you did not write and cannot test against.
Air-gapped delivery. Signed offline bundles, mirrored artefact repositories, no internet at all. This is defence, critical infrastructure and parts of the public sector. Treat it as a separate product line with its own release process, because that is what it is.
Day two is where the money goes
Getting the software installed once is a solved problem. Terraform, a Helm chart and a good week of work will do it. The cost lands afterwards, and it lands repeatedly.
You now run upgrades across a fleet of environments with different versions, different network policies and different maintenance windows, with safe rollout and rollback in each. You need observability that gives you enough signal to operate without exfiltrating customer data, which usually means aggregating metrics and redacted traces rather than shipping logs home. You need usage metering that works when the meter lives on the other side of the boundary and the customer can, in principle, tamper with it. You need certificate and secret rotation that does not require a human with console access. You need to support a customer through an incident in an environment you cannot open a shell into.
This is why BYOC is a product architecture, not a deployment script. A control plane that governs many isolated customer environments without overreaching into them is a substantial system in its own right. Teams that underestimate this end up with a bespoke, hand-operated deployment per customer, which is exactly the outcome that kills margins.
The commercial reckoning
Three contract questions decide whether BYOC is profitable or merely impressive.
Who pays for the infrastructure? In BYOC the customer usually absorbs the cloud bill, which is often part of the appeal, since they can apply committed spend discounts. That means your pricing should not be quietly subsidising compute any more. Reprice accordingly, and price the operational burden explicitly.
Where does your responsibility end? If the customer misconfigures a security group, patches a node badly or hits a quota limit, whose incident is it? Write the split down. Ambiguity here is the single most common source of BYOC support disputes.
What does the SLA mean now? You cannot credibly promise four nines on infrastructure you do not control. Uptime commitments become shared and conditional, with defined customer obligations attached. This is the same discipline we covered in our guide to maintenance and support agreements, applied to a much harder case.
A decision framework
Before you agree to anything, answer four questions honestly.
- Is the demand structural or is it one deal? If three or more regulated prospects have raised it independently, it is a market signal. If it is one enthusiastic CISO, it is a feature request with a very high price tag.
- What is the annual contract value? BYOC realistically costs a small team six to twelve months of focused engineering plus permanent operational overhead. If the deals are not six figures, the arithmetic does not work.
- Is your product already deployable as an isolated unit? If you cannot stand up a complete single-tenant instance from source with one command today, you are not months from BYOC, you are further out than that.
- Would a lesser option close the deal? Sometimes the real requirement is regional data residency, or a dedicated single-tenant instance in your own cloud, or a customer-managed encryption key. Ask what the security review actually needs before agreeing to the most expensive answer available.
If you do proceed, sequencing matters. Build single-tenant isolation in your own cloud first and operate it as if it were a customer environment. Move to an outbound-only agent architecture. Ship versioned, signed releases with an SBOM, because supply chain review will ask. Build fleet telemetry before the fifth deployment, not after. And decide early whether a second cloud provider is on the roadmap, because retrofitting portability is far more painful than designing for it.
The bottom line
BYOC is not a fad, and it is not free. It is the market repricing trust: enterprise buyers no longer accept “our infrastructure, our rules” as the default, and vendors who can meet them inside their own perimeter reach deals others cannot. Treated as a product line, with its own architecture, pricing and operational discipline, it opens a segment that was previously closed. Treated as a favour to one large customer, it becomes a permanent tax on your engineering team.
REPTILEHAUS builds and operates SaaS platforms, cloud infrastructure and deployment automation for companies selling into regulated markets. If you are weighing a BYOC request, working out whether your architecture can support one, or trying to establish what a security review actually requires before you commit, get in touch.
📷 Photo by Albert Stoynov on Unsplash
