What do you gain and what do you give up by running a container with Docker's `host` network driver on Linux?

## What actually changes With `--network host`, Docker does not create a new network namespace for the container. Its processes use the host's interfaces, IP addresses, routing table and network settings. There is no `eth0` created for the container, no veth pair, no bridge membership, no masquerade rule and no destination-NAT rule. Other namespaces - mount, PID, user, UTS - are still applied normally, so this is *network* isolation being dropped, not containerisation in general. ## The performance argument, honestly stated Bridge networking costs: one extra virtual hop, firewall rule traversal, and a connection-tracking entry per connection. Historically Docker also ran a userland proxy process for published ports in some configurations, which is far more expensive. Host mode removes all of that. When it matters: workloads with very high connection churn (connection-tracking table pressure and insertion cost), high packet rates such as an ingress proxy or a DNS server, and latency-sensitive paths where tens of microseconds count. When it does not matter: essentially every ordinary web service, where network overhead is invisible next to application time. The honest interview answer is "I would measure first", because "host is faster" without numbers is a red flag. ## The isolation argument This is the real cost. A host-mode container can connect to anything listening on the host's `127.0.0.1` - metrics endpoints, admin ports, unauthenticated local daemons that were considered safe *because* they were loopback-only. If the container is granted `NET_ADMIN` or `NET_RAW` it can change host firewall rules or capture host traffic. Host mode is therefore a meaningful escalation of what a compromised container can reach, and should be an explicit, reviewed decision rather than a default. ## The operability argument Port independence is the quiet loss. On bridge networking, ten containers can all listen on 8080 internally and be published to different host ports, so images need not know their deployment. In host mode each instance must be configured with a unique port, which means per-instance configuration, no simple horizontal scaling on one host, and collisions with host services installed later. Discovery also changes: no Docker network means no embedded name resolution for that container, so it addresses peers by host IP or published port, and other containers must reach it via the host's address rather than a container name. ## Real client addresses With source translation on the way in (and, in some setups, a userland proxy), the address an application sees for inbound connections may not be the client's. Host mode preserves it, which matters for rate limiting, geo rules, audit logs and allowlists. The alternative on bridge networking is passing the client address at the application layer (an `X-Forwarded-For` style header or the PROXY protocol) - which requires a trusted proxy in front. ## Practical guidance Reach for host mode when the workload's job *is* the host's network: an edge load balancer, a packet-capture or flow-metrics agent, a service that needs broadcast/multicast, or one with a wide dynamic port range (media protocols, some clustering stacks). Otherwise stay on a user-defined bridge and publish what you need. If you adopt host mode, document port ownership somewhere machine-readable - port collisions on a busy host are discovered at the worst moment - and keep capabilities minimal so the loss of network isolation is not compounded. Finally, remember portability: host mode assumes a Linux host whose network stack is the one you mean. On Docker Desktop the daemon runs inside a VM, so `--network host` binds inside that VM, and behaviour that works in CI on Linux can surprise a developer on a laptop.