Docker Networking: Bridge, Host, Macvlan, Custom

An application that runs in isolation is not done — it becomes useful only when it can receive traffic, call other services, and reach the internet, and each of those is a networking question with three or four defensible answers. Docker's network modes are frequently reduced to a slogan ("bridge by default, host when you need ports") that collapses exactly when a real deployment needs a decision: a public-facing reverse proxy, an internal API that must not have a route to the world, or a service that needs to appear on the LAN directly. This guide lays out bridge, host, and macvlan, then shows the custom networks that production stacks actually arrange.

The Default Bridge and Its Limits

When you run a container with no --network flag, Docker attaches it to the default bridge. Each container gets its own virtual interface, an internal IP on a private subnet, and outbound NAT to the host's network, while inbound traffic arrives only through explicitly published ports (-p 8080:80). This gives you safe-by-default isolation with zero configuration, which is why it is the default. The catch is that the default bridge does not provide automatic DNS between containers: two containers on it reach each other by IP, and IPs change on every recreate, which is the classic reason stacks outgrow it.

User-Defined Bridge Networks: The Production Default

Creating your own bridge network changes the rules in two valuable ways: containers on it resolve each other by name, and you can attach the same container to several networks so that, say, a web tier talks to an internal API but never to the database's network segment. This is the smallest change with the largest isolation payoff — network attachment becomes an access-control statement.

# A named bridge with DNS between containers
docker network create appnet
docker run -d --name api --network appnet --network-alias api my-api:1.4
docker run -d --name web --network appnet -p 8080:80 my-web:2.0

# Prove name resolution from inside a container
docker run --rm --network appnet nicolaka/netshoot curl -s http://api:8080/health

The --network-alias api is what other containers use as a stable hostname; the runtime keeps publishing it as long as any container holds the alias, so you can roll containers against a fixed name.

Host Mode for Raw Performance and Special Cases

The --network host mode skips the virtual NICs and NAT entirely: the container uses the host's network stack and binds sockets directly on host addresses, with no port mapping and no per-container IP. Throughput improves by a few percent and source IPs are preserved — which matters for anything enforcing access by originating address, like certain licensing or P2P workloads. The price is that containers share the host's network namespace, so two host-mode containers cannot both bind port 80, and there is no network isolation to fall back on if your runtime ever needs it.

Macvlan for LAN-Conscious Services

Macvlan gives each container its own MAC address and IP on your physical subnet, making it indistinguishable from any other LAN host — the mode to reach for when software expects a plain host address, such as some monitoring probes, or when a container needs to talk to devices that ignore NAT. It requires you to hand the network a real parent interface and an IP range, which means your underlying network must have room and must permit the ARP/switch behavior macvlan depends on.

docker network create -d macvlan   --subnet=192.0.2.0/24   --gateway=192.0.2.1   -o parent=eth0   lan0

docker run -d --name sensor --network lan0   --ip 192.0.2.42 my-sensor:latest

Two operational realities of macvlan are worth repeating: the host itself cannot freely talk to its macvlan containers (connectivity with the parent is restricted), and you will own the IP inventory by hand. On a VPS where your provider's network is the parent, macvlan also depends on your provider allowing multiple MACs per interface — verify before you build around it.

Putting It Together: A Layered Stack

The pragmatic production shape on a single host is one user-defined network for each trust tier: a front network for the reverse proxy, an internal network for APIs, and the database attached only to internal. Services are attached to exactly the networks they need; nothing else is reachable.

docker network create front
docker network create internal
docker run -d --name proxy --network front -p 80:80 -p 443:443   --link-api-alias nginx-proxy:latest
docker run -d --name api --network front --network internal my-api:5.0
docker run -d --name db --network internal postgres:16-alpine
docker network inspect front
docker network inspect internal

docker network inspect prints each segment's full membership, which is the fastest audit of "who can talk to whom" you can run. If a container appears in a network you did not intend, that is a config bug, not a mystery — and it is visible in seconds.

Takeaway

Bridge is the safe default, host is the throughput compromise with zero isolation, macvlan is for services that must look like plain LAN hosts, and user-defined networks are what you actually build production stacks on because they give name resolution and segment isolation in one move. Non-root containers, read-only filesystems, and layered networks are how serious stacks stay boring in the best way. Netbay VPS hosts boot with a fresh network configuration and Docker ready in under a minute, and DC01's Lucknow-edge placement keeps your published ports fat — spin one up and lay out your segments at netbayhosts.in.