Deployment approvals are configured entirely through GitHub's native environment settings — there's nothing new to adopt. This keeps your audit surface small, works within your existing compliance tooling, and means your team manages approvals with the same GitHub UI they already know.

In your repository settings, navigate to Environments and create environments that match your deployment targets (e.g., production, staging, development). See Using environments for deployment in the GitHub docs for details.

For each environment that requires approval, configure deployment protection rules:

In your GitHub Actions workflow file, reference the environment in the job that runs terraform apply:

jobs:
  apply:
    runs-on: ubuntu-latest
    environment: ${{ inputs.github_environment }}
    steps:
      - uses: actions/checkout@v4
      - name: Apply
        env:
          COMPONENT: ${{ inputs.component }}
          STACK: ${{ inputs.stack }}
        run: atmos terraform apply "${COMPONENT}" -s "${STACK}"

Notice that environment uses ${{ inputs.github_environment }} rather than a hardcoded value. Atmos Pro passes the environment name through from your stack configuration when it dispatches the workflow, so the same workflow file works across all your environments. The environment is configured in your Atmos stack YAML — not in the workflow itself — which means you can dynamically target different GitHub environments based on the stack being deployed.

When Atmos Pro dispatches this workflow, GitHub will automatically enforce the protection rules for the target environment before the job runs.

The most common pattern is to require approvals only for production while allowing staging to deploy automatically:

For critical infrastructure components, you can create separate environments with stricter approval requirements: