A protection rule is a deployment control attached to a GitHub Actions environment. A job targeting that environment waits until its required conditions are satisfied, turning a release pipeline into a visible, controlled sequence rather than an automatic path from workflow trigger to deployment. section 1.2
Use protection rules to gate access to sensitive deployment targets and their environment secrets. Available controls include manual approval, wait timers, and deployment restrictions; an environment can also limit jobs to particular branches or tags. This makes the environment a boundary around the deployment job, not merely a workflow label. section 1.2 section 9.3.3
Choose a gate that matches the deployment risk:
- Require manual approval before a job proceeds when a person must validate a release. section 6.2
- Add a wait timer when deployment should pause before continuing. section 1.2
- Restrict eligible branches and tags so only approved release references can deploy or access environment secrets. section 9.3.3
- Use a custom protection rule when an external check, run by a GitHub App, must complete successfully. section 6.2
Gate an OIDC-enabled deployment environment
When an environment is used by a workflow that authenticates through OpenID Connect, add protection rules before permitting deployment or access to that environment’s secrets. Restrict deployments to the intended branches or tags, then require approval or a successful custom check for the protected job. This adds a deployment gate alongside the OIDC policy. section 9.3.3 section 6.2
Protection rules are especially important for self-hosted runners. A protected job can be held until stringent automated and manual checks have passed, reducing the chance that an unsafe workflow reaches a runner with sensitive deployment access. GitHub also blocks workflows from forks or new contributors in the described scenario, providing a separate safeguard. section 6.2
Figure 6.12 Environment protection rules
Inspect the environment protection-rule settings as a visual reference for placing approvals and custom checks around a deployment job. section 6.2
Treat protection rules as part of deployment design: connect jobs through workflow dependencies where needed, target the appropriate environment, and make the gate proportionate to the access granted after it passes. A rule is useful only when the protected job cannot proceed before its required approval, timer, restriction, or custom check succeeds. section 1.2 section 6.2
