iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To automate deployment with GitHub Actions, put your build, test, and deploy steps in a workflow file, run the deploy step in a job that references a named environment such as production, and let three controls decide who can deploy, when, and with what credentials: the environment’s protection rules, a concurrency group, and OpenID Connect (OIDC) authentication in place of stored cloud keys. GitHub describes the combination this way: “GitHub Actions gives you fine-grained control over deployments with environments, concurrency groups, and protection rules” (GitHub Docs, Deploying with GitHub Actions).
This guide walks through each control in the order you need them, then shows how they fit into one workflow.
Choose the event that starts a deployment
A workflow runs only on the events you list under on:. GitHub’s deployment guide names push, pull_request, and workflow_dispatch among the common triggers. Picking a trigger is a release decision, not a technical one: a trigger that is easy to fire is not automatically safe to connect to production.
| Trigger | Runs when | Suitable for |
|---|---|---|
push |
Commits reach a branch you name under on.push.branches |
Automatic deployment to staging. For production, only if that branch is protected and changes are reviewed before merge. |
pull_request |
A pull request is opened or updated | Build and test checks before merge. Deploying to production from this event is rarely appropriate because the code has not yet been approved. |
workflow_dispatch |
Someone starts the run manually from the Actions tab or through the API | Controlled production releases where a person chooses the moment and, if you add an input, the version. |
Many teams combine these: automatic deploys to staging on push, and a manual workflow_dispatch run that targets production. For the trigger syntax itself, see GitHub Docs, Deployments and environments.
#1 Best Overall
Use environments as the production gate
An environment is a named deployment target, commonly development, staging, or production. A job that references an environment must pass that environment’s protection rules before GitHub sends it to a runner. Environment secrets are also withheld until those rules pass, which is why an environment is the right place to keep production credentials.
To create one:
- Open your repository and go to Settings > Environments.
- Select New environment, enter
production, and save. - Under Deployment branches, choose selected branches and add only the branch you release from, such as
main. - Enable Required reviewers and add the people who must approve a production release.
- Under Environment secrets, add the credentials that only the production job needs.
GitHub’s interface labels can change, so match the wording you see on screen. The environment concept itself is described in GitHub Docs, Deployment environments.
Protection rules you can apply
| Protection | What it does | Practical note |
|---|---|---|
| Required reviewers | The job waits until a listed reviewer approves it | Use it for production. Approval is per run, so each release needs its own sign-off. |
| Wait timer | Delays the job by a set number of minutes after it is queued | Gives time to cancel a mistaken release. It does not verify anything. |
| Deployment branches | Limits which branches may deploy to the environment | Prevents a feature branch from reaching production even if a workflow references the environment. |
| Custom deployment protection rules | Calls a GitHub App that approves or rejects the deployment | Listed as public preview in GitHub’s documentation at the time of writing. Confirm its current status before depending on it. |
Some environment features depend on repository visibility and your GitHub plan. Check GitHub Docs, Deployments and environments for the current availability of each rule before designing your release process around it.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Prevent overlapping deployments with concurrency
A concurrency group allows only one job or workflow that uses that group to run at a time. GitHub specifically recommends it for keeping an environment to one deployment in progress, which prevents two releases from racing to update the same target.
jobs:
deploy-production:
runs-on: ubuntu-latest
environment: production
concurrency:
group: deploy-production
cancel-in-progress: falseThe cancel-in-progress setting matters. With false, a deployment already running finishes, and a new run waits. With true, GitHub cancels the running deployment when a newer one arrives, which can leave a target half-updated. For deployments, false is the safer default. GitHub keeps only one pending run per group, so if several runs queue behind a running deployment, the older pending ones are superseded by the newest.
Replace stored cloud keys with OIDC
OIDC lets a workflow obtain short-lived access to a supported cloud provider without storing a long-lived access key as a GitHub secret. Each run presents a token that identifies the repository, branch or environment, and workflow. The cloud provider checks that identity against a trust policy and issues temporary credentials if it matches.
Setting it up involves four steps:
- Register GitHub as an identity provider in your cloud account. GitHub’s guide for configuring OpenID Connect in cloud providers covers the general pattern, and the OpenID Connect reference lists the token claims you can match on.
- Add a trust policy condition. Without at least one condition, any repository could request a token that your account accepts. Restrict the trust to your repository and to the environment, for example a subject claim that matches
repo:your-org/your-repo:environment:production. Confirm the exact claim format in the OIDC reference, since it varies by provider. - Grant the job permission to request a token. Add
id-token: writeat the job level. This permission lets the job fetch the OIDC token. It does not itself grant write access to any cloud resource; the role your cloud account assigns controls that. - Exchange the token and keep the role narrow. Use a provider action to trade the GitHub token for cloud credentials. Give the assumed role only the permissions the deployment needs.
Example: AWS
GitHub documents a specific path for configuring OpenID Connect in Amazon Web Services. In the workflow, the aws-actions/configure-aws-credentials action performs the token exchange and returns temporary AWS credentials for later steps. Other providers follow the same logic with their own actions and trust settings.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Example: Azure
GitHub’s continuous deployment guide points to Azure Web App workflow templates and provider-specific actions. Token lifetime and exchange details differ by provider, so follow the provider’s own setup for the federated credential.
When you must use stored secrets
If a provider does not support OIDC for your target, stored secrets are the fallback. Keep them contained:
- Store each secret at the narrowest scope that works: environment first, then repository, then organization. GitHub encrypts secrets before they reach its servers, but scope still determines who can use them.
- Expose a secret only to the step that needs it, rather than as a workflow-wide environment variable.
- Rotate keys on a schedule and remove them when a target is retired.
If your deployment runs on self-hosted runners, treat secrets with extra care. GitHub’s secrets and deployment references note that self-hosted runners do not run in isolated containers, even when you use environments, so a compromised job on that machine can reach what the job can reach. See GitHub Docs, Secrets.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Put the pieces together
The workflow below combines the trigger, build gate, environment, concurrency group, and OIDC exchange. Replace the build commands, the role ARN, and the region with your own values. It is an illustration of structure, not a tested configuration for your stack.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →name: Deploy
on:
push:
branches: [main]
workflow_dispatch:
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
deploy-production:
needs: build
runs-on: ubuntu-latest
environment: production
concurrency:
group: deploy-production
cancel-in-progress: false
permissions:
contents: read
id-token: write
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/github-production-deploy
aws-region: us-east-1
- run: ./deploy.shBecause the production job references environment: production, the reviewer requirement and branch restriction apply before the job starts. The build job runs first, so an untested commit never reaches the deploy step. Keeping push to main in this file is safe only if main is protected and merges are reviewed; otherwise, remove the push trigger and rely on workflow_dispatch.
Quick Recap
Troubleshoot common deployment failures
- The job shows as waiting and never starts. A protection rule is unsatisfied. Check whether a required reviewer has approved the run and whether the branch is allowed under the environment’s deployment branches.
- An environment secret is empty. Environment secrets are not released until the protection rules pass. Confirm the job has reached the approved state and references the correct environment name.
- The cloud provider rejects the token. The trust policy condition probably does not match the token’s claims. Compare the repository, branch or environment, and claim format against the values in the OIDC reference.
- A deployment is canceled or two appear to run together. Check the concurrency group name. Groups must match exactly across workflows that should queue behind each other, and
cancel-in-progressshould befalsefor production.
Pre-release checklist
- Production deploys only from a protected branch or a manual dispatch.
- The
productionenvironment has required reviewers and a deployment branch restriction. - The deploy job has a concurrency group with
cancel-in-progress: false. - Cloud access uses OIDC with a trust condition scoped to the repository and environment, or stored secrets are limited to the environment that uses them.
- The job’s
id-token: writepermission is paired with a cloud role that grants only deployment actions. - Self-hosted runners, if used, are dedicated to deployment and trusted for the secrets they receive.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
