When vendors start getting requests from their customers to deploy their software to the customer's environment, they need to make decisions on how to architect their software for BYOC (Bring Your Own Cloud) and how to respond to frequently asked questions during the sales cycle.
The vendors who struggle are the ones who wait until a customer demands BYOC to start figuring out their dependencies, their auth, and their networking in real time. The ones who do well get in front of it on the architecture side. They go in already knowing every external service their system has to talk to, and they’ve prepped how the deployment will actually go down. Then, by the time the customer asks for BYOC, the answer is yes.
At Nuon, we’ve seen all types of architecture styles and fielded every question from vendors going through this preparation. Let’s walk through everything you’ll need to consider.
Security
Identity & Authentication
Customers use different Identity Providers, so vendors should make authentication pluggable in their BYOC offering. Not every end customer will use your auth, so it’s a best practice to support the customer’s preferred authentication.
Nuon initially hit the same problem with Auth0, so we now treat authentication as a pluggable layer. Provide an OAuth client ID and secret from Entra, Google, or any compatible provider and Nuon handles the rest. Under the hood, we've built a lightweight, open-source, Go-based auth component that gets deployed alongside your app.
If your app has been leaning on a hosted auth SaaS (like Clerk) to carry roles and permissions, that authorization logic has to be ported into your own app, because you're ripping the hosted provider out to be pluggable. Smaller end customers may not care about RBAC, but the larger enterprises will, so you might as well build real RBAC as part of the same BYOC port.
Supply Chain Security
Supply Chain Security answers a different question than identity and permissions: not who gets in or what they can touch, but what you are putting in the customer's cloud in the first place. It comes down to provenance, the customer being able to verify your artifacts before they run, and it usually shows up as two asks: container image scanning and SBOMs. Both are vendor responsibilities at the application layer. Nuon does not generate SBOMs for you. You produce a Software Bill of Materials for each individual image component, the same way you own scanning your own images, because only you know what is actually in them. With regulators now forcing the issue — such as the US executive order on software supply chain and the EU's upcoming Cyber Resilience Act — expect SBOMs to move from a nice-to-have to a hard gate in regulated accounts.
Where Nuon helps is on the packaging and enforcement side. Nuon lets you vendor your images as part of the app config, so the artifacts that land in the customer's environment are the ones you declared, not whatever a registry happens to serve at deploy time. And while Nuon does not create SBOMs, its policy engine detects and enforces them on the customer's behalf . A vendor can require every image to carry an SBOM before it deploys into the customer VPC, restrict to a specific format such as CycloneDX, or block deployment entirely when no SBOM is present. That turns your SBOMs into something the customer can verify and gate on, which is exactly the assurance a security-conscious buyer is asking for.
Networking
VPC
As a vendor, you want as much control as you can have, to ensure your app works the same way, every time, across every install. So your baseline should be to create the VPC in the customer’s cloud account.
But you should be ready to support BYO VPC or even BYO Kubernetes cluster if the end customer demands it. By default, our install stack creates the VPC, subnets, and NAT Gateway, but you can use other flavors of our stack templates that pass VPC information to our sandbox primitive. That’s a large part of the substrate of your application, like a Kubernetes cluster.
Allowlists
More security-focused end customers may want a deny-by-default VPC egress. When you set up your Nuon app config, it’s more than just Nuon control plane endpoints, image registries, package repositories, IaC sources, observability, and the end customer’s own internal services. Nuon’s install stack template ships with optional allowlist support built in.
Cutoffs
Because the Nuon runner resides in the VPC, the customer can shutdown the VM, effectively stopping the runner from communicating with the Nuon control plane. Some customers do this after the initial app provisioning, then periodically start the VM and runner during maintenance windows or troubleshooting sessions.
Package Your App
Packaging is where preparation turns into an artifact you can actually ship into a customer's cloud. Making it work in an environment you can't log into is the hard part. So the goal in packaging is to get your app into the customer's cloud quickly and put your effort into everything that comes after.
From Source to Install
You connect your existing infrastructure as code, container images, and Helm charts, and you get a deployable artifact, an install. That install is what goes into the customer's environment, and from then on you manage it from the control plane and push updates with a Git-style branching model. You aren't rebuilding your app for BYOC, you're wrapping what you already ship.
Vendor Your Dependencies
Vendor your images and your dependencies into the app config so the install is self-contained and isn't reaching out to pull things at deploy time, which matters a lot once you're behind an allowlist. Where a dependency has a self-hosted or open-source version, like a durable workflow engine or a self-hosted database, you can pull that into the app config, too, instead of relying on the customer to stand it up. The more the install carries with it, the fewer surprises you hit in an environment you don't control.
Operations
Release Management
Unlike Saas, BYOC doesn’t have a push-whenever cadence. The vendor inherits the customer’s release window and their runner-permission-cut-between-updates posture.
Nuon’s control plane manages updates with a Git-branching model, where changes to your app automatically kick off customer install updates depending on branches for groups of customers.
External Dependencies
The real challenge with packaging up your app for BYOC is handling the external services, especially the application layer like porting authorization policies from authentication providers like Clerk or database vendors that may have additional functionality not in their self-hosted PostgreSQL version or AWS RDS. Cloud hosting platforms like Fly.io, Railway, or Render are easier to move into Kubernetes and a container service like AWS ECS.
The takeaway is that your application code is rarely the challenge; the challenge is every externally hosted service your app calls out to. Each dependency resolves one of three ways: swap it for the cloud-native equivalent (Supabase file storage to RDS/S3, Postgres to RDS), let the customer bring their own existing enterprise engagement (ClickHouse, Temporal, SES), or vendor a self-hosted/open-source version into the Nuon app config (Ingest, self-hosted Supabase). The prep work is inventorying every outbound call and deciding which bucket each one falls into before you ever write the Nuon config.
Dev vs. Prod BYOC Environments
Two or more BYOC environments is the norm, not the exception for your BYOC customers. Expect to reproduce your typical application development pipeline (stage/prod) to translate to how you roll out to a customer environment. Now the total number of prod/stage environments you manage are multiplied by the number of BYOC deployed customers.
Every architecture or dependency change has to be proven in a dev BYOC environment first, because in prod it's amplified across every customer install. You don't get to test in your own single cloud and ship — you test in a representative BYOC environment that mirrors the customer's constraints (their VPC, their allowlist, their IdP, permissions cut between updates), then promote through the release window.
The control plane's Git-style branching-style promotion model is what makes dev to prod tractable. You promote an install from a lower environment to production rather than hand-rolling each deploy.
What You’re Taking On
The application code is rarely a problem. The hard parts are everything around it. Mapping every external service and deciding whether to swap it for a cloud-native alternative, let the customer bring their own, or vendor in a self-hosted version. Making auth pluggable for customer identity providers. Operating inside a network you don't control, usually with deny-by-default egress. Releasing on the customer's schedule instead of yours, with reduced permissions between releases and no direct access to production when something goes wrong.
And doing all of that across every customer. Each environment is isolated. Most run two or more. Every architecture change multiplies across your install base.
That's a lot to absorb while you're still trying to close the deal asking for it.
Where Nuon Comes In
With Nuon, you get a runner that sits inside the customer account and manages everything over egress with almost no standing permissions. That's what makes the allowlist requirement workable and avoids the fight over permissions getting cut between releases. Your existing infrastructure as code, containers, and Helm charts become an install artifact and a control plane that promotes releases across customers with a Git-style branching model. Dev versus prod across a growing install base becomes something you operate, not something you hand-roll.
Day two is handled, too. Runbooks and actions for environments you can't log into directly. Break glass for when a windowed release goes sideways. Drift detection when a customer's environment changes underneath you. Security requirements, SBOMs, image scanning, and egress allowlists enforced as policy rather than a manual checklist.
Once you have an approach mapped out for all of these considerations, you can show up with confidence for conversations with your end customers, and move forward with ease to a BYOC setup.
Ready to get started?
Deploy your application into customer clouds
See how Nuon can help you unlock BYOC deployment for your entire customer base.