What are ephemeral and just-in-time GitHub Actions runners, and when would you use them?

## Two related ideas **Ephemeral runner.** A runner configured with `--ephemeral` picks up one job, completes it, and then removes its own registration. The agent process exits; it will never take a second job. The important discipline is that ephemerality must extend to the *machine*: if you restart the same VM with the same disk, you have merely re-registered a dirty host and thrown away the benefit. **Just-in-time runner.** JIT configuration is the API-native way to create such a runner. Instead of minting a short-lived registration token and running `config.sh`, you ask GitHub for a complete, single-use runner configuration: ``` gh api --method POST /repos/acme/api/actions/runners/generate-jitconfig \ -f name=jit-1 -F runner_group_id=1 -f 'labels[]=self-hosted' -f 'labels[]=linux' ``` The response carries an encoded configuration blob you hand straight to the agent via `--jitconfig`. No token file is written, no `config.sh` step, no removal step — and the configuration cannot be reused to bring up a second runner. ## Why this matters **Security.** This is the primary driver. A persistent runner lets job N influence job N+1 through the workspace, `PATH`, dependency caches, background processes or leftover credentials. A one-job-and-gone runner removes that channel entirely, which is the standard answer to "how do I self-host safely". **Correctness and flakiness.** Persistent runners drift. Disk fills with old workspaces and container images; a half-finished job leaves a lock file; two runners on one host contend for the Docker daemon or a fixed port. A large share of "works on my machine, flakes in CI" on self-hosted fleets is state, and ephemerality is the cure. **Elasticity.** Ephemeral and JIT runners are the substrate for autoscaling. GitHub emits a `workflow_job` webhook when a job is queued; a controller creates one runner for that job and lets it disappear afterwards. Actions Runner Controller implements this on Kubernetes, giving a pod per job. Persistent runners cannot scale to zero, because a scaled-down runner might be mid-job. ## The costs, honestly - **Cold start.** Every job pays for provisioning plus any tool installation. Mitigations: bake tooling into the runner image, keep a small warm pool of pre-created runners, or lean harder on `actions/cache` — which now has to fetch over the network instead of hitting a warm local directory. - **Cache locality lost.** The big attraction of a persistent self-hosted runner is a hot dependency directory and pre-pulled images. You trade that for isolation; for many teams a shared cache service or a well-designed `actions/cache` key recovers most of it. - **Operational surface.** Something must now create runners: an autoscaler, a controller, or a cloud API loop. That is a system to run and monitor. Naive designs also hit API rate limits when they mint configuration per job at high volume. ## Choosing Use ephemeral/JIT when the workload is untrusted (public repositories, many contributors), when jobs need clean isolation, or when demand is spiky enough that scale-to-zero matters. Keep persistent runners for a small, trusted, homogeneous internal fleet where the warm state genuinely pays — and even then, wipe the workspace and monitor drift.