Using GitHub Actions Environments and Approvals
Add a human approval gate to production without leaving GitHub.
GitHub Actions environments let you scope secrets, add protection rules, and require a manual approval before a job runs. They are the building block for continuous delivery: production deploys wait for a reviewer to click approve. This lesson configures an environment with required reviewers and environment-scoped secrets.
What an environment is
An environment (for example staging or production) is a named target you reference from a job with the environment: key. It carries its own secrets and protection rules, such as required reviewers and wait timers, which gate any job that targets it.
Creating the environment
- Go to Settings -> Environments and create one named
production. - Add Required reviewers (up to 6 people or teams) who must approve each deployment.
- Optionally add a Wait timer to enforce a cool-down before the job proceeds.
- Add environment secrets that exist only for jobs targeting this environment.
Referencing it in a job
Set environment: production on the deploy job. When the job is reached, GitHub pauses it and requests approval from the required reviewers before any step runs.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- run: ./deploy.sh
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}Environment secrets vs repository secrets
A secret defined on the production environment is only available to jobs that declare environment: production. This lets you keep production credentials away from PR builds and staging jobs entirely, which is a meaningful least-privilege win.
Key takeaways
- Environments add protection rules like required reviewers and wait timers to a deploy job.
- Reference an environment with
environment: production; the job pauses for approval before any step runs. - Environment secrets are scoped to jobs targeting that environment, improving least privilege.