When teams are setting up their infrastructure on Aptible, one of the first architecture questions they tend to ask is deceptively simple: should staging and production live together, or should they be separated?

There isn’t a universal answer, because the right setup depends on what kind of isolation the team needs, what type of data staging will handle, how closely staging mirrors production, and how much operational overhead the team is willing to take on. For many teams, staging should look and behave enough like production to provide meaningful release confidence. For others, staging can be lighter-weight because it only uses synthetic or non-sensitive data.

On Aptible, the decision becomes clearer once you understand the distinction between Stacks and Environments. Stacks provide the infrastructure and network boundary; environments provide local organization, access control, backup policies, and operational separation. In other words, Environments help you govern resources while Stacks help you isolate them.

Understanding Stacks and Environments

Stacks

An Aptible Stack is the underlying infrastructure where your apps and databases run. It includes the virtualized infrastructure, private network, and region-specific resources that support your workloads. Because Stacks define the network boundary, resources in different stacks cannot communicate with each other unless a network integration (like VPC peering) is configured.

Aptible offers Shared Stacks and Dedicated Stacks; Shared Stacks are used across multiple Aptible customers and are best suited for development, testing, and low-risk staging workloads that use synthetic or non-sensitive data. Dedicated Stacks, by contrast, are isolated to a single customer and are designed for production and compliance-sensitive workloads. These provide stronger tenancy, network-level isolation, availability, advanced connectivity options (like VPN tunnels and VPC peering), and Aptible’s built-in security controls. They’re also where Aptible can support HIPAA BAA coverage for environments that process PHI (note: BAAs are now executed in-app).

Because a Dedicated Stack gives your production workloads their own Stack-level boundary, it carries more cost than running on shared infrastructure (this is the main reason for the Production plan’s platform fee). That’s why it’s important to be intentional about where you use Dedicated Stacks; we recommend them for production systems, regulated workloads, staging environments that handle production-like sensitive data, or cases where staging and production need stronger separation. For lower-risk dev and testing workloads, Shared Stacks or separate Environments may be a better fit.

TL;DR: Dedicated Stacks are the recommended home for production and production-like workloads. Shared Stacks are best suited for lower-risk development, testing, and staging workloads that use synthetic or non-sensitive data.

Environments

An Aptible Environment is a logical grouping of apps and databases within a Stack; this is where teams manage user access, backup retention policies, activity reporting, and day-to-day resource organization. A team might have separate Environments for development, staging, and production, each with different permissions and operational practices.

The main nuance between the two (Stacks and Environments) is that Environments don’t provide network-level isolation from each other if they are in the same Stack. Two Environments in the same Stack are logically separated, sure, but they still share that Stack’s network and underlying infrastructure. That distinction will be helpful in choosing the right architecture for your unique workloads.

TL;DR: use Environments to organize and govern resources; use Stacks to isolate infrastructure and networks.

Why staging and production separation matters

Staging environments are meant to reduce production risk. Teams use staging to test new code, configuration changes, migrations, background jobs, dependency upgrades, and operational procedures before those changes reach users. The more production-like staging is, the more confidence it can provide.

But staging can also introduce risks of its own. It may be used for experimental work, load testing, one-off scripts, or changes that are not yet fully understood. It may have broader developer access than production. It may also run with less restrictive operational controls.

In Aptible, if staging and production are in the same Stack, they are separated by Environment. They can have different access controls, backup policies, and operational practices, but they still share the same Stack-level infrastructure and network boundary. For many teams, this is the recommended balance: staging is close enough to production to provide meaningful confidence, while still being logically separated from production day to day.

For teams with stricter compliance, security, or reliability requirements, it may be important to create a stronger boundary between staging and production. That’s where separate Dedicated Stacks come in. And for teams whose staging workloads are lightweight and use only synthetic or non-sensitive data, a Shared Stack can still be a practical lower-cost option.

Ultimately, the staging vs. production decision is about how much production parity and isolation your team needs. Below are the three patterns we most often see.

Option 1: staging and production in separate Environments within one Dedicated Stack

For many teams, this is the recommended starting point: run staging and production in separate Environments within the same Dedicated Stack.

This model works best when staging needs to behave like production. For example, a team may use staging to test production database restores, validate migrations against realistic data, test configuration changes, or confirm performance characteristics in the same infrastructure class as production. Keeping staging and production in the same Dedicated Stack gives staging the closest day-to-day alignment with production without requiring a second Dedicated Stack.

The main advantage of this model is balance. Staging gets the benefits of Dedicated infrastructure (stronger tenancy, production-grade security controls, BAA eligibility for PHI workloads, and advanced connectivity options) while Environments still let teams manage staging and production separately through access controls, backup policies, and operational practices.

