How to connect a Docker container to a specific network with the --network option in docker run.

If you’re tinkering with Docker, networks can feel like a maze at first. Then you realize there’s a simple, practical way to tell containers where to talk. That clarity comes from using the --network flag when you run a container. It’s small, fast, and it changes how your apps communicate in big ways.

The core idea: connect a container to a specific network at creation

Here’s the thing. Docker gives you networks to group containers so they can chat without shouting across the internet. When you start a container with a dedicated network, you nudge it into a lane where it can find its lane-mates by name. It’s like giving them a private hallway in a busy building.

If you’ve ever wondered which flag does the trick, it’s the --network flag you want to use with docker run. This isn’t something you set in a Dockerfile or commit into a sandboxed config file. At runtime, you tell Docker exactly which network the new container should join. That makes the setup predictable and easy to reason about—especially when you’re running multiple services that need to talk.

Why not other approaches?

You might have heard a few different ideas about wiring containers together. Let me explain why the --network flag is the straightforward choice:

• The network in the Dockerfile: It’s a handy place to set up environment variables, install packages, or tweak the image itself. But the actual network assignment isn’t something you pin in a Dockerfile. The container’s network is decided when it’s started. Think of the Dockerfile as the blueprint; the network is the street it’s parked on when you launch it.

• Modifying docker-compose.yml: This is a terrific tool for multi-container apps. It lets you declare networks and attach services to them in a tidy, reusable way. Still, that’s a Compose-level configuration. If you’re running a standalone container with a single docker run command, the --network flag is how you assign it on the spot. And if you’re using Compose, you’ll map networks in the YAML, then bring everything up together.

• A supposed --connect flag: That one isn’t a valid flag for docker run. It’s easy to assume there’s a secret switch to toggle, but in this case, the right path is the --network flag (or, when you’re managing existing containers, docker network connect). If you’re following a tutorial that mentions --connect, double-check—it’s probably a miscommunication or a version mismatch.

Getting hands-on: a quick run-through

Here’s a simple sequence you can try to see how it works in practice. It’s the kind of “try it, see the effect, adjust” workflow that makes networking less abstract and more tangible.

• Step 1: Create a network

• Command: docker network create mynet

• What it does: makes a private bridge network named mynet. Containers on this network can discover each other by their Docker-assigned names.

• Step 2: Start a container on that network

• Command: docker run -d --name web --network mynet nginx

• What you’ll notice: The container starts, and it’s part of the mynet network. It’s reachable by name from other containers on the same network.

• Step 3: Start another container on the same network

• Command: docker run -d --name app --network mynet alpine sleep 300

• What you’ll see: The app container can now resolve the name web to the nginx container’s IP address, assuming the app’s logic supports it.

• Step 4: Verify the network wiring

• Commands:

• docker network inspect mynet

• docker exec web ping -c 1 app

• What you learn: You’ll see the two containers listed under the network’s “Containers” section, and the ping shows that they can reach one another.

• Step 5: Connect an existing container to a network

• Command: docker network connect mynet some_other_container

• Why this matters: Sometimes you start containers without a network, or you spin up a container for a quick test and want to join it to an existing network later.

• Step 6: Disconnect if you need to

• Command: docker network disconnect mynet some_other_container

• A quick check: degrees of separation matter—don’t leave containers on networks they shouldn’t be able to see.

A note on DNS and service discovery

When containers share a network, they typically discover peers by container name. If nginx is running in a container named web, another container on the same network can reach it as http://web. It’s a tiny detail, but it changes how you architect services. Instead of hard-coding IP addresses (which drift as containers are created and destroyed), you rely on this name-based lookup. It’s one of those small wins that makes microservice patterns much more forgiving.

A helpful detour: networks come in flavors

You’ll see different network types in Docker, and they’re not just flavor for flavor’s sake. They map to real-world needs:

• Bridge networks: the default, good for a single host. Containers can talk to each other, and you can isolate workloads by using separate bridges.

• Host networks: bypass the network namespace entirely. The container shares the host’s network stack. This is fast but trades off some isolation.

• Overlay networks: needed when containers live on different hosts. They let containers across machines talk as if they’re on the same LAN, coordinated by a container-orchestration layer.

• Other networks (macvlan, etc.): used for more specialized cases, like giving a container its own MAC address on the physical network. Usually you’ll reach for this in more advanced setups.

In daily practice, most folks start with bridge networks on a single host, then expand to Compose for multi-container apps or to overlay networks when scaling across several machines.

A practical pattern you’ll see in the wild

When teams build services that must talk to one another, they often create a dedicated network for the whole app. For example:

• A front-end container serving the web UI

• A back-end API container

• A database container

All three live on the same network so the UI can call the API, and the API can fetch data from the database, all without leaking extra exposure to the outside world. If you later need to run a background worker, you attach it to the same network so it can reach the API without whitelisting anything more complicated.

But what about docker-compose? Is it a better fit for some projects?

It’s a different tool, but it’s closely related. If you’re orchestrating more than one container, docker-compose makes life easier by letting you declare networks in a YAML file and then attach services to those networks. Here’s a tiny taste of what that looks like in prose:

• Define a network at the bottom of the file

• List services that should live on that network

• Rely on Docker’s internal DNS so services can find each other by name

If you’re new to this approach, think of docker-compose as a way to script your whole app’s topology in one place, while docker run gives you precise control over individual containers at the moment you launch them.

A few quick troubleshooting tips

• If you see No such network or the container can’t reach a service, double-check the network name. A typo will leave the container stranded in its own little internet.

• Use docker network ls to list networks, and docker network inspect mynet to peek inside any network’s details.

• If a container is already running, you can still connect it to a network with docker network connect. Similarly, you can detach with docker network disconnect.

• When diagnosing, try pinging by container name from inside one container to confirm DNS is working on that network.

A little analogy to seal the idea

Think of a Docker network as a shared office building. Each container is a desk. The --network flag is the elevator that drops you onto a particular floor. If you want to chat with colleagues on the Marketing floor, you ride the right elevator and take the stairs only if you’re supposed to. It’s about clear boundaries, predictable paths, and reliable communication.

Keeping things readable and maintainable

As you scale, you’ll notice that the right network layout saves time and headaches. It makes deployments more predictable and reduces the risk of “who can talk to whom” surprises. Tools like Compose help you encode those decisions in a single file, so you’re not reconfiguring the same networks over and over as you bring services up and down.

If you’re exploring Docker in depth, you’ll come back to networks again and again. They’re the quiet backbone that keeps containerized apps talking the same language, even as you spin up new services, replace old ones, or move to a bigger cluster. And when you’re asked to connect a container to a specific network, you’ll know the right move is simple: use the --network flag when you run the container, and keep your topology clean and intentional.

A final nudge to keep experiments productive

Give yourself permission to experiment with a couple of small setups. Create a network, launch two containers on it, and try a third container that needs to talk to one of them. Then experiment with docker network connect and docker network disconnect. You’ll see the network’s effect in real time—how traffic routes, how DNS resolves names, and how the whole system behaves under simple, controlled changes.

In the end, the beauty of Docker networking is its balance: powerful enough to support complex architectures, yet approachable enough to learn in small, incremental steps. When you need to connect a container to a specific network, the right move is crisp, predictable, and wonderfully practical—the --network flag in the docker run command. It’s a tiny switch that unlocks a lot of clean, reliable communication across your containers. And that—not just on paper, but in actual practice—feels like a win you can feel in your hands.