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: dind and isolated-sysbox give a job its own Docker daemon, isolated-kata gives it its own kernel. 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. The inner daemon’s data root is an anonymous Docker volume created with the runner and removed with it, so every image a job pulls is reclaimed on exit.

• 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. It starts no inner daemon, so jobs that run docker, container: or services: belong on dind or isolated-sysbox.

dind and isolated-sysbox give each 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

Docker layer cache does not carry across runner generations on any nested tier — each runner’s daemon starts empty. The /cache filesystem volume still mounts, so ecosystem and tool caches survive.

Caution

The profile’s memory limit caps the runner and everything its inner daemon starts. On dind and isolated-sysbox, size it for the heaviest container a job builds or runs, not for the runner itself.

Enabling sysbox

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