The tradeoff is that this is logical separation, not full Stack-level isolation. Staging and production are separated by Environment, but they still share the same underlying Stack boundary. For many teams, that’s acceptable and preferred. But if the goal is to ensure staging and production do not share infrastructure or network space, separate Dedicated Stacks are the better fit.

Option 2: separate Dedicated Stacks for staging and production

The strongest isolation model is to use separate Dedicated Stacks for staging and production. This gives each environment its own infrastructure and network boundary.

This approach is the right fit when a team has strict compliance obligations, customer-contract requirements, internal security policies, or a low tolerance for production blast radius. It can also make sense when staging runs intensive tests, experiments with infrastructure-level changes, or needs Stack-level configurations that differ from production.

The tradeoff is cost and operational complexity. Each Dedicated Stack has its own cost, and communication between Stacks requires network integrations. There may also be more to coordinate when migrating resources, managing access, configuring integrations, or maintaining parity between staging and production.

For teams that need true network segmentation between staging and production, that overhead can be worth it. For teams that mainly need production-like staging and separate access controls, one Dedicated Stack with separate Environments is usually the simpler recommendation.

Option 3: Shared Stack for staging, Dedicated Stack for production

A lower-cost option is to keep development and staging on a Shared Stack while running production on a Dedicated Stack.

This model works only when staging is truly low-risk: it uses synthetic, anonymized, or non-sensitive data; does not need to mirror production infrastructure closely; and is primarily used for functional testing, QA, or release validation. In that case, putting staging on Dedicated infrastructure may be more than the team needs.

The main advantage is cost efficiency and simplicity. Staging can remain lightweight, while production gets the isolation and compliance posture of a Dedicated Stack.

The downside is fidelity and isolation. Because Shared Stacks are shared infrastructure and Dedicated Stacks are single-customer infrastructure, staging may not represent production from a performance, networking, or operational perspective. Shared Stack staging also should not be used for PHI, PII, production database restores, or regulated workflows.

This option is best treated as a cost-conscious fallback for low-risk staging, not the default recommendation for teams that need production-like staging or strong separation from production.

Choosing the right model

The best choice for your team typically becomes clear after asking a few questions:

• Will staging process sensitive or regulated data? If yes, staging should not run on a Shared Stack. It should be in a Dedicated Stack, either alongside production in a separate Environment or in its own separate Stack.

• Does staging need to mirror production closely? If you’re using staging to validate production database restores, migrations, performance characteristics, or customer-impacting changes, it should run on Dedicated infrastructure. If staging is mostly used for lightweight functional testing with synthetic or non-sensitive data, then a Shared Stack may be sufficient.

• How much isolation do you need between staging and production? If the concern is primarily who can access which resources, Environments can solve that. If the concern is network or infrastructure separation, Stacks are the boundary you need.

• How much operational overhead and cost can I justify? A single Dedicated Stack with multiple Environments can be a good balance for many teams. Separate Dedicated Stacks provide stronger isolation, but they also add cost and complexity.

Migration considerations

Teams often evolve their Stack strategy over time. Some start on Shared Stacks for early development and later move production, or production-like staging, onto Dedicated infrastructure. Others start with one Dedicated Stack and later add a second Dedicated Stack when compliance, customer-contract, or isolation requirements increase.

That’s a normal path, but migrations should be planned carefully. Teams should confirm which apps and databases need to move, whether staging and production should move together or separately, what downtime window is acceptable, and who will validate the application after the migration.

Region is also an important consideration; if a source environment is in one AWS region and the destination Dedicated Stack is in another, the migration path may not be so simple. In some cases, resources may need to be recreated or migrated differently.

We also recommend reviewing network dependencies before migrating. If vendors, partners, or internal systems rely on IP allowlists, those may need to be updated to include the appropriate Stack IP addresses. If workloads in different Stacks need to communicate, a network integration may be required.

Recommended starting points

A useful way to decide is to start with two questions: what kind of data will each environment handle, and how much isolation do you need between staging and production?

Most teams should start with Option 1: separate staging and production Environments within one Dedicated Stack. This gives staging a production-like foundation while keeping cost and complexity lower than running two Dedicated Stacks.

Move to Option 2: separate Dedicated Stacks when you need true network/infrastructure segmentation between staging and production.

Use Option 3: Shared Stack staging + Dedicated Stack production only when staging is low-risk, uses synthetic or non-sensitive data, and does not need to closely mirror production.

TL;DR: start with the lowest-complexity option that satisfies your data, compliance, and isolation requirements. Move up the isolation ladder only when the risk profile of staging or production requires it.

Wrapping up

There’s no single best setup for every team. The right answer depends on the data being processed, the team’s compliance obligations, and the level of separation required between staging and production.

If you’re a current Aptible customer considering migrating to or from a Dedicated Stack, contact Aptible Support. If you’re exploring Aptible and want to see which setup is best for you, we’d love to help. Book time with our customer success team here.