Atmos Pro integrates with GitHub Environments to give your team control over when infrastructure changes are applied. By configuring deployment protection rules on your GitHub environments, you can require manual approval from designated reviewers before any Terraform apply runs.

This is especially important for production environments where infrastructure changes can have significant impact. With deployment approvals, your team gets an explicit gate between a successful plan and the actual apply — ensuring that changes are reviewed and approved by the right people before anything is provisioned.

Deployment approvals are powered entirely by GitHub's native environment protection rules. Atmos Pro dispatches workflows that target GitHub environments, and GitHub enforces the protection rules you've configured.

Atmos Pro dispatches workflows and tracks their status — it does not implement its own approval mechanism. Approvals are handled entirely by GitHub, which means:

This design keeps Atmos Pro focused on orchestration while leveraging GitHub's mature, well-understood approval infrastructure.

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
        run: atmos terraform apply ${{ inputs.component }} -s ${{ inputs.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: