When a workflow needs to deploy an app or publish a Docker image, it may need a password, API key, or cloud credential. These are sensitive values, so they must never be written directly in the workflow file or committed to Git.

GitHub gives you a safe place to store them: Actions secrets. A workflow can read a secret while it runs, but people cannot see its value in the repository.

Secrets

GitHub Actions secrets store sensitive values outside the repository.

Examples:

Secrets should never be committed to Git.

Using secrets

Secrets are accessed through the secrets context.

env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}

Only expose a secret to the step that needs it. Avoid putting secrets in global environment variables when possible.

For example, add DEPLOY_TOKEN in Repository settings → Secrets and variables → Actions. Then pass it only to the deployment command that needs it.

GITHUB_TOKEN

GitHub automatically provides a GITHUB_TOKEN for workflows.

It can be used for repository operations such as:

Its permissions should be explicitly limited.

Permissions

Set workflow permissions instead of relying on broad defaults.

permissions:
  contents: read
  packages: write

Use the minimum permission required for the job.

OpenID Connect

OIDC lets GitHub Actions request short-lived credentials from cloud providers.

This is safer than storing long-lived cloud keys as GitHub secrets.

Common flow:

  1. Workflow requests an identity token.
  2. Cloud provider validates the GitHub identity.
  3. Cloud provider returns temporary credentials.
  4. Workflow deploys using those credentials.

Common mistakes

Quick revision