Stack Strategies

A stack strategy controls how your environments are grouped into CloudFormation stacks. It determines the level of isolation between environments and affects cost, blast radius, and infrastructure complexity.

You choose a strategy when creating a project. Once services exist, the strategy is locked — see Changing Strategy below.

Strategy Comparison

Shared

All environments are deployed into a single CloudFormation stack and share one ECS cluster, one ALB, and one RDS instance.

Consider a project myapp with two services: web (deploys to dev, stage, prod) and api (deploys to dev, prod):

myapp-shared              ← ECR repos, OIDC, IAM (always present)
myapp-nonprod-services    ← web×dev, web×stage, web×prod, api×dev, api×prod (1 ALB, 1 cluster)
myapp-persistence         ← 1 RDS instance (all envs share)

All five service-environment combinations live in the same services stack. A failing stack update affects every environment.

Best for: Solo developers, early-stage projects, non-critical workloads where cost matters more than isolation.

Split

Non-production environments share one stack. Production environments get their own stack with a dedicated ECS cluster, ALB, and database.

Same project — web (dev, stage, prod) and api (dev, prod):

myapp-shared              ← ECR repos, OIDC, IAM
myapp-nonprod-services    ← web×dev, web×stage, api×dev (1 ALB, 1 cluster)
myapp-prod-services       ← web×prod, api×prod (1 ALB, 1 cluster)
myapp-nonprod-persistence ← 1 RDS instance (dev + stage)
myapp-prod-persistence    ← 1 RDS instance (prod only)

Notice that api is not in the stage stack because it only declares dev and prod environments. Each service deploys only to the environments it declares.

Best for: Most production workloads. Good balance of cost and safety — production is fully isolated from non-production, while dev and staging share infrastructure.

Isolated

Every environment gets its own CloudFormation stack, ECS cluster, ALB, and database. No infrastructure is shared between environments.

Same project:

myapp-shared              ← ECR repos, OIDC, IAM
myapp-dev-services        ← web×dev, api×dev (1 ALB, 1 cluster)
myapp-stage-services      ← web×stage (1 ALB, 1 cluster)
myapp-prod-services       ← web×prod, api×prod (1 ALB, 1 cluster)
myapp-dev-persistence     ← 1 RDS instance (dev only)
myapp-stage-persistence   ← 1 RDS instance (stage only)
myapp-prod-persistence    ← 1 RDS instance (prod only)

Again, api is absent from the stage stack because it doesn't declare that environment.

Best for: Regulated industries, large teams, or when you need independent scaling and rollback per environment. Highest cost due to separate ALB, cluster, and RDS per environment.

Per-Service Environment Subsets

Stack strategy is a project-level setting, but each service can deploy to a different subset of the project's environments. When you create a service, you pick which environments it deploys to.

For example, a project with environments dev, stage, prod might have:

• web deploying to all three
• api deploying to only dev and prod
• worker deploying to only prod

The strategy determines how those environments are grouped into stacks, but services only appear in the stacks for the environments they declare.

Full Per-Service Isolation

If you need completely separate infrastructure per service (separate ALBs, clusters, and databases for each service), create a separate project for each service and use the Isolated strategy. This gives you independent stacks, independent deployments, and independent teardown per service.

Cost Estimation

Approximate base costs for a project with 3 environments (dev, stage, prod) and a database:

Actual cost varies by instance size, traffic, and additional resources. These estimates assume db.t4g.micro instances and minimal traffic.

Production Environment Classification

By default, environments named prod or production are treated as production. You can override this per-project in Project Settings > Production Environments.

For example, setting production environments to prod, staging would give staging the same isolation treatment as prod when using the Split strategy.

This affects:

• Which stack group an environment is placed in (Split and Isolated strategies)
• Database defaults (instance class, multi-AZ, backup retention)
• Log retention periods (90 days for production, 30 days for non-production)

Shared Infrastructure

Regardless of strategy, all environments share a shared stack ({project}-shared) that contains:

• ECR repositories (one per service)
• OIDC provider for GitHub Actions authentication
• IAM roles for CI/CD

These resources are environment-agnostic and safe to share.

SSM Parameter Paths

Stack strategy affects how database credentials are stored in AWS Systems Manager Parameter Store:

Split and Isolated use environment-scoped paths so each environment's database credentials are separate.

Changing Strategy

Stack strategy is locked once your project has services. CloudFormation stacks are named based on the strategy, and changing the naming scheme after stacks are created would cause mismatched or orphaned infrastructure.

To change strategy:

1. Tear down all services in the project
2. Go to Project Settings and select the new strategy
3. Re-create your services

Consider your strategy choice carefully during project setup.

Related

• Environments — how environments work in StrictOps
• Deployments — the deployment lifecycle
• strictops.yml — configuration reference