Skip to content
runaway

Docker Registry Mirror

When a job pulls container images during the build — docker pull, docker compose up, a service container — those pulls go through a Docker daemon, not through the package-manager custom-env knobs. A registry mirror or pull-through cache caches those image pulls on your network.

Shared-daemon workloads (the default)

Section titled “Shared-daemon workloads (the default)”

On the default shared-daemon runtime, every runner shares its host’s Docker daemon. So the mirror is configured on the host daemon, once per agent host — an operator task, not something Runaway exposes.

Edit /etc/docker/daemon.json on the agent host:

{
  "registry-mirrors": ["http://registry-mirror.lan:5000"]
}

Then reload the daemon (systemctl restart docker).

Every runner on that host inherits the mirror, since they share the daemon you just configured. Standing up the mirror service itself (Docker’s registry:2, Harbor, etc.) is out of scope here.

Isolated (sysbox) workloads

Section titled “Isolated (sysbox) workloads”

On the isolated-sysbox runtime, each runner gets its own fresh inner dockerd, so the host daemon’s mirror config does not apply. The inner daemon needs its own registry-mirrors config, and that’s harder to arrange:

  • The inner daemon starts fresh on every runner (AutoRemove: true wipes it on exit), so any config you write into it does not persist across jobs.
  • You inject the daemon config and restart the inner dockerd as an early workflow step, before any image pulls. No Runaway setting seeds the inner daemon’s daemon.json.

If your workload needs both isolation and a pull-through mirror, treat the inner-daemon config as a per-workflow bootstrap step you own.

Section titled “Related”