GitHub environments let you attach required reviewers, branch limits and secrets to a named deployment target such as production. A job that uses the environment must pass those rules before it runs or can read the environment's secrets. For agencies, that keeps production keys out of ordinary builds and out of reach of unreviewed code.
The three secret scopes
GitHub's documentation describes three scopes for Actions secrets.
| Scope | Available to | Who can create it |
|---|---|---|
| Repository | One repository | Write access in an organization repo |
| Environment | Jobs that use that environment, after protection rules pass | Admin access in an organization repo |
| Organization | Repositories chosen by an access policy | Organization owners |
Agencies running many clients in one organization should be wary of organization secrets. A secret shared with all repositories is a secret shared across all clients. Use selected repositories, or better, give each client its own organization or account.
What environment protection offers
From the environments documentation:
- Required reviewers. Up to six people or teams. One approval is enough. You can enable prevent self-review so people cannot approve runs they triggered.
- Wait timer. A delay in minutes before the job proceeds.
- Deployment branches and tags. Limit which branches and tags can deploy to the environment.
- Environment secrets. Only available to jobs that use the environment after the rules pass.
- Administrator bypass. You can turn off the ability for admins to bypass the rules.
On GitHub Free, environments are available only for public repositories, so check your plan before designing around them.
A pattern that works
- Create a staging environment with no reviewers and a production environment with a reviewer from the client or a second agency engineer.
- Restrict production deploys to the main branch.
- Put the hosting token, database URL and API keys in the production environment, not in repository secrets.
- Reference the environment in the deploy job only, never in the test job.
- Turn on prevent self-review so the author cannot approve their own release.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- run: ./deploy.sh
Other secret rules to remember
- Secrets are not passed to workflows triggered from forks, except GITHUB_TOKEN, and are not available to workflows triggered by Dependabot events.
- Secrets are not automatically passed to reusable workflows.
- The documentation recommends OpenID Connect to authenticate to cloud providers where possible, rather than storing long-lived credentials.
- Avoid printing secrets in logs and avoid passing them as command line arguments.
Why clients like it
A reviewer gate gives the client a visible control. They can see who approved each production release. That is easier to explain than "our developers have the keys".
Try it yourself
Click through it at your own pace, or open it full screen.
Open the demo and trace what a failing check blocks. An environment reviewer is the same idea applied at deploy time.
Quick check
Should the client be the required reviewer?
It is one option. Some clients prefer a second agency engineer. Choose whoever can say no, and who will respond within your release window.
Are environment secrets enough on their own?
No. Combine them with branch protection and least privilege tokens. Environment rules do not review the code itself.
Sources
Last reviewed: 19 October 2026.
