SaaS deployment in customer environments: a guide for SaaS vendors

SaaS deployment in a customer environment means running your software inside a customer's own cloud account (AWS, GCP, or Azure, for example), rather than in your infrastructure. In most implementations, the vendor manages the application and updates centrally through a control plane. Depending on the deployment pattern, some or all of the customer's workloads and data remain inside their own cloud account.

Enterprise customers in regulated industries often require software to run within their own cloud environment rather than in a vendor's shared infrastructure. For SaaS vendors moving upmarket, this is one of the more frequent requirements that comes up during enterprise procurement.

This guide covers what SaaS deployment in a customer environment involves, why enterprises require it, the three main SaaS deployment patterns for customer-hosted infrastructure, the operational challenges of supporting it at scale, and how vendors approach automating it.

When an enterprise customer requires deployment inside their own cloud, it is typically driven by compliance frameworks, internal security policies, or data residency requirements.

Understanding what drives that requirement, and what it takes to support it, is what the rest of this guide covers.

Many enterprises operate under regulatory frameworks or internal policies that prohibit sending certain data to a third-party cloud environment, regardless of the vendor's certifications.

The specific drivers vary by industry:

• Healthcare: the Health Insurance Portability and Accountability Act (HIPAA) requires covered entities to implement appropriate safeguards for protected health information and to establish Business Associate Agreements with any third party that handles it. Many healthcare organisations satisfy this by keeping PHI within their own cloud environment.
• Financial services: firms regulated under the Payment Card Industry Data Security Standard (PCI-DSS) or under financial regulatory frameworks such as those set by the Financial Conduct Authority (FCA) often have strict internal policies about where data can be processed and stored.
• Government and public sector: the Federal Risk and Authorization Management Program (FedRAMP) requires software to run within approved infrastructure boundaries. Air-gapped deployments are required for certain defence and intelligence use cases.
• Data residency regulations: the General Data Protection Regulation (GDPR) restricts transfers of personal data outside the EU unless adequate protections are in place. Many organisations address this by keeping data within EU-based infrastructure.
• Internal security posture: some enterprises, regardless of regulatory requirements, have a blanket policy against granting third-party vendors access to data in their environment.

In many cases, these requirements apply regardless of a vendor's security certifications or audit history.

The term covers several different deployment models, which are often used loosely and interchangeably. The table below defines them precisely.

The terms customer VPC deployment and BYOC (Bring Your Own Cloud) are often used interchangeably, though implementations vary between vendors. In most cases, the vendor deploys and operates software inside the customer's own cloud account. The key architectural concept is the separation of the control plane from the application plane.

The control plane typically stays in the vendor's account. It handles deployment orchestration, CI/CD pipelines, configuration management, monitoring, and update delivery. Depending on the pattern, some or all of your services, databases, and compute resources operate inside the customer's VPC as the application plane. In some configurations, data may cross the boundary between the vendor's account and the customer's environment, for example when application logic in the vendor's account accesses a remote data store in the customer's VPC.

The two planes connect through a secure cross-account link, using cloud provider mechanisms such as IAM roles on AWS, service accounts on GCP, or managed identities on Azure, all scoped to least-privilege access. The vendor can push deployments and read health signals without accessing the customer's application-level data directly.

Not every customer deployment requires moving your entire application stack into the customer's environment. There are three distinct patterns, each with different tradeoffs.

The control plane and application logic run in the vendor's account. Only the database or data storage layer is provisioned inside the customer's VPC. The application accesses the remote data store through a cross-account role or equivalent mechanism on the customer's cloud provider.

This is the least operationally complex pattern. It works when the customer's compliance requirement applies to data at rest rather than to compute or processing. The vendor retains control over the application layer, but the customer takes on some responsibility for the availability and backup of their remote data store.

The control plane runs in the vendor's account. Certain application services, typically those that process sensitive data or need to run close to the customer's data, are deployed into the customer's VPC. The rest of the application continues to run centrally.

This pattern works when only specific services handle regulated data. The complexity increases because you now have application services running across two separate environments that need to communicate reliably across account boundaries. This also introduces network latency between services running in different environments, which may affect performance depending on how frequently those services communicate.

The entire application plane runs inside the customer's VPC. The vendor retains only the control plane in their own account. All compute, storage, services, and networking exist within the customer's environment.

This pattern is typical for customers in heavily regulated industries or for air-gapped deployments where no outbound connectivity to the vendor's infrastructure is permitted. It is also the most operationally demanding pattern for the vendor to support.

The table below maps common regulatory frameworks to the deployment requirements they create.

Some enterprises impose deployment requirements beyond what their regulatory framework technically mandates. A financial services firm might require customer VPC deployment not because PCI-DSS demands it, but because their information security team has a blanket policy against third-party vendors touching infrastructure near customer data. Internal policies are often harder to work around than the regulations themselves.

Supporting one customer VPC deployment is a project. Supporting ten is a system. Supporting fifty without a dedicated platform is a significant ongoing engineering commitment.

Here is what you need to build and operate for each customer environment:

• Environment provisioning: in most modern implementations, each new customer needs a Kubernetes cluster (EKS, GKE, or AKS), VPC configuration, networking setup, and cloud provider roles for cross-account access. Done manually, this can take several weeks per customer depending on the complexity of the environment.
• Secure cross-account connectivity: your control plane needs a persistent, secure connection to each customer environment using least-privilege cloud provider mechanisms, managed across every customer without credential sharing.
• CI/CD across multiple environments: your pipeline needs to support multi-environment targeting, progressive rollouts to specific customers, and rollback on failure. Some customers require a change approval step before any update is applied.
• Configuration management: each customer will have variations such as custom domains, feature flag states, or regional configurations. You need a layer that applies per-customer overrides without forking your codebase.
• Observability without data access: your pipeline needs to collect operational telemetry such as CPU usage, memory, and error rates without reading application-level data. This requires separation at the logging and metrics layer.
• Onboarding time: without automation, getting a new customer environment provisioned, reviewed, and tested typically takes two to six weeks.

A common approach uses Infrastructure as Code tooling, such as Terraform, Pulumi, or AWS CDK, to define the customer environment template once and provision it repeatably. Kubernetes provides the runtime layer that works consistently across AWS EKS, GCP GKE, and Azure AKS. GitOps pipelines handle deployment delivery to multiple target environments from a single source of truth.

The challenge is that building this system requires upfront engineering investment. You need to design and maintain the control plane, build the multi-environment CI/CD pipeline, handle the cross-account connectivity layer, and build the configuration management system. For most SaaS vendors, this infrastructure work sits outside their core product.

For more on how the control plane and data plane separate across account boundaries, Northflank's BYOC guide covers the underlying architecture in detail, including how cross-account connections are managed without credential sharing.

Before committing the engineering investment, these are the questions worth working through:

• How many enterprise customers in the last 12 months required customer-hosted deployment as a condition of procurement?
• Which compliance frameworks do your target customers operate under?
• How many customer environments do you expect to support in the next 12 to 24 months?
• Are your target customers concentrated on one cloud provider or distributed across AWS, GCP, Azure, or other infrastructure?
• Do you have the engineering capacity to build and maintain a custom control plane?

The answers determine whether the engineering investment in building in-house is proportionate or whether an existing platform covers your requirements.

The terms are used interchangeably in most contexts. BYOC (Bring Your Own Cloud) describes the same deployment model from the customer's perspective. The customer provides their cloud account, and the vendor deploys into it. Customer VPC deployment describes the same model from the vendor's perspective. Both refer to software running inside the customer's cloud account, managed by the vendor through a separate control plane.

Updates are delivered from the vendor's control plane to each customer's application plane through the secure cross-account connection. This requires a CI/CD pipeline that supports multi-environment targeting, progressive rollouts, and rollback on failure. Some customers will also require a change approval step before updates are applied to their environment.

No. Customer VPC deployment runs inside a customer's cloud account on infrastructure managed by a cloud provider such as AWS, GCP, or Azure. On-premises deployment runs on hardware within the customer's own data centre or private infrastructure. The operational challenges differ: on-premises environments often involve air-gapped networks, no managed Kubernetes services, and more restricted connectivity.

Without automation, onboarding a new customer can take several weeks, accounting for infrastructure provisioning, security configuration, networking setup, and testing. The timeline varies depending on the complexity of the customer's environment and their internal approval processes. With a platform that automates provisioning and uses pre-defined application templates, this can be reduced significantly for customers on standard cloud providers.