Environments: dev, stage, prod
Separate environments let you test changes safely before they reach real users.
You almost never deploy straight to production. Instead you promote a change through a series of environments, each a copy of your app with its own configuration and data.
The common three
- Development (dev) — where engineers experiment. Broken things are expected here.
- Staging (stage) — a near-identical mirror of production used for final testing and QA.
- Production (prod) — the live environment real users touch. Treat it with respect.
Keep them isolated
Each environment should have its own AWS account or at least its own resources, credentials, and databases. A mistake in dev must never be able to corrupt prod data. Configuration (URLs, secrets, feature flags) changes per environment, but the code should be identical as it is promoted upward.
Example
# Environment is chosen by config, not by code branches
export APP_ENV=staging
export DATABASE_URL=$(aws ssm get-parameter --name /app/staging/db-url --with-decryption --query Parameter.Value --output text)When to use it
- A QA engineer tests a new payment feature in the staging environment against a copy of production data before approving the release.
- A team uses separate AWS accounts for dev, stage, and prod so a broken dev deploy cannot affect live customers.
- A feature flag service reads the ENVIRONMENT variable to enable experimental features only in dev and stage.
More examples
Export environment variable per stage
Uses shell environment variables to control which AWS profile and config the deploy script targets.
# Set the active environment before running deploy scripts
export APP_ENV=staging
export AWS_PROFILE=myapp-staging
echo "Deploying to: $APP_ENV"Read config from SSM by env prefix
Fetches environment-specific config from SSM by using the environment name as a path prefix.
ENV=${APP_ENV:-dev}
# Read config from the correct SSM prefix for this environment
DB_URL=$(aws ssm get-parameter \
--name "/${ENV}/app/database_url" \
--with-decryption \
--query 'Parameter.Value' \
--output text)Promote Docker image from stage to prod
Promotes the exact same Docker image that passed staging tests to production, avoiding a risky rebuild.
# Re-tag the exact staging image for production
STAGE_IMAGE=123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:staging-${GIT_SHA}
PROD_IMAGE=123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:prod-${GIT_SHA}
docker pull $STAGE_IMAGE
docker tag $STAGE_IMAGE $PROD_IMAGE
docker push $PROD_IMAGE
Discussion