Create Development, Staging, and Production Environments

Architecture Overview

This architecture creates three isolated environments that share the same infrastructure definition but differ in sizing, availability, and configuration. The development environment runs minimal resources for fast iteration. The staging environment mirrors production’s configuration at a smaller scale for validation testing. The production environment runs with full high-availability, autoscaling, and monitoring. All three environments deploy from the same infrastructure code, ensuring consistency.

The key principle is that environments differ in parameters, not in architecture. The same Pulumi program defines all three environments using configuration values that control instance sizes, replica counts, database tiers, and monitoring thresholds. This means a change that works in staging will behave the same way in production, eliminating the “works in staging but breaks in production” class of issues.

Network isolation prevents accidental cross-environment communication. Each environment runs in its own VPC or virtual network with no peering or shared subnets. This prevents a development workload from accidentally connecting to a production database, and it satisfies compliance requirements that mandate environment separation. DNS and service discovery are scoped per environment so service names resolve to the correct environment’s resources.

Environment Sizing

Each environment gets resource configurations appropriate to its purpose. Development environments use the smallest viable instance types and single replicas to minimize cost while remaining functional for testing. Staging uses mid-tier resources with enough capacity to run realistic load tests. Production uses the largest instances, multiple replicas, multi-AZ deployments, and autoscaling to handle real traffic.

Network Isolation

Each environment runs in its own network space with independent address ranges, security groups, and routing tables. There are no network paths between environments, which prevents accidental data leakage and limits the blast radius of security incidents. External access controls (like VPN requirements for development environments) add another layer of separation.

Promotion Workflow

The promotion workflow defines how changes move from development through staging to production. Infrastructure changes are first applied to the development environment, where developers verify basic functionality. After validation, the same changes are promoted to staging for integration testing and stakeholder review. Finally, after approval, changes are applied to production. Each promotion step uses the same infrastructure code, only changing the target stack and its configuration values.

Common Customizations

• Add ephemeral environments: Extend the prompt to create short-lived environments for each pull request, automatically destroyed when the PR is closed.
• Add database seeding: Request scripts that populate development and staging databases with realistic test data so developers can work with representative datasets.
• Add cost controls: Ask for development environments that automatically shut down outside business hours and staging environments that scale down on weekends.
• Add feature flags: Request a feature flag configuration that lets you enable or disable features per environment without redeploying.