Talos Linux supports configuring registry mirrors for container image pulls. Registry mirrors allow to use official container image references while pulling images from local caching proxies. When used with a pull-through cache, the first time an image is pulled from the registry mirror, it is fetched from the upstream registry and cached locally. Subsequent pulls of the same image are served from the local cache, significantly improving pull times. The same concept can extended to air-gapped or partially connected environments, where a local registry mirror can be populated with required images ahead of time. There are many implementations of container registries that support pull-through caching, including Docker Registry, Harbor, Zot, and others.Documentation Index
Fetch the complete documentation index at: https://docs.siderolabs.com/llms.txt
Use this file to discover all available pages before exploring further.
Launch the caching Docker Registry proxies
The Docker Registry is the simplest way to set up pull-through caching proxies. It requires to set up a separate registry container per upstream registry. For example, to set up caching proxies for Docker Hub,registry.k8s.io, gcr.io, and ghcr.io, run:
Note: Proxies are started as docker containers, and they’re automatically configured to start with Docker daemon.As a registry container can only handle a single upstream Docker registry, we launch a container per upstream, each on its own host port (5000, 5001, 5002, 5003 and 5004).
Configuring Talos to use the caching registries
Talos Linux can be configured to redirect image pulls to the caching registries using RegistryMirrorConfig configuration document. The registry mirror configuration is honored by Talos Linux itself and automatically propagated to CRI runtimes (containerd). The registry configuration starts with the endpoint of the image reference: the endpoint is the leftmost part of the image reference before the first/.
For example, the endpoint for the image docker.io/library/nginx:latest is docker.io. If the endpoint contains the port, it must be included as well (e.g., myregistrydomain.com:5000).
One exception is that images from Docker Hub can omit the endpoint, for example library/nginx:latest has the endpoint docker.io.
For the endpoint, one can configure one or more mirror endpoints.
The endpoints will be tried in order until one succeeds, and by default the last implicit endpoint is the original upstream registry.
The endpoint should explicitly include the protocol (http:// or https://).
skipFallback: true in the configuration to prevent falling back to the upstream registry:
/v2 suffix is automatically appended to the endpoint URL when interacting with OCI registry API.
If the caching registry already includes /v2 in its URL path, set overridePath: true to prevent appending /v2 again:
my-private-registry.io use RegistryAuthConfig:
Using Harbor as a caching registry
Harbor is an open source container registry that can be used as a caching proxy. Harbor supports configuring multiple upstream registries, so it can be used to cache multiple registries at once behind a single endpoint.

overridePath: true to prevent Talos and containerd from appending /v2 to the path.
http://harbor in this example) can be configured with authentication or custom TLS: