19.3.4.4 Info Registry Config
A focused guide to Info Registry Config, connecting core concepts with practical Docker and container operations.
The registry configuration section in docker info shows which image registries are configured on the Docker host, specifically which registries Docker treats as secure by default and which it is configured to access over unencrypted HTTP (insecure registries). This information comes from the Docker daemon configuration and determines how Docker authenticates and communicates with registries when pulling or pushing images.
Registry Configuration in docker info Output
docker info
Registry: https://index.docker.io/v1/
Insecure Registries:
127.0.0.0/8
Registry Mirrors:
https://mirror.example.com/
Registry (Default Registry)
Registry: https://index.docker.io/v1/
This field identifies the default image registry Docker uses when an image name does not include a registry hostname. When you pull nginx:latest, Docker resolves it as docker.io/library/nginx:latest and contacts https://index.docker.io/v1/ (Docker Hub's API endpoint) to find the image.
This value is fixed by the Docker daemon to point to Docker Hub. It is not configurable in the daemon settings.
Insecure Registries
Insecure Registries:
127.0.0.0/8
Insecure registries are registries that Docker will communicate with over plain HTTP (without TLS) or HTTPS with an untrusted (self-signed) certificate. By default, Docker only allows insecure communication with addresses in the 127.0.0.0/8 loopback range (localhost). Any other registry must use valid HTTPS.
Insecure registries are added in /etc/docker/daemon.json:
{
"insecure-registries": [
"192.168.1.50:5000",
"registry.internal.example.com:5000"
]
}
After restarting the daemon, these addresses appear under Insecure Registries in docker info.
The loopback range 127.0.0.0/8 is always present as an insecure registry, allowing local registry containers (such as a registry container started on localhost port 5000) to be used without TLS configuration.
Why Insecure Registries Matter
Pulling or pushing images over HTTP exposes image layers and authentication credentials to network interception. Insecure registry configuration is acceptable only for:
- Local development environments on trusted networks.
- Air-gapped environments where TLS infrastructure is not feasible.
- Temporary setups where a self-signed certificate is being used during initial configuration.
For any production or shared network environment, registries should be configured with valid TLS certificates. Docker supports custom CA certificates placed in /etc/docker/certs.d/<registry-hostname>/ca.crt, which allows Docker to trust a self-signed certificate without marking the registry as insecure.
Registry Mirrors
Registry Mirrors:
https://mirror.example.com/
Registry mirrors are proxy servers that cache Docker Hub image pulls. When a mirror is configured, Docker attempts to pull images from the mirror first. If the mirror has the image cached, the pull is faster and does not count toward Docker Hub rate limits. If the mirror does not have the image, Docker falls back to Docker Hub.
Registry mirrors are configured in /etc/docker/daemon.json:
{
"registry-mirrors": [
"https://mirror.example.com"
]
}
Common use cases:
- Organizations with many Docker hosts that all pull the same base images, reducing Docker Hub traffic.
- Environments with slow or metered internet connections that benefit from a local cache.
- Environments subject to Docker Hub pull rate limits on free-tier accounts.
If no registry mirrors are configured, this section does not appear in docker info output.
Checking Registry Configuration Programmatically
docker info --format "{{.IndexServerAddress}}"
To see insecure registries:
docker info --format "{{range .RegistryConfig.InsecureRegistryCIDRs}}{{.}}{{println}}{{end}}"
To see registry mirrors:
docker info --format "{{range .RegistryConfig.Mirrors}}{{.}}{{println}}{{end}}"
Registry Authentication
Registry configuration in docker info shows connectivity settings but not authentication credentials. Authentication is stored separately in ~/.docker/config.json on the client machine and managed with docker login:
docker login registry.example.com
This stores an authentication token or credentials in the Docker client configuration, which the daemon uses when pulling or pushing images to that registry. The docker info output does not expose stored credentials.