GitHub Actions: Scoping environment variables across environments without wildcards

If you're running a monorepo where multiple apps deploy independently through multiple environments, you'll eventually hit a limitation that GitLab CI handles natively: GitHub Actions doesn't support wildcards for environment variable scoping.

In this post, I'll explain why this becomes a real problem and how to work around it using a single repository variable and a jq one-liner.

The Problem

GitHub Actions supports named environments with their own variables and secrets, configured under Settings → Environments. For a single app with testing, staging, and production environments, this works fine - you define your variables three times and you're done.

The problem arises in a monorepo where multiple apps deploy independently, each with its own GitHub environment per tier. Independent per-app environments are useful because they give you fine-grained protection rules: you can require a reviewer for production/apps/dashboard without blocking production/apps/performance. In a reusable deployment workflow, the environment name is dynamic:

jobs:

  deploy:

    environment:

      name: ${{ inputs.environment }}/apps/${{ inputs.name }}

With ten apps and three tiers, you end up with thirty environments:

testing/apps/dashboard

testing/apps/performance

testing/apps/monitoring

...

staging/apps/dashboard

staging/apps/performance

staging/apps/monitoring

...

production/apps/dashboard

production/apps/performance

production/apps/monitoring

...

Variables like AWS_OIDC_IAM_ROLE_ARN, CDK_DEFAULT_ACCOUNT, or DOMAIN are the same for every app within a tier - all staging environments point to the same AWS account and domain. But GitHub has no wildcard scoping, so you can't say "set DOMAIN=staging.example.com for all staging/* environments" in one place.

Without wildcard support, you have two bad options:

1. Define every variable on every environment individually - 30 environments × 15 variables = 450 entries to keep in sync


2. Promote shared variables to the repository level - losing all environment separation

In GitLab, you'd define the variable once with scope staging/* and move on.

The Workaround

Store all environment-tier-specific variables in a single repository variable called ENVIRONMENT_CONFIG as a JSON object:

{

  "testing": {

    "AWS_OIDC_IAM_ROLE_ARN": "arn:aws:iam::111111111111:role/testing-role",

    "CDK_DEFAULT_ACCOUNT": "111111111111",

    "DOMAIN": "test.example.com",

    "COGNITO_USER_POOL": "eu-central-1_abc123",

    "COGNITO_DOMAIN": "auth.test.example.com"

  },

  "staging": {

    "AWS_OIDC_IAM_ROLE_ARN": "arn:aws:iam::222222222222:role/staging-role",

    "CDK_DEFAULT_ACCOUNT": "222222222222",

    "DOMAIN": "staging.example.com",

    "COGNITO_USER_POOL": "eu-central-1_def456",

    "COGNITO_DOMAIN": "auth.staging.example.com"

  },

  "production": {

    "AWS_OIDC_IAM_ROLE_ARN": "arn:aws:iam::333333333333:role/production-role",

    "CDK_DEFAULT_ACCOUNT": "333333333333",

    "DOMAIN": "example.com",

    "COGNITO_USER_POOL": "eu-central-1_ghi789",

    "COGNITO_DOMAIN": "auth.example.com"

  }

}

ENVIRONMENT_CONFIG is a repository variable - not an environment variable - so it's accessible regardless of which GitHub environment the job runs in.

As the first step of the deployment job, extract the right tier and write each key-value pair to $GITHUB_ENV:

- name: Load environment variables from repository variables

  run: |

    echo '${{ vars.ENVIRONMENT_CONFIG }}' | jq -r '.${{ inputs.environment }} | to_entries[] | "\(.key)=\(.value)"' >> $GITHUB_ENV

jq selects the object for the current environment (e.g., staging), converts each entry to KEY=VALUE format, and appends it to $GITHUB_ENV. Everything written to $GITHUB_ENV is available to all subsequent steps.

These vars.* references will be empty at job start - they exist only to document which variables the job expects. The Load environment variables step overwrites them via $GITHUB_ENV.

jobs:

  deploy:

    environment:

      name: ${{ inputs.environment }}/apps/${{ inputs.name }}

    env:

      AWS_OIDC_IAM_ROLE_ARN: ${{ vars.AWS_OIDC_IAM_ROLE_ARN }}

      CDK_DEFAULT_ACCOUNT: ${{ vars.CDK_DEFAULT_ACCOUNT }}

      DOMAIN: ${{ vars.DOMAIN }}

      COGNITO_USER_POOL: ${{ vars.COGNITO_USER_POOL }}

      COGNITO_DOMAIN: ${{ vars.COGNITO_DOMAIN }}

    steps:

      - uses: actions/checkout@v6



      - name: Load environment variables from repository variables

        run: |

          echo '${{ vars.ENVIRONMENT_CONFIG }}' | jq -r '.${{ inputs.environment }} | to_entries[] | "\(.key)=\(.value)"' >> $GITHUB_ENV



      - name: Configure AWS credentials

        uses: aws-actions/configure-aws-credentials@v6

        with:

          role-to-assume: ${{ env.AWS_OIDC_IAM_ROLE_ARN }}

          aws-region: ${{ vars.AWS_DEFAULT_REGION }}

The env: block is evaluated once at job start - at that point vars.AWS_OIDC_IAM_ROLE_ARN is empty. The Load environment variables from repository variables step writes the correct value to $GITHUB_ENV, and all subsequent steps read from there. By the time Configure AWS credentials runs, ${{ env.AWS_OIDC_IAM_ROLE_ARN }} resolves to the correct value for the tier.

When this approach doesn't work:

This workaround is best suited for:

• Non-sensitive configuration values


• Values that change per environment tier, not per app

Consider alternatives if:

• You need to store secrets (use GitHub Secrets instead)


• You have app-specific variables (use environment variables on the GitHub environment)

I hope this post helps you manage environment-specific configuration without drowning in repeated variable definitions.

If you have any kind of feedback, suggestions or ideas - feel free to comment this post!