Environments & CI/CD: from a commit to production

An environment is a running copy of your app plus everything it's wired to: its configuration, its secrets and its data. Most teams have four:

The point of having more than one is to test the same code before users meet it. So the rule is: the code and the build are the same everywhere; only configuration differs. If staging builds with different flags or runs a different command, a green staging tells you little about production.

What legitimately differs, and lives in environment variables rather than in code:

• Config — API base URLs, feature flags, log levels.
• Secrets — each environment gets its own keys: a test-mode payment key in preview, the live one only in production. A leaked preview key should be worthless.
• Data — which database the app connects to.

Hosting platforms scope variables per environment. On Vercel, for example, every variable is assigned to Production, Preview and/or Development (Pro and Enterprise plans can add custom environments such as staging); Preview applies to every branch that isn't the production branch, and a branch-specific value overrides it. One detail catches people: Vercel applies a changed variable only to new deployments, so you redeploy to pick it up.

The trap: a preview on the production database

The quickest way to get a working preview is to copy production's DATABASE_URL into the Preview scope. Now every pull request's deployment — code nobody has approved yet — reads and writes real customer data. A branch that adds a column, or a migration that runs on deploy, changes production's schema before the PR is merged, or even if it never is.

Give previews their own database: a seeded one shared by all previews, or a database branch per PR if your provider offers it. "Preview" should mean safe to break.

on:
  pull_request:
    branches: [main]
    paths-ignore:
      - "docs/**"
      - "**/*.md"
  push:
    branches: [main]

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

Every rule below is from GitHub's Actions documentation, and each one surprises someone.

branches means different things per event. Under push it's the branch pushed to. Under pull_request it's the branch the PR targets — its base. A PR from feature/login into main matches branches: [main]; a PR from feature/login-ui into feature/login (a stacked PR) does not, so this CI never runs on it.

pull_request listens to three activities by default: opened, synchronize (new commits on the PR's branch) and reopened. Retitling a PR — or changing its base branch — is edited, which isn't in the list. Retarget that stacked PR onto main after its parent merges, and CI still doesn't start until something is pushed to it (or it's closed and reopened), unless the workflow lists edited under types.

paths runs if any file matches; paths-ignore skips only if every file matches. A PR that changes docs/setup.md and src/login.ts runs, because one file isn't ignored. Patterns match from the repository root, and * stops at / while ** crosses it: docs/* matches docs/a.md but not docs/guides/a.md; docs/** matches both. When a workflow has branch and path filters, both must be satisfied.

A skipped workflow doesn't report success. If a filter skips a workflow whose check is required by branch protection, the check stays "Pending" and the PR can't merge. GitHub's advice is blunt: avoid requiring workflows that can be skipped.

Concurrency: one running, one waiting

A concurrency group is a name; runs that compute the same name share one slot. GitHub's rules for a group (with the default queue: single):

• at most one run executes;
• at most one run waits — when a newer run arrives, the waiting one is cancelled and the newcomer takes its place;
• cancel-in-progress: true additionally cancels the run that's executing.

So three quick pushes to a branch with cancel-in-progress: false give: run 1 executes, run 2 is cancelled when run 3 arrives, run 3 runs after run 1. With true, as above, only the newest push is ever worth finishing — right for PR checks, where an older commit's result is useless the moment a newer one exists.

The group name decides what competes. ci-${{ github.ref }} gives each branch or PR its own group, so two PRs never cancel each other. A bare group: ci would make every PR in the repository fight over one slot.

Standard GitHub-hosted runners are free for public repositories. For private ones, every account gets a monthly allowance and pays (or is blocked, with no payment method on file) beyond it. GitHub's billing docs, October 2026:

The allowance is per account, shared by every private repository the account owns, and charged to the repository owner no matter who triggered the run.

The rounding rule

GitHub rounds the minutes and partial minutes each job uses up to the nearest whole minute.

Each job, not each run. So the same 160 seconds of work costs differently by shape:

And each job pays its own setup: a fresh runner, checkout, toolchain, dependency install. A job that does 5 seconds of linting after 50 seconds of install bills a full minute for 55 seconds of mostly setup. Splitting a pipeline into many small parallel jobs makes it faster, and multiplies the bill.

Where minutes leak

• Runs nobody needed. Docs-only PRs (fix with paths-ignore — but not on a required check), superseded pushes to a PR (fix with a per-branch concurrency group and cancel-in-progress: true), and the same workflow firing on both push and pull_request for one commit (scope push to main).
• Per-run downloads. npx playwright install --with-deps installs browsers and their Linux packages — on Ubuntu runners Playwright runs apt-get update and apt-get install — on every run, and Playwright's CI guide notes those OS dependencies can't be cached. Installing one browser instead of all of them (npx playwright install --with-deps chromium) shrinks it; running the job in Playwright's prebuilt Docker image, which already contains the browsers and their packages, removes it.
• Expensive runners. Windows and macOS minutes cost more than Linux in GitHub's price list ($0.010 and $0.062 per minute against $0.006 for a standard 2-core Linux runner), and larger runners can't use included minutes at all.
• Retries. A failed run's minutes are spent; the re-run spends them again.