# Using GitHub Actions Environments and Approvals

> Configure GitHub Actions environments with required reviewers, wait timers, and environment secrets to add manual approval gates to production deployments.

Source: https://latchkey.dev/learn/course-cicd/using-github-actions-environments-and-approvals-tutorial  
Updated: 2026-06-26

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.

```.github/workflows/deploy.yml
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.

## FAQ

### Using GitHub Actions Environments and Approvals?

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.

### 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.

### 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt