We Need a Safer Way to Run Software in Customer Environments

In BYOC, deploying your application isn’t the hard part. Rather it is to keep it running reliably for all of your customers.

When you deploy software into someone else's cloud, you're operating in an environment you don't own. The customer is accountable for compliance, security, and audit requirements in their account. You're responsible for ensuring your software works, while being a good citizen in their account. Both sides need to agree on what's allowed and what isn't.

Now multiply that by 50 customers. Or 500. Each with their own configurations, constraints, and compliance requirements. Both parties usually do reviews and audits when the app is deployed for the first time, but that happens only once. What about ongoing changes that will get pushed to all of your customers? In the age of continuous delivery, manual reviews don’t scale and often result in incidents from a lacking process, or a human error.

We need something that can act like a contract and enforce these requirements continuously, not just on the first setup. This way, we can take all this scattered organizational knowledge and turn it into automated, enforceable checks that run every time code moves through the pipeline.

The Status Quo: RBAC Isn't Enough

Today, the primary tool for governing access in customer environments is permissions. RBAC. IAM roles. Service account scopes.

These answer one question: who can perform an action?

RBAC can tell you:

• who can run `terraform apply`
• who can patch a deployment
• who can apply a Helm chart

But that's not enough to define a contract on what you should or shouldn’t do in a customer’s environment.

For example:

• RBAC allows you to manage databases, but a simple update can lead to forced recreation of the database instance, resulting in downtime, and potentially, permanent data loss. You need a way to enforce “deny recreation of database instances”.
• You require a public ingress for your application, and have one in your customer’s account as well as your cloud. Now let’s say you need another ingress in your SaaS offering. You make an update to your infra but it gets pushed to your BYOC customers as well. As you would already need the permissions for the first ingress, RBAC here will not stop the change and the ingress will be created for your customers too. This can lead to security issues in the worst case, or a higher bill for your customer in the best.

Permissions can act as a last line of defense, as they won’t allow unauthorized actions. But they can’t prevent an actor with sufficient permissions from making a mistake. They can't tell you whether that change is safe. Whether it violates compliance requirements. Whether it aligns with the customer's operational standards. Whether it's going to cause an incident.

What Can Go Wrong

Operating in a customer's cloud without clear guardrails is a liability, and things can fail in a myriad of ways as we push changes to the application and the infrastructure supporting it. We refer to the initial setup as Day-1, and Day-2 is when the hard parts start, everything that comes after. On Day-2, you need minimal permissions, just enough to allow upgrades to the stack, but they still can’t catch everything as we discussed in the last section. We need something that is shifted-left from RBAC, and allows us to take the concerns and audits from Day-1 and have them continuously enforced before we deliver anything to the customer’s environment. Without this, at some point, vendors will run into problems such as:

• You accidentally drop and recreate a database. A schema migration goes wrong. The Terraform state drifts. Someone runs `apply` without checking the plan. Customer data is gone or corrupted.
• You add a public ingress. A new Helm chart version includes an ingress that exposes a service to the internet. No one catches it in review. The customer's security team finds out from their cloud provider's alert, or worse, from an attacker.
• You deploy a container without resource limits. The workload consumes all available memory. Other services in the cluster crash. The customer's production environment goes down.
• You push unencrypted storage configs. A new S3 bucket or RDS instance gets created without encryption at rest. The customer fails their next compliance audit.
• You give a user overly permissive roles. Investigating an incident on your customer’s cloud can lead to leaving behind an active role with unintended admin privileges. Without guardrails to elevated permissions such as time limit, audit trail, and approval, you risk an accidental admin role available as an attack surface.

These aren't hypotheticals. These are the kinds of things that can lead to downtimes, data-loss, data-leakage or other serious security vulnerabilities. As you are operating in the customer’s cloud account, you can even push changes affecting other resources, unrelated to your application. Without proactive protection against these scenarios, customer trust will erode, leading to push back on updates. Longer time between releases can make them even more brittle and painful.

Vendors operating primarily in a SaaS model already have many guardrails in place. But the problem with SaaS-specific tooling is that it doesn’t map one-on-one to many challenges unique to the BYOC world. The tooling might not scale with the large amount of customer installs. Shipping software to customer infrastructure reliably requires tooling that is purpose-built to overcome such challenges.

The Day-2 Problem

Let's say you get the initial setup right. You work with the customer to define permissions. You review your first few deployments carefully. Security signs off.

What happens after?

Infrastructure drifts. Someone makes a console edit during an outage. An emergency patch skips the normal review process. A vendor agent modifies a resource. Day-2 operations introduce changes that weren't planned.

