Lesson 4 of 30

Runners and Environments

Q: When would you actually reach for a matrix build, and when is it wasted CI spend? Walk through a real example either way.

A strong answer covers: Explains a matrix runs the same job across every combination of declared variables (OS, language/runtime version, etc.), in parallel; Ties matrix value to actual production/consumer diversity — libraries and CLIs installed on machines you don't control benefit; a single deployed app targeting one known runtime usually doesn't; Names the real cost: N combinations multiply runner-minutes, not just wall-clock time; Gives a concrete example distinguishing a matrix-worthy project from one that isn't.

The machine that actually executes your job — hosted vs. self-hosted, and matrix builds: running the same job across multiple versions at once, and when that's worth the extra minutes.

15 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Runners and Environments

What interviewers actually ask about this, and what a strong answer has to cover.

When would you actually reach for a matrix build, and when is it wasted CI spend? Walk through a real example either way.

A strong answer covers

Explains a matrix runs the same job across every combination of declared variables (OS, language/runtime version, etc.), in parallel
Ties matrix value to actual production/consumer diversity — libraries and CLIs installed on machines you don't control benefit; a single deployed app targeting one known runtime usually doesn't
Names the real cost: N combinations multiply runner-minutes, not just wall-clock time
Gives a concrete example distinguishing a matrix-worthy project from one that isn't

Likely follow-ups

If your test suite takes 8 minutes and you add a 6-combination matrix, what's the actual minute cost, and does 'it runs in parallel so it's still fast' fully address that?
What's the difference between a hosted runner and a self-hosted one in terms of what persists between two separate job runs?
Why might a compromised self-hosted runner be a bigger security concern than a compromised hosted one?

Practice these with the AI interviewer →

The plain-language idea

A runner is the actual machine a job's steps execute on. runs-on: ubuntu-latest in this repo's ci.yml isn't a config option floating in the abstract — it's a real, freshly-provisioned Linux VM that GitHub spins up, runs your ten steps on, and then destroys the moment the job finishes. Every job starts from a clean slate; nothing persists between runs unless you deliberately cache or upload it.

Two flavors:

Hosted runners — GitHub provisions, maintains, and tears down the machine for you (ubuntu-latest, windows-latest, macos-latest). Zero maintenance, but you're limited to what GitHub offers, and macOS/Windows minutes cost several times more than Linux minutes.
Self-hosted runners — you register your own machine (a bare-metal box, a VM, a Kubernetes pod) as a runner. You maintain the OS, installed tools, and security patching yourself. Teams reach for this when they need specific hardware (a GPU for ML pipelines), need to run inside a private network to reach internal resources, or are burning enough hosted-runner minutes that owning the hardware is cheaper.

A matrix build runs the same job definition multiple times in parallel, once per combination of variables you specify — most commonly across Node versions, OS versions, or both.

See it in a real thing: turning this repo's job into a matrix

This repo's actual ci.yml pins one specific target: runs-on: ubuntu-latest with node-version: 24. That's a deliberate choice — the app deploys to one known Node version on one known OS, so testing more combinations would just burn CI minutes without catching anything real. But here's what it would look like if this were a published library that other teams' Node versions and OSes needed to support:

jobs:
  verify:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node-version: [20, 22, 24]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: pnpm install --frozen-lockfile
      - run: pnpm test

strategy.matrix declares two axes — 2 OSes × 3 Node versions — and GitHub Actions runs all 6 combinations as separate, parallel jobs automatically. ${{ matrix.os }} and ${{ matrix.node-version }} are placeholders substituted per-job. The job summary shows six independent pass/fail results: (ubuntu-latest, 20), (ubuntu-latest, 22), ... (windows-latest, 24).

What people usually miss

Watch out

A matrix only earns its cost when you'd actually break on some combination and not others. This repo's app is a Next.js app deployed to one Node version on one OS — a matrix here would be pure overhead, testing combinations nobody will ever run in production. Matrices earn their keep for published libraries, CLIs, or anything installed on machines you don't control.
Self-hosted doesn't mean "cheaper" by default. It trades GitHub's per-minute billing for your own infrastructure, maintenance time, and — critically — your own responsibility for security patching and isolating the runner between jobs. A compromised self-hosted runner can be a much bigger blast radius than a hosted one, which is destroyed after every single job.
Hosted runners are not free of state entirely — dependency caching bridges runs without needing a persistent machine. actions/setup-node's cache: pnpm (from the previous lesson) restores a cache keyed to the lockfile even though the underlying VM is brand new every time. "Ephemeral machine" and "zero memory between runs" aren't quite the same claim.

The genealogy: what a runner actually has access to

A runner being ephemeral and freshly provisioned raises an obvious question: if the machine is destroyed after every job, how does a step reach a real API key or database password without it being baked into this file in plain text? That's secrets and environment variables — how sensitive values get onto a runner without ever appearing in this YAML or in a log line — and it's the next lesson.