No. The Distribution deployment guide says the default configuration is set for development, with debug logging and OpenTelemetry traces exported to localhost on port 4318. Before production you need TLS, authentication, a decision on delete, log settings and a health check that notices when auth breaks.
What the defaults assume
The guide states that the default config is meant for development. Two specifics it calls out are debug logging and trace export to localhost:4318. You can stop the export by setting OTEL_TRACES_EXPORTER=none.
From the configuration reference, other defaults to know:
| Setting | Default | Production question |
|---|---|---|
storage.delete.enabled | false | Do you need cleanup, and who may delete? |
storage.maintenance.readonly.enabled | false | Do you have a procedure to use it? |
http.tls.minimumtls | tls1.2 | Can clients handle a higher floor? |
log.accesslog.disabled | access logging on, to stdout in Combined Log Format | Where do the logs go and how long are they kept? |
proxy.ttl | 168h | Only for cache setups; is the value deliberate? |
Authentication is a choice among providers, and TLS needs a certificate and key. Neither is something you get by default, so check both explicitly.
Logging
Debug logging is noisy and can include request detail that you would rather not retain. Set a level that fits production. Keep access logging on. The reference says it goes to stdout by default, which suits container platforms that collect stdout. Turning it off with disabled: true removes the record you will want after an incident.
Telemetry
Trace export to localhost is harmless on a lone machine, but in a container it fails quietly or is pointed at something unintended after config changes. Either set up a real collector under your control or switch export off. Do not leave a default that sends data to an address you did not pick.
Health checks
The guide suggests treating a 401 from /v2/ as healthy and anything else as down, so that broken authentication shows up as a failed check. The registry also has a file based health check: the check fails while a named file exists, which lets you drain a node by creating it. Results appear at /debug/health, but only if the debug server is enabled, so keep that listener off the public network.
Production change list
- TLS with a trusted certificate chain.
- An authentication provider, tested from outside.
- Delete decision and a garbage collection procedure.
- Log level and shipping set, access logging on.
- Telemetry export configured or off.
- Health checks that treat
401as healthy. - Debug and metrics listeners bound to an internal interface.
- A short runbook for patching the registry software itself.
Try it yourself
Click through it at your own pace, or open it full screen.
See how continuous checks flag change over time. A config review once at launch will not catch next year's drift.
Safeguard can scan container images and generate SBOMs for what your registry stores, with a free scan at gold.safeguard.sh/scan.
Quick check
Does the default registry config include authentication?
The deployment guide says production registries should always add access restrictions, so treat auth as something you must configure and test.
How do I turn off the default trace export?
Set OTEL_TRACES_EXPORTER=none, as the deployment guide notes.
Sources
Last reviewed: 19 October 2026.
