Environments

Model each deployment target with dedicated parameter packs and GitHub variables.

Overview

Each environment you deploy to has two components: a parameter directory and a GitHub Actions variable. The deploy script matches templates with their environment-specific parameters.

How environments work

ComponentLocationPurpose
Parameter directoryparameters/<env>/Rain configuration files for each template
GitHub variable<ENV>_AWS_ACCOUNT_IDAccount ID for OIDC role assumption
Workflow file.github/workflows/cloudformation-deploy-<env>.ymlCI/CD pipeline

When you run ./scripts/deploy-templates.sh -e <env>, the script matches templates in templates/ with parameter files in parameters/<env>/ using the same base filename.

Adding a new environment

  1. Run the provisioning helper:
./scripts/provision-repo.sh

Select your environment name when prompted.

  1. Edit the parameter file:

Open parameters/<env>/oidc-provider.yml and replace the placeholder SubjectClaimFilters with your repository slug.

  1. Add GitHub variables:

In your repository settings, add:

  • <ENV>_AWS_ACCOUNT_ID (e.g., STAGING_AWS_ACCOUNT_ID)
  • AWS_REGION (if not already set)
  1. Optional: Customize the workflow:

Edit .github/workflows/cloudformation-deploy-<env>.yml to adjust triggers or scheduling.

Repeat for each environment you need.

Granting GitHub access via OIDC

The OIDC provider stack trusts the repository you specify. To allow different repositories to deploy to different environments, duplicate the parameter file and narrow the SubjectClaimFilters value:

# Narrow to specific branch
SubjectClaimFilters: repo:my-org/my-repo:ref:refs/heads/main

# Or specific environment
SubjectClaimFilters: repo:my-org/my-repo:environment:production

See the OIDC Provider reference for all parameters and security best practices.

Multi-account deployment

Each workflow uses different:

  • IAM role ARNs (different account IDs)
  • GitHub variables (per-environment)
  • Parameter files

Tips for larger organizations

  • Shared parameters: Use YAML anchors to share common values (tags, CloudWatch settings) across parameter files
  • Document environments: Commit parameter folders even if they only contain placeholders
  • Protect production: Use branch protection so workflows are the only path to production deploys
  • Local testing: Use AWS CLI profile switching to test deployments across accounts

Next steps

← Project StructureCI/CD Workflows →