Environment Protection Rules

~11 min · protection, approval, branch

Level 0Apprentice

0 XP0/101 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

Gates wrapped around the deploy

An environment can require gates before any job targeting it runs. Configure under Settings → Environments → <name>.

Required reviewers

Up to 6 specific users or teams.
The job pauses; reviewers see a 'Review pending deployments' button.
Reviewer must NOT be the same person who triggered the run (configurable).

Wait timer

Force a delay (0–30 days) between approval and execution.
Used for cooling periods, batch deploys, business-hour windows.

Deployment branch policy

Restrict deploys to specific branches (often main only).
Or to specific tags (v*.*.* for releases).
Without this, a feature branch could deploy to prod by changing one line of YAML.

Custom deployment protection rules (Beta)

Apps that vote on deploys: change-management tickets, observability budgets, etc.
Useful when your gate requires data from outside GitHub.

Code

Job pinned to environment with rules·yaml

  deploy-prod:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://www.example.com
    # required reviewers + branch policy live in repo Settings → Environments
    # The YAML just opts into them by naming the environment.
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh prod

External links

GitHub — Reviewing deployments

Exercise

On a real production environment you control, configure: required reviewers (at least yourself), branch policy of main only, and a 5-minute wait timer. Trigger a deploy from main and verify the gates fire.