GitHub Actions Environments: Approvals, Secrets & Deployment

GitHub Actions environments add deployment controls to your workflows, including required reviewers, wait gates, environment-specific secrets, and deployment branch policies.

What You'll Learn

In this tutorial, you'll learn how to create environments in GitHub, configure approval requirements, use environment-specific secrets, protect production branches, and view deployment history.

Why It Matters

Deploying to production without safeguards is risky. Environments give you a safety net: production deployments require approval from a specific team, can only deploy from the main branch, and use different secrets than staging. This prevents accidental or unauthorized deployments.

Real-World Use

Durga Antivirus Pro uses environments for three deployment tiers. The development environment deploys automatically on every push. The staging environment requires CI tests to pass. The production environment requires two approvals from senior engineers and can only deploy from the main branch.

Defining an Environment

Configure the environment in the workflow:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    steps:
      - run: echo "Deploying to production"

Environment Configuration (in GitHub UI)

• Required reviewers -- 1-6 people who must approve
• Wait timer -- delay before deployment (minutes)
• Deployment branches -- restrict which branches can deploy
• Environment secrets -- secrets scoped to this environment

Environment Secrets

Store secrets per environment instead of Repository-wide:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./deploy.sh
        env:
          API_KEY: ${{ secrets.PRODUCTION_API_KEY }}
          DB_URL: ${{ secrets.PRODUCTION_DATABASE_URL }}

Staging uses the same secret names but different values:

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: ./deploy.sh
        env:
          API_KEY: ${{ secrets.STAGING_API_KEY }}

Deployment Protection Rules

Required Approvers

When a job targets an environment with required reviewers, it pauses and waits for approval:

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production
    # Workflow pauses here until approved
    steps:
      - run: echo "Deploying to prod"

Viewing Deployment History

GitHub shows deployments in the Repository Insights tab and on Pull Request pages with deployment status.

Practice Questions

1. What does a required reviewer do in an environment? They must approve the deployment before the job proceeds. The workflow pauses until approval is given.

2. How are environment secrets different from Repository secrets? Environment secrets are scoped to a specific environment and are only accessible when that environment is targeted.

3. What is a deployment branch policy? It restricts which branches can deploy to an environment. For example, only the main branch can deploy to production.

4. How do you specify a deployment URL? Set the url field under the environment key in the job configuration.

5. Challenge: Create three environments named dev, staging, and production. Configure production to require one approval and restrict it to the main branch. Write a workflow that targets each environment.

Mini Project: Protected Deployment Pipeline

Build a workflow with three deployment jobs. The dev environment deploys automatically. The staging environment requires passing tests. The production environment requires two approvals and can only deploy from the main branch. Use different secrets for each environment.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.