Back to Articles
Docker10 min read
Docker Networking Explained: Bridge vs Host vs Macvlan for Your Homelab
Understand Docker bridge, host, and macvlan networking drivers, when to use each, and how to configure them in your self-hosted homelab.
Understand Docker bridge, host, and macvlan networking drivers, when to use each, and how to configure them in your self-hosted homelab.
If you run Docker containers in your homelab, understanding how Docker networking works is essential. Every container you launch needs to communicate — with other containers, with the host machine, and with devices on your local network. Docker provides several network drivers to handle these scenarios, and picking the right one can make or break your self-hosted setup.
In this article, we'll break down the three most commonly used Docker network drivers in homelab environments: bridge, host, and macvlan. You'll learn how each one works, when to use it, and how to configure it with practical examples.
Docker's networking subsystem is pluggable and uses drivers to provide core networking functionality. Several drivers exist by default. According to the official Docker documentation, the built-in network drivers include:
For most homelab and self-hosting use cases, you will work primarily with bridge, host, and macvlan. Let's dive into each one.
The bridge driver creates a private internal network on the Docker host. Containers attached to a bridge network can communicate with each other, while being isolated from networks that are not connected to that bridge. This is the default driver if you do not specify one.
When you install Docker, it automatically creates a default bridge network called docker0. According to Cisco's exploration of Docker networking, this acts like a virtual switch that connects containers effortlessly. Each container gets a virtual Ethernet interface (_veth_) that connects it to the bridge, and Docker's built-in IPAM driver provides container interfaces with private IP addresses from the subnet of the bridge network.
Note: The default bridge network does not provide automatic DNS resolution between containers. Containers on the default bridge can only communicate with each other using IP addresses, not container names.
For production and homelab use, Docker recommends creating custom bridge networks instead of relying on the default docker0 bridge. Custom bridge networks offer:
To create a custom bridge network:
docker network create --driver bridge my-bridge-networkYou can also specify a custom subnet and gateway:
docker network create --driver bridge --subnet=172.20.0.0/16 --gateway=172.20.0.1 my-custom-bridgeOnce the network exists, you can attach containers to it at runtime:
docker run -d --name my-container --network my-bridge-network nginxBridge networking is ideal for:
Note: Containers on a bridge network can reach the outside world through NAT, but they are not directly reachable from the local network unless you publish ports with -p.The host driver removes network isolation between the container and the Docker host. When you use the host network mode, the container shares the host's networking namespace — it does not get its own IP address, and it binds directly to the host's interfaces.
According to the official Docker documentation, if you run a container that binds to port 80 and use host networking, the container's application is available on port 80 on the host's IP address. There is no port mapping or NAT involved.
To run a container with host networking:
docker run --network host nginxdocker inspect to find a separate IP for the containerHost networking is useful when:
-p flagsNote: Host networking is not supported on Docker Desktop for Mac and Windows in the same way as on Linux. It is supported on Docker Desktop version 4.34 and later, but with different behavior.
The macvlan driver is one of the most powerful tools for homelab networking. It allows you to assign a MAC address to a container, making it appear as a physical device on your network. The container gets its own IP address from your local LAN subnet, just like any other device on your network.
According to Docker's official documentation, the macvlan driver connects Docker containers directly to host network interfaces through layer 2 segmentation. You designate a physical interface on your Docker host to use for the macvlan, along with the subnet and gateway of the network.
When you use macvlan, your container appears as a real device on your physical network. Other devices on your LAN can reach the container directly at its assigned IP, and the container can reach them without going through any Docker-level NAT.
To create a macvlan network that bridges with a given physical network interface:
docker network create -d macvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0 \
my-macvlan-netIn this command:
-d macvlan specifies the macvlan driver--subnet defines the IP range from which containers will receive addresses--gateway is your network's gateway (usually your router)-o parent=eth0 specifies the host's physical interface to bridge throughA common pattern in the homelab community is to define an external macvlan network in Docker Compose and assign static IPs to containers. Here is an example based on practical self-hosted setups:
version: "3.8"
networks:
macvlan_net:
external: true
services:
pihole:
image: pihole/pihole:latest
container_name: pihole
networks:
macvlan_net:
ipv4_address: 192.168.1.100
environment:
- TZ=America/New_York
- WEBPASSWORD=your-password
volumes:
- ./pihole/etc:/etc/pihole
- ./pihole/dnsmasq:/etc/dnsmasq.dIn this example, the Pi-Hole container gets the IP 192.168.1.100 on the local LAN and acts as a DNS server for the entire network — just like a physical device.
Macvlan is ideal for:
| Feature | Bridge | Host | Macvlan |
|---|---|---|---|
| Network isolation | High | None | Medium |
| Container has own IP | Yes (bridge subnet) | No (uses host IP) | Yes (LAN subnet) |
| Port mapping needed | Yes (-p flag) | No | No |
| Performance | Good (some NAT overhead) | Best (no overhead) | Excellent (direct L2) |
| DNS resolution by name | Yes (custom bridge only) | N/A | Yes |
| Accessible from LAN | Only via published ports | Yes, on host IP | Yes, direct IP |
| Host can reach container | Yes (via bridge) | Yes | No (by default) |
Use a custom bridge network. Place your reverse proxy (Nginx, Traefik, Caddy) and your web application containers on the same bridge. The reverse proxy can resolve containers by name and forward traffic internally. Expose only the reverse proxy's ports to the host.
Use macvlan to give your Pi-Hole or AdGuard Home container its own IP on the LAN. Point your router's DHCP settings to that IP, and every device on your network uses your container as its DNS server.
Use host networking for applications where every millisecond counts — for example, a gaming server, a real-time data pipeline, or a VPN gateway. Just be mindful of port conflicts.
Use the default bridge for quick testing, or a custom bridge when you need name resolution. This keeps your experiments isolated from your production containers.
Check which network the container is attached to:
docker inspect my-container | grep -A 10 "Networks"Or use the dedicated command:
docker network inspect my-bridge-networkThis displays all containers connected to that network and their IP addresses.
This is expected behavior by default. To work around it, you can create a macvlan interface on the host with the same parent interface and assign it an IP address in the Docker network's subnet, as documented in the official Docker docs.
Since host networking shares the host's namespace, you cannot run two containers that bind to the same port. Use a different port in one container, or switch to bridge networking with port mapping.
As mentioned earlier, the default bridge does not support DNS-based container discovery. Switch to a custom bridge network to resolve containers by name.
Understanding Docker networking is a critical skill for any homelab enthusiast. The bridge driver is your go-to for most self-hosted applications, providing solid isolation and easy container-to-container communication. The host driver gives you raw performance and direct port access when you need it. The macvlan driver is the secret weapon for making containers behave like first-class citizens on your physical network.
Each driver has its place. By matching your networking strategy to your use case, you can build a self-hosted environment that is both powerful and well-organized. Start with custom bridge networks for most services, then reach for macvlan when you need containers to exist directly on your LAN, and use host mode sparingly for performance-critical workloads.
For the official nitty-gritty details, always refer to the Docker documentation on network drivers. Happy container networking!