The contract you established on day one erodes over time. Without continuous enforcement, you're back to hoping nothing goes wrong.

Multi-Tenant Cloud-Hosted Products Already Solve This

Well-run SaaS teams don't rely on hope. They validate every change before it lands.

Rules are enforced on infrastructure configs, container images, Kubernetes manifests, Terraform plans etc as part of their continuous delivery pipelines. Allowing them to catch bad changes before they hit production. There are projects like Open Policy Agent (OPA) that are used directly in CD with custom written policies, or even homegrown internal tooling in many cases.

In the BYOC model this becomes a problem of a completely different scale. Not only do we need to enforce policies for all customer environments, the policies themselves can change depending on the customer requirements. This is why it is important to solve this problem in a BYOC native way, so that we can reduce the huge amount of friction for both the customer and the software vendor around shipping new changes.

What If Policies Were the Contract?

At Nuon, we want to make BYOC feel as easy as SaaS. To achieve this, we are always thinking about some hard problems like:

• How do we make BYOC more secure and safe?
• How do we make it easier for both vendors and customers to push and accept changes?
• What SaaS primitives do we need to rethink for the BYOC world?

We believe that having policies that can govern all of the changes, encompassing customer as well as vendor requirements, is a great step in this direction.

So here's the idea: increase trust and speed to deploy your product to the customer’s cloud by making a formal, programmatically enforced contract with your customer.

Define what's allowed:

• Only approved container images can run
• All storage must be encrypted at rest
• Workloads must have resource limits
• No public ingresses without explicit approval

Define what's disallowed:

• No destructive database operations outside maintenance windows
• No changes to networking without customer approval
• No untagged resources

The rules expressed as policies can be enforced by the delivery pipeline, and the results provided to customers as part of audit reports. Now you have a contract that's not just documentation. Both vendor and customer can see what the rules are, and both can verify they're being followed.

Policy Enforcement: Shift Left or Pay Later

We can have policies in the runtime itself, for example Kyverno policies in a Kubernetes cluster, but they are only evaluated once a change makes into the runtime. The ideal point instead, is to catch these problems during the build, or deploy stages, before they even make it to customer environments. Shifting left from in-cluster policy enforcement to earlier stages allows for timely intervention. In BYOC, this is non-negotiable.

Policies block vulnerabilities before they land:

• Insecure configurations (public buckets, missing encryption)
• Unapproved container images
• Workloads without resource limits or security contexts
• Infrastructure changes that violate hardening standards

The best feedback comes earlier during planning and diff phases, as the plan/diff reflects the exact change that is about to be applied. Allowing developers to fix issues before they're even applied. And policies don't stop at the plan. Once paired with drift detection, policies can catch violations introduced outside CI/CD such as console edits, emergency patches, or manual changes. The result: reduced attack surface, fewer incidents, and faster remediation when issues do occur.

Efficiency Gains: Speed Without Sacrifice

There’s a common misconception that policies slow teams down. The opposite is true.

Manual gates and waiting for security review, compliance sign-off, or ops approval are the real bottlenecks. Automated policies remove them and allow for:

• Faster feedback — developers learn about violations immediately, not days later
• Less rework — issues caught early are cheaper to fix
• DevSecOps alignment — dev, sec, and ops teams agree on rules once, and enforce them everywhere
• Scalability — policies work the same whether you have five environments or 500

Automation doesn't replace judgment, but rather encodes the judgment your organization has already made, and applies it consistently.

What This Means for BYOC

Security and reliability for a software depends on the cohesion between the app itself and the environment, the release process, etc. In SaaS, this is easier to achieve, as the operators own all parts of the equation, but they also need the customers to hand over their data. On the other hand, in the self-hosted/on-prem model, the customers handle the operational burden. Due to lack of expertise and internal knowledge of the application, they are inefficient, and tend to have more reliability and security issues.

BYOC has the potential to bring the best of both worlds together. If done properly, it can achieve a similar level of cohesion to SaaS, allowing you to deliver secure and reliable applications, while the data lives in the customer’s infrastructure. For this we need to think about primitives that allow a software vendor to secure the application from both, the cloud SaaS, and the self-hosted perspective.

In the BYOC model, policies aren't a nice-to-have, they're the contract between the customer’s environment and your application.

For vendors, policies mean shipping with confidence. Every deployment follows the same rules. Every customer environment meets the same baseline. Support burden drops. Trust scales.

For customers, policies mean control without micromanagement. Vendor software runs in their cloud, and on their terms. Compliance is verifiable. Audits are survivable.

For both, policies mean fewer surprises, faster feedback, and a foundation of trust that makes BYOC work at scale.