Environments

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

How environments are represented

Each environment you deploy to has two components:

  • A directory under parameters/<environment>/ that stores Rain configuration files for each template
  • A GitHub Actions variable named <ENV>_AWS_ACCOUNT_ID that the workflow uses when assuming roles via OIDC

When you run ./scripts/deploy-templates.sh -e <environment> the script looks for templates in templates/ and matches them with parameter files inside parameters/<environment>/ using the same base file name.

Adding a new environment

  1. Run the provisioning helper and select the new environment name when prompted. This will scaffold a workflow and parameter folder for you. 
    ./scripts/provision-repo.sh
  2. Open the generated parameter file (for example parameters/staging/oidc-provider.yml) and replace the placeholder SubjectClaimFilters with your repository slug.
  3. In GitHub, add a repository variable named STAGING_AWS_ACCOUNT_ID (or whatever uppercase name matches your folder) along with an AWS_REGION variable if you have not already set one.
  4. Optional: adjust the workflow trigger or schedule in .github/workflows/cloudformation-deploy-staging.yml so it fits your release cadence.

Repeat the process for as many environments as you need. Because the deploy script expects the environment flag, you can run local Rain deployments for each account by swapping -e.

Granting GitHub access via OIDC

The starter kit deploys an OIDC provider stack that trusts the repository you specify. If you want different repositories to deploy to different environments, duplicate the parameter file and narrow the SubjectClaimFilters value to the exact repo:<owner>/<repo>:ref pattern that should assume the role.

For complete details on all parameters, security best practices, and troubleshooting, see the OIDC Provider reference.

Tips for larger organizations

  • Store shared parameters (such as tags or CloudWatch settings) in YAML anchors and import them across parameter files to keep environments consistent.
  • Commit environment folders even if they only contain placeholders. This keeps the Rain script happy and documents which deployments exist.
  • Use branch protection on main so workflows are the only path to production deploys.
  • When testing multiple accounts locally, lean on AWS CLI profile switching so Rain always targets the right credentials.
← Project StructureCI/CD Workflow →