Docker Networking for Homelab: Bridge, Compose, and Ports Done Right

Most homelab Docker tutorials stop at docker compose up. That gets containers running, but it does not explain why two containers cannot see each other, why a service is reachable from the host but not from another machine, or why your reverse proxy returns gateway errors after a reboot. Understanding Docker networking removes those blockers and makes your homelab stack predictable.

This guide focuses on the networks Docker creates by default, how to connect services across containers, and how to expose ports safely without turning your server into a Swiss cheese.

Docker’s Default Networks

When you install Docker, it creates three networks automatically: bridge, host, and none. Every container you start without an explicit network joins the bridge network.

On the default bridge, containers can reach the internet, but they cannot reach each other by container name. Docker does not provide automatic DNS resolution between containers on the default bridge. That single detail causes more confusion than anything else in beginner homelab setups.

Use a User-Defined Bridge

Create a custom bridge network for services that should talk to each other. On a user-defined bridge, Docker provides built-in DNS. Containers can reach each other by service name or container name.

docker network create homelab

Then launch containers on that network:

docker run -d --name app --network homelab myapp:latest

Any container on homelab can now reach app simply by using that name as a hostname.

Docker Compose Networking

In Compose, every service can join a shared network by default. You do not need to create the network manually. Docker Compose creates it from your project name and attaches every service to it.

This means services can reach each other by service name. If your app service needs to talk to db, it can use db as the hostname. That is why Compose works so well for multi-service stacks.

Exposing Ports Safely

Do not expose every container port to the host. Only publish ports that need external access. Use -p or the Compose ports section selectively.

For services accessed only by other containers, do not publish the port at all. For services accessed through a reverse proxy, publish only the reverse proxy ports, such as 80 and 443, and keep application ports internal.

For services that need direct access from your LAN, publish only the required port and restrict access at the firewall level.

Macvlan for True LAN IPs

Sometimes you want a container to behave like a physical machine on your LAN. macvlan networks let containers use their own IP addresses from your router’s subnet. This is useful for devices that expect to be on the physical network, such as media servers, printers, or legacy applications.

Create a macvlan network tied to your physical interface and assign IPs manually or through a DHCP reservation. Note that macvlan containers cannot reach the host by default; use a separate ipvlan or a secondary interface if you need host communication.

Common Troubleshooting

If containers cannot reach each other, verify they are on the same network. If a service is unreachable from another machine, verify the port is published and no firewall rule blocks it. If DNS resolution fails inside a container, make sure the containers share a user-defined bridge instead of relying on the default bridge.

Inspect a container’s network settings with docker inspect. Look for NetworkSettings.Networks to see attached networks and IP addresses.

Connecting to External Services

Sometimes your homelab needs to reach an external API or database. Docker containers use the host’s default gateway for external traffic. As long as the host can reach the destination, containers can too. If you need custom DNS for external resolution, configure it at the Docker daemon level or on the host.

Final Thoughts

Docker networking looks complex until you separate it into two rules: internal service-to-service traffic uses a shared user-defined bridge, and external access uses published ports behind a reverse proxy or firewall. Once that model is consistent, adding services to your homelab becomes routine instead of experimental.

If this helped, you may also want to read our guides on Docker Compose homelab stack, Nginx Proxy Manager setup, and home network segmentation with VLANs.