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 scale sets (the default)

Section titled “Shared-daemon scale sets (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) scale sets

Section titled “Isolated (sysbox) scale sets”

On the isolated-sysbox runtime, each runner gets its own fresh inner dockerd — so the host daemon’s mirror config does not apply. To use a mirror inside an isolated runner, the inner daemon would need the same registry-mirrors config.

This is more involved and comes with a caveat:

  • 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’d inject the daemon config and restart the inner dockerd as an early workflow step, before any image pulls — there’s no Runaway setting that 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”