Isolated Runners

Each workload picks one runtime tier, from none (no Docker, the default) up to isolated-kata (a full VM). This page covers the three nested tiers that give a job its own Docker daemon: dind, isolated-sysbox, and isolated-kata. For the full ladder and how to set the tier, see Configuring workloads.

The nested tiers

• dind — a privileged inner Docker daemon per runner. Isolates Docker state per job without sysbox or kata, but the inner daemon runs privileged, so a container escape is host-root. Consent-gated; trusted single-tenant CI only.

• isolated-sysbox — wraps each runner in sysbox’s user-namespaced nested dockerd. Any docker build or docker run in the job uses that inner daemon, and on container exit the layers, images, and BuildKit cache are gone.

• isolated-kata — runs each runner in a lightweight VM via Kata Containers, kernel-level isolation. Needs /dev/kvm on the host and a registered kata runtime.

Each tier gives a job a fresh inner daemon, matching github-hosted semantics: cold Docker layers per job, but warm filesystem caches through the /cache volume, which bind-mounts in regardless of runtime.

Note

Because each job gets a fresh inner daemon, Docker layer cache does not carry across runner generations on isolated-sysbox. The /cache filesystem volume still mounts, so ecosystem and tool caches survive.

Enabling isolated runners

1. Install sysbox-runc on the host. Tick the sysbox option when enrolling the host, or install it later from the host detail page. See Running multiple hosts for host enrollment.

2. Pick the runtime on the workload. Choose isolated-sysbox in the workload’s runtime setting.

3. Keep the standard image. The default myoung34/github-runner:latest ships a Docker daemon inside it, which is all the isolated runtime needs. The hub starts that inner dockerd automatically at runner boot (it injects START_DOCKER_SERVICE=true) — you don’t configure anything.

Caution

If a targeted host doesn’t have sysbox installed, the workload warns you and writes a clear error for that host instead of spawning into the shared daemon. It will not silently fall back to shared-daemon.

Notes

• Selecting the isolated runtime suppresses the host Docker-socket bind — the runner uses its own inner daemon, not the host’s, so there’s no /var/run/docker.sock mount.
• sysbox is opt-in. Workloads on other runtimes (none, shared-daemon) are unaffected whether or not sysbox is installed on any host.

Related

Running multiple hosts

Configuring workloads