How to add multiple insecure registries to Docker using the daemon.json file

Brief outline

• Hook and context: When teams experiment with on-prem or private registries, you might need to mark several ones as insecure. The method you pick matters for persistence and reliability.

• The key idea: Adding registries to /etc/docker/daemon.json is the standard, durable approach.

• Why not the CLI flags: Command-line flags are temporary and vanish after a restart; that’s why daemon.json is preferred.

• How to do it: Step-by-step guide, a clean example, and quick validation tips.

• Caveats and best practices: JSON correctness, permissions, reboots, and a nod to security with TLS where possible.

• Quick wrap-up: The practical takeaway for Docker-savvy readers and real-world relevance to DCA topics.

Article: A practical guide to configuring multiple insecure registries in Docker

Let me explain something that often pops up in day-to-day Docker work: you sometimes need Docker to talk to registries that aren’t set up with TLS. It happens in labs, on-prem environments, or private testing pages where you’re dealing with internal images. The question isn’t whether you should do this, but how you do it so the change sticks around, even after you restart your machine or Docker daemon. The tidy, reliable way is to configure Docker through /etc/docker/daemon.json. It’s a small file, but it carries a lot of weight for how your daemon behaves.

Here’s the thing about the alternatives. You could spin up the daemon with a flag, or try to pass a flag through a compose file, but that’s like taping a temporary sign to a door. It works for a moment, but it doesn’t survive a reboot or a daemon restart. For long-lived setups, that makes life unnecessarily bidgety. A stable, predictable setup is a hallmark of solid Docker knowledge—a cornerstone you’ll find echoed across many Docker Certified Associate topics, and a habit you’ll thank yourself for later.

Why the daemon.json approach feels right

• Persistence: The daemon.json file sits on disk. Change it once, and the registry list is there after every reboot. This is exactly the kind of reliability teams lean on in real-world deployments.

• Clarity: It’s easy to see at a glance which registries you’ve allowed as insecure. No hunting through command histories or scripts to understand what’s allowed.

• Centralization: If you manage a few hosts, you can standardize the same configuration across machines by distributing the same daemon.json, making your environment more uniform.

What you’re configuring, exactly

In Docker, the setting you want to tweak is insecure-registries. It tells the daemon which registries should be treated as insecure, i.e., not strictly enforcing TLS verification. You can list multiple registries in a single array, and Docker will accept images from all of them.

The canonical form looks like this:

{

"insecure-registries": ["repo1", "repo2"]

}

A tiny snippet, yet it conveys a big change in behavior. If you’re wondering how to test it, pull or push an image to one of those registries after a restart, and you’ll see Docker happily communicating with them.

A quick, real-world step-by-step

1. Locate and open the file

• On Linux, the file lives at /etc/docker/daemon.json. If it’s not there yet, you can create it. Just make sure you’re editing a valid JSON document.

2. Add the insecure registries

• You want to include an array under the key insecure-registries. For example:

{

"insecure-registries": ["repo1", "repo2"]

}

3. Save and shut the editor

• Be careful with JSON syntax. A stray comma or a missing quote can break the daemon startup.

4. Restart the Docker daemon

• On systems using systemd, you’d run:

sudo systemctl restart docker

Then check status to confirm it’s back up:

sudo systemctl status docker

5. Verify the change

• A quick way to verify is to inspect the Docker info output:

docker info

Look under the Registry section to confirm your insecure registries are listed.

6. Test with a real image

• Try pulling from repo1 or repo2. If it’s a private registry, you might still need credentials, but Docker should attempt the connection according to the new rules.

Helpful tips and a few caveats

• JSON correctness matters: A stray trailing comma is a classic trap. If you’re editing by hand, many editors can help with syntax highlighting or JSON linting—use that to your advantage.

• Permissions matter: /etc/docker/daemon.json is a system file. You’ll typically need root privileges to edit it. If you’re deploying across several hosts, consider configuration management tools like Ansible, Puppet, or Salt to keep things consistent.

• Reboots don’t magically alter this: Once you set it in daemon.json, you’re setting a baseline for the daemon’s behavior. If you ever need a temporary change, you’ll want a method that doesn’t live inside this file, but for day-to-day work, this is your friend.

• Security note: Marking registries as insecure is convenient for testing or internal networks, but it reduces security. If possible, run registries over TLS with proper certs. If you do use insecure registries, keep them isolated and monitored. It’s a good habit to keep TLS certificates updated and trusted in production-like setups.

• Complementary checks: After you restart, you can run docker info | grep -i insecure to confirm. If you don’t see your registries listed, double-check the syntax and the file’s JSON structure.

Why not the CLI flags for this?

• The proposed command A—docker daemon --insecure-registries=repo1,repo2—sounds tempting, but it’s ephemeral. It starts the daemon with that setting, yet once the process ends or the machine reboots, that flag is gone unless you run it again. In contrast, editing daemon.json makes the change permanent. It’s the small decision that pays off in reliability.

• The other options in the question—like docker run --insecure-registry=repo1,repo2 or docker-compose up with an insecure-registry flag—don’t apply here. Docker run is about containers, not configuring the daemon’s registry behavior, and docker-compose doesn’t manage daemon-wide settings across restarts. And yes, those options can be tempting, but they won’t give you the stable, system-wide configuration you want.

• So, the only approach that sticks across reboots and updates is the daemon.json route. It’s the clean, durable path that lines up with how Docker is designed to be configured.

A few related topics you’ll encounter in DCA circles

• TLS and certificates: If you can, shift toward TLS with signed certificates for registries. It keeps data integrity and authentication tight, which is a dream for production environments.

• Registry security models: Private registries, proxy registries, and the distinction between insecure and secure registries—these are all fair game in real-world scenarios. Understanding when and why to switch modes is practical knowledge that translates to real workflows.

• Image pull behavior: How Docker authenticates with registries, how credentials are stored, and how to handle authentication errors gracefully. This helps when you’re diagnosing pull failures in environments with multiple registries.

• System administration basics: Editing system files, restarting services, and validating service status are bread-and-butter skills for Docker operators. If you’re aiming for a solid grasp of the fundamentals, these tasks are worth mastering.

A little nudge toward practical wisdom

When you’re navigating Docker in real life, think about consistency first. If you’ve got a fleet of machines or a CI environment, a single source of truth for daemon settings reduces friction. When you can point to a daemon.json file and say, “This is how we enable a handful of registries,” you’re lowering cognitive load for your teammates and you’re making the system more predictable.

And if you ever find yourself tempted to take a shortcut with a one-off flag, pause and ask: will this survive a restart? If the answer is no, you’ve got a good reason to put it in daemon.json instead. Small choices like this compound over time, shaping how smoothly your Docker-based workflows run.

Final takeaway

For configuring multiple insecure registries, adding them to /etc/docker/daemon.json is the practical, durable route. It’s straightforward, it’s persistent, and it aligns with how Docker is designed to be managed in real environments. The method keeps things clean, reduces surprises after reboots, and helps you stay focused on the bigger picture—like building reliable, scalable containerized systems.

If you’re exploring Docker concepts tied to real-world operations, this pattern is a handy reference point. It’s one of those little-but-important details that make you sound confident in conversations about container infrastructure, whether you’re debugging a local lab or coordinating with a larger team. And yes, it’s a topic you’ll see echoed across the kinds of practical scenarios that matter when you’re getting hands-on with Docker.