Vishwark

Posted on Dec 25

GitHub Actions: From Zero to Production(EP5)

#githubactions #frontend #github #cicd

Episode 5 – Secrets, Variables & Environments (Security Done Right)

So far in this series, we’ve learned:

how GitHub Actions workflows are structured
when workflows run
where jobs execute
how actions are reused

Now it’s time to talk about security.

This episode focuses on something every real-world pipeline needs but beginners often misuse:

Secrets, variables, and environments

Understanding this properly is what separates toy pipelines from production-ready CI/CD.

Why This Topic Matters

Your GitHub Actions workflow can:

deploy to production
publish packages
access cloud infrastructure
modify repositories

That means:

If secrets are handled incorrectly, the entire system is at risk.

1️⃣ Secrets vs Variables (Core Difference)

🔹 Variables

Variables are non-sensitive configuration values.

Examples:

Node version
App name
Feature flags
API base URLs

They are:

stored in plain text
safe to log
meant for configuration

Example usage:

env:
  NODE_VERSION: ${{ vars.NODE_VERSION }}

🔹 Secrets

Secrets are sensitive credentials.

Examples:

API keys
Tokens
Passwords
Cloud credentials

They are:

encrypted at rest
masked in logs
injected only at runtime
never readable after creation

Example usage:

env:
  API_KEY: ${{ secrets.API_KEY }}

👉 Rule of thumb
If leaking it is bad → it must be a secret.

2️⃣ Where Can Secrets Live?

GitHub allows secrets at three levels.

🟨 Organization Secrets

Shared across multiple repositories
Lowest priority
Useful for common credentials

🟦 Repository Secrets

Scoped to one repository
Most commonly used
Good for CI pipelines

🟥 Environment Secrets (Most Important)

Scoped to an environment (staging, production)
Can have protection rules
Ideal for deployments

👉 Priority order:

Environment > Repository > Organization

3️⃣ How Secrets Are Accessed in Workflows

Secrets are always accessed like this:

${{ secrets.SECRET_NAME }}

Example:

- run: curl -H "Authorization: Bearer ${{ secrets.API_KEY }}" api.example.com

GitHub automatically masks secret values in logs:

********

4️⃣ What Are Environments?

An environment represents a deployment stage.

Common examples:

development
staging
production

Usage in a job:

jobs:
  deploy:
    environment: production

Once you do this:

environment secrets become available
protection rules are enforced
deployments are tracked

5️⃣ Environment Protection Rules (Production Safety)

Environments can enforce:

✅ Required reviewers

Manual approval before job runs

✅ Deployment branch rules

Only allow deploys from main

✅ Wait timers

Delay deployments if needed

This is how real teams protect production.

6️⃣ A Real-World Deployment Example

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - run: echo "Deploying to production"
        env:
          API_KEY: ${{ secrets.PROD_API_KEY }}

What happens here:

Workflow starts
GitHub pauses for approval
Secrets are unlocked only after approval
Deployment runs

7️⃣ Common Mistakes to Avoid 🚨

❌ Committing secrets in code
❌ Printing secrets in logs
❌ Using repo secrets for production
❌ Forgetting to specify environment
❌ Exposing secrets to PR workflows

These mistakes are very common and very dangerous.

Final Mental Model (Lock This In)

vars        → configuration
secrets     → credentials
environment → protection + scope

If this model is clear, your pipelines will already be safer than most.

What’s Next?

👉 Episode 6:
Caching & Artifacts – Faster Pipelines and File Sharing

DEV Community