It's easy to get caught up in the news and marketing around Bring Your Own Cloud (BYOC). Software vendors are creating BYOC landing pages with a form to contact sales. Leadership like Grafana's CTO gave an interview with an opinion of why their customers should adopt BYOC to reduce cost.
The JPMorgan Chase CISO published an open letter warning that SaaS vendors are prioritizing feature development over security, creating dangerous concentration of risk. Separately, JPMorgan's own technology strategy team named BYOC one of the top trends of 2025 , describing it as purpose-built to address exactly those concerns around security, data sovereignty, and resiliency.
Being an early entrant when BYOC was not even an understood term, Nuon has developed implicit knowledge through 3-4 years of conversations with seed stage startups to established software vendors and their quest to meet customers in the middle with a deployment option that solves data residency requirements and still feels like SaaS, with the vendor managing the installation, performing upgrades and ensuring up-time.Before we dive in, let's get on the same page about terminology.
What is BYOC?
The concept goes by many names: BYOC (Bring Your Own Cloud), Cloud-Prem, Hybrid Cloud, Vendor-managed, Customer-hosted. The terminology varies by audience, but the idea is the same. Software that runs inside the customer's infrastructure, managed by the vendor. Don't get too hung up on any one term though. Each carries its own nuances and interpretations depending on who you ask. These are the patterns we've observed from years of conversations with software vendors, from early-stage startups to established vendors.
Startups want to win any deal they can. They have a B2B product that appeals to large enterprises, and are being told SaaS is a non-starter. They are eager to demonstrate that operating their software in the customer's cloud is a viable option, yet want to grasp the level of effort to adjust and fit their stack into a BYOC fashion.
They may lose the sales cycle at any moment. A new CISO or economic buyer can say no, so speed is of the essence. They just want to add BYOC on their docs page fast and are focused on getting something working with their app and BYOC. For startups, security is a means to an end, to satisfy enterprise buyers. They'll gladly delegate it to the platform rather than investing in it themselves.
Startups & Established Vendors
For established vendors, BYOC is a tax they'll pay to unlock security-sensitive customers, but only if the ROI is clear. The sales case is obvious; the operational burden is what gives them pause. Upgrades, debugging across customer clouds, version sprawl. Day-2 operations are the real cost. That's why many large vendors scope BYOC narrowly: one cloud, one architecture, optimized for their own operational convenience rather than what every customer actually needs.
There's another dimension with established vendors: organizational inertia. They don't run POCs on a whim. They organize a tiger team, document requirements, speak with vendors, and move deliberately. When they evaluate a BYOC platform or consider building this in-house, they already know what they need. These are not BYOC problems. They're fleet management problems that come with having an existing customer base.
Three Principles of BYOC
These two customer types, startups moving fast to prove their app works in a customer's cloud, and established vendors solving security and fleet management at scale, led us to three principles about what BYOC actually requires.
Getting Your App Ready
The first principle is simple: port your app to run in a customer's cloud. For startups, this is the most pressing question. The most forward-thinking ones are asking it before they even have enterprise customers. If you're going to engineer something, why not engineer for the customer most likely to pay more and demand it anyway? The good news is that BYOC doesn't require a Kubernetes-native app or polished Helm charts. Modern infrastructure primitives like S3, Serverless, containerization via AWS ECS, Google Cloud Run, or Azure Container Apps make BYOC-enabling an app far more accessible than vendors assume.
The platform also needs to handle the reality that not every customer looks the same. Different versions of your app may be required to match varying customer architectures. Some vendors, particularly in AI and database, will want to split-plane it: keeping a control plane on their side while putting the data plane in the customer's cloud to satisfy data residency requirements.
Accommodating any Customer Requirement
The second principle is meeting customers where their infrastructure already is. Every enterprise customer comes with their own set of requirements. A bank may provide a locked-down shared Kubernetes cluster and expect you to deploy into it. Another customer provides the VPC. Others want to bring their own LLM such as AWS Bedrock, Azure OpenAI, Google Vertex AI, their own S3 bucket, or their own encryption keys. These aren't edge cases, they're the norm.
Supporting this requires flexible, repeatable handling of custom inputs: app configurations, API keys, license keys, sensitive values, which are expressed through customer-specific infrastructure templates like CloudFormation, Azure ARM templates, or Google Deployment Manager. When you land your first BYOC customer, none of this feels urgent. There's anecdotal evidence that some established vendors treat BYOC as a VIP offering for only their largest, multi-million dollar accounts. The proof is in their marketing: a BYOC landing page with nothing but a contact sales form. That's not a product, that's professional services dressed up as a license with a multi-year price tag.
This is the principle that separates your first BYOC customer from your tenth and one startups grow into but can't grow without. Supporting a couple of customers manually is manageable. Beyond that, the cracks start to show. Established vendors know, even if they won't say it: this is the bridge from pets to cattle, from bespoke to repeatable, from professional services to a scalable business. The outcome is the same. You're making BYOC commercially viable across a diverse customer base.
Day 2 - Continuous Delivery in BYOC
The third principle is secure, continuous delivery of your app into customer infrastructure. It's where the real operational weight lives.
This means approval gates before each infrastructure change, drift detection when a customer admin tinkers with your app's infrastructure, and policies that prevent catastrophic changes to customer databases or unauthorized external network access. Every state and infrastructure change is audit logged, without exfiltrating sensitive customer data. When your app falls over, SSH and shell access aren't options. You need a mechanism to approve and run health check scripts, review state, and troubleshoot, all within a permission structure that is authorized and time-gated by the customer, not the vendor. The customer sees the audit log of everything that was run and done.
Alternatives like cross-account access and VPC peering work, but carry a potentially wider blast radius and difficult auditability. They don't mesh with the second principle at all. A customer bringing their own VPC, cluster, LLM, or encryption key has infrastructure requirements that wide-open access models fundamentally can't accommodate.
Startups aren't thinking about this yet and that's fine. If you don't have customers, or have one, you're better off building a better app than engineering a polished continuous delivery engine. Startups benefit from the fact that established vendors' security and operational requirements are what created the market for BYOC platforms in the first place. Established vendors need a security model that flexes across diverse customer infrastructure and policy requirements, and an app versioning approach that makes deploying updates predictable and safe across dozens to hundreds of customer deployments.
This is day-2 and beyond. It's what makes BYOC a business you can actually operate at scale.
Scaling BYOC
Customer reasons for adopting BYOC are as diverse as vendors' reasons for offering it. The movement is early, but showing real signs of maturity. Not maturity measured in thousands of deployments, but in the diversity of opinion, the complexity of the tradeoffs, and the gap between how startups and established vendors think about it.
There are real business model tensions driving vendor behavior that don't get talked about enough. Established vendors have built revenue models around multi-tenant SaaS, dedicated SaaS, and self-hosted. Adding a new deployment model doesn't just add complexity. It introduces unpredictability into revenue, support, and operations. BYOC can feel like opening a Snowflake-style business overnight: forward deployed engineers, cloud troubleshooting across customer accounts, customer success calls that turn into infrastructure debugging sessions. The concern is legitimate. But it shouldn't be harder than SaaS to operate, and the vendors who treat it that way will find themselves on the wrong side of where enterprise buying is heading.
On the customer side, regulated enterprises have felt this tension for years. The consolidation of the software industry onto a small number of SaaS and cloud providers is a systemic risk. Cloud outages and auth provider incidents are no longer hypothetical. They're documented, they're recent, and regulated enterprises have taken notice. These customers want to use your software. They just want it running in their infrastructure.
The tension between vendors and customers on this has always existed. The pendulum swung hard toward SaaS for good reasons. But it needs to swing back a little. Not all the way to self-hosted, not back to on-prem, but just enough to meet the customers asking for it. BYOC is that middle ground. The vendors who figure it out will close more deals and build a more resilient business in the process.
Ready to get started?
Deploy your application into customer clouds
See how Nuon can help you unlock BYOC deployment for your entire customer base.