The GitHub Environments feature

Creating an Environment

In a repo where you're an admin: Settings > Environments > New environment. Give it a name (e.g. staging) and confirm. You land on its configuration page, where you can add:

• secrets (encrypted, never shown in plain text once saved);
• variables (plain text, visible in logs if you explicitly print them);
• protection rules (next module).

Hands-on step 1 — create an Environment and a scoped variable

1. Create an Environment named demo.
2. Add a variable to it (not a secret, to keep this simple): name GREETING, value hello-from-demo.
3. In your repo, create .github/workflows/env-demo.yml:

name: Environment demo

on:
  workflow_dispatch:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    environment: demo
    steps:
      - name: Print the scoped variable
        run: echo "Message: ${{ vars.GREETING }}"

4. Commit, push, then trigger the workflow manually (Actions tab > select the workflow > Run workflow — that's what workflow_dispatch enables).
5. Open the finished run: the step's log shows Message: hello-from-demo.

Verifying the scoping

Remove the environment: demo line from the file, commit, re-run the workflow manually. The log this time shows Message: (empty): the GREETING variable only exists for jobs that explicitly reference the demo Environment. That's concrete proof of scoping — not just a claim to take on faith.

Put environment: demo back before continuing to the next module.

The Deployments page

A job that references an Environment automatically creates a deployment object, visible via the Deployments link in the sidebar of the repo's main page (or via the REST/GraphQL API). Each run shows up there with its status (in_progress, success, failure) and, if you set one, an environment URL — useful for quickly finding what was deployed where, without digging through workflow logs one by one.

What you just did

You created an Environment, verified with proof (not theory) that its variables are scoped to jobs that explicitly reference it, and discovered the Deployments page that tracks every run. The next module adds the real reason Environments exist: protection rules that turn an automatic deployment into a governed one.