GitHub Actions Secrets and Security Best Practices

When working with GitHub Actions, your workflows often require API keys, tokens, or credentials for deployments and integrations. Storing these securely is crucial — leaking secrets can compromise your entire system.

This article is part of our complete Git and GitHub Actions workflow guide.

This guide explains how to manage secrets in GitHub Actions and the best practices for keeping workflows safe.

🔹 What Are GitHub Actions Secrets?

Secrets are encrypted environment variables stored in GitHub.

They’re never exposed in plaintext in logs.
They’re accessible only to workflows in your repo.
Examples: API keys, cloud credentials, SSH keys.

🔹 Adding Secrets

Go to your repo → Settings → Secrets and variables → Actions.
Click New repository secret.
Add key-value pair, e.g.:

Name: AWS_ACCESS_KEY_ID  
Value: &lt;your-key>

🔹 Using Secrets in Workflows

Example: Deploying with AWS credentials

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to AWS
        run: aws s3 sync ./build s3://my-bucket --delete
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

🔹 Organization & Environment Secrets

Repo-level secrets → Available only in that repo.
Organization secrets → Shared across multiple repos.
Environment secrets → Scoped for staging, testing, or production.

Example:

deploy:
  environment: production

This ensures only production secrets are used.

🔹 Security Best Practices

✅ Never hardcode credentials in workflow YAML.
✅ Use Environments (staging, prod) to separate secrets.
✅ Limit permissions with fine-grained PATs or tokens.
✅ Rotate secrets regularly.
✅ Enable branch protection so only reviewed code can trigger sensitive workflows.
✅ Use GitHub Environment Protection Rules (manual approval before deploy).
✅ Consider OpenID Connect (OIDC) for cloud deployments instead of static keys.

🔹 Example: Using Environments & Approvals

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://my-app.com
    steps:
      - uses: actions/checkout@v3
      - run: ./deploy.sh

This can require a manual approval before running.

✅ Key Takeaways

Store sensitive data in GitHub Secrets, never in code.
Use environments to separate staging vs. production.
Protect workflows with approvals and branch rules.
Use OIDC for cloud auth instead of long-lived tokens.

By following these practices, you’ll ensure your GitHub Actions pipelines are secure, reliable, and production-ready.

Frequently Asked Questions

Where are GitHub Actions secrets stored?

Encrypted at the repository, environment or organization level. They are exposed to workflows only as masked environment variables or inputs at run time.

Are secrets available to workflows from forked pull requests?

No. Secrets are not passed to workflows triggered by pull_request from a fork, which stops contributors exfiltrating them.

Can I see a secret value after saving it?

No. GitHub never displays a stored secret again. You can only update or delete it.

How do I stop a secret leaking into logs?

GitHub masks known secret values automatically. Avoid printing them, and pass them as environment variables or inputs rather than command-line arguments.

DevToolHub