Host, None, and the Driver Seam

In one sentence: Network drivers are strategies for furnishing a sandbox — bridge builds the private world you've seen, host skips isolation entirely (the container uses the host's stack), and none furnishes nothing — traded off along isolation vs. performance vs. convenience.

Three strategies, one decision

host mode doesn't create a NET namespace at all: the container shares the host's real interfaces, so there's no NAT hop (maximum network performance), no port publishing (the app's port is a host port), and no isolation — port clashes and raw-socket access included. Right for network tools and rare latency-critical services. none creates the namespace but leaves only loopback: airgapped by construction, for batch jobs and security-sensitive processing whose only I/O is mounted storage. bridge is the balanced default. The engine's remaining job is honesty at the seam: refuse option combinations a driver can't honor (publishing a port in host mode is meaningless; so is any network I/O in none).

flowchart TB
  subgraph B["bridge (default)"]
    B1["own sandbox
private IP + NAT + DNS
publish ports to expose"]
  end
  subgraph H["host"]
    H1["NO sandbox —
host's real stack
no NAT · no publish · no isolation"]
  end
  subgraph N["none"]
    N1["own sandbox,
loopback only
airgapped by construction"]
  end
  APP["same container image"] --> B
  APP --> H
  APP --> N
  style H1 fill:#fff8ec,stroke:#f2ddb0
    

sequenceDiagram
  participant U as User
  participant E as Engine
  participant DR as chosen driver
  U->>E: run --network host -p 8080:80 app
  E->>E: validate options against driver capabilities
  E-->>U: error: host driver cannot publish ports
(the app's port is already a host port)
  U->>E: run --network host app
  E->>DR: setup(sandbox: none needed)
  DR-->>E: container joins host stack directly