Before touching any command, it helps to be precise about what a container is, and is not, left with under this mode.

Every container Docker starts gets its own network namespace, a Linux kernel feature giving a process its own private view of network interfaces, addresses, and routing rules. In the default bridge mode, that private namespace is populated with a virtual network interface connecting the container to the rest of the world through Docker’s managed bridge. In none network mode, Docker still creates that private namespace, exactly as it always does, but it deliberately leaves it almost entirely empty. No virtual interface is created to connect it to anything else, no IP address is assigned for reaching the outside world, and no route exists for sending traffic anywhere beyond the container itself.

What remains, even under none network mode, is a single, special interface every network namespace has by default: the loopback interface, conventionally addressed as 127.0.0.1, which lets a process talk only to itself, or to other processes inside that exact same namespace. A container using none network mode can still have two of its own internal processes talk to each other over this loopback address, but it has absolutely no way to send or receive traffic to or from anything outside its own namespace: not the host machine, not other containers, and not the wider internet.

Why Docker still creates a namespace at all

It might seem simpler for none network mode to skip creating a network namespace entirely, the way host network mode skips it in the opposite direction by reusing the host’s own. Docker instead always creates a fresh, private namespace, populated with nothing but the mandatory loopback interface, because a process fundamentally still needs some namespace to exist in, even an empty one, for the kernel’s networking code to function correctly at all. Creating an empty, private namespace, rather than omitting one, is what actually guarantees the container has no path to anywhere outside itself.

It is also worth being clear from the outset about what kind of guide this is not. None network mode is not a workaround for a broken bridge network, nor a general troubleshooting step to try when ordinary container networking seems to be misbehaving. It is a specific, positive choice made for workloads whose entire design already assumes no networking will be available, and reaching for it in any other situation, simply hoping it will somehow simplify a networking problem that has not actually been diagnosed, tends to produce confusing, hard-to-debug failures rather than a genuine fix. The chapters that follow build up the full picture needed to use it correctly, starting from the concepts it depends on and working through to the specific, real situations where it belongs.

Why this matters more than it might first appear

It would be easy to dismiss none network mode as a minor, rarely used footnote among Docker’s networking options, but the guarantee it provides turns out to matter quite a lot in practice, precisely because so much of modern software development involves running code that was not entirely written, or entirely trusted, by the person running it. A dependency pulled from a public package registry, a script submitted by an outside contributor, a build step whose full behaviour has never been carefully audited line by line, all of these represent exactly the kind of situation where “this simply has no way to talk to the network at all” is a far stronger and simpler statement to make confidently than “we believe this has been configured correctly to only talk to the network in the ways we intended.” The rest of this guide explores exactly why that distinction matters, and precisely when it is worth reaching for.

A handful of words appear constantly around this topic. Getting comfortable with them now makes every later chapter click into place.

One sentence to hold onto

If you remember only one sentence from this chapter, make it this: none network mode does not remove Docker’s networking isolation, it maximises it, leaving a container with a genuine, private namespace containing nothing routable to anywhere beyond itself.

Comparing the setup steps for bridge mode and none network mode side by side shows exactly what is deliberately left out.

flowchart TB
    subgraph Bridge["Bridge mode setup"]
        B1["Create a new network namespace"] --> B2["Create a virtual ethernet pair"]
        B2 --> B3["Attach one end to the bridge, one end inside the container"]
        B3 --> B4["Assign a private IP address"]
        B4 --> B5["Add routing and NAT rules"]
    end
    subgraph NoneMode["None network mode setup"]
        N1["Create a new network namespace"] --> N2["Bring up only the loopback interface"]
        N2 --> N3["Stop: no virtual interface, no address, no route created"]
    end

When the Docker daemon starts a container in the default bridge mode, it performs a small sequence of setup steps: creating a fresh network namespace, creating a linked pair of virtual network interfaces connecting that namespace to the host’s internal bridge, assigning a private IP address, and configuring routing and address translation rules so traffic can actually flow in and out. For none network mode, the daemon performs only the very first of those steps. It creates the namespace, exactly as always, brings the mandatory loopback interface inside it up and running, and then simply stops there, deliberately performing none of the remaining steps that would otherwise connect that namespace to anything else.

This is a meaningfully different situation from host network mode, which skips creating a namespace at all and instead reuses the host’s existing one. None network mode does create a namespace, a genuinely separate, private one, but chooses to leave it disconnected rather than either populating it with a virtual interface, as bridge mode does, or discarding it altogether in favour of the host’s own, as host mode does. Of the three, none network mode is the only one that results in a container with its own real namespace and simultaneously no way to reach anything through it.

Why this is Docker’s strongest built-in isolation, not merely an absence of one

It would be easy to think of none network mode as simply “bridge mode with the networking parts removed,” but it is more precise to describe it as the deliberate, positive act of building a genuine boundary and choosing not to open any door in it. The namespace is real; the loopback interface inside it is real and functioning; the isolation it produces is an actual property of the running container, actively enforced by the kernel, not merely the absence of a feature someone forgot to configure.

Understanding exactly what a process sees from inside a none-network container clears up most of the confusion beginners run into.

A process running inside a none-network container that asks its own operating system “what network interfaces do I have?” receives an honest, short answer: exactly one, the loopback interface, conventionally given the address 127.0.0.1 and sometimes also an equivalent address for newer network protocols. Every other kind of interface a normal machine or container would typically have, a connection to a local network, a virtual bridge connection, is simply absent from the list entirely, not disabled or blocked, but genuinely never created in the first place.

Because there is no routing table entry pointing anywhere beyond that loopback address, any attempt by the application inside the container to open a connection to an external address, whether that is another container, the host machine, or a server out on the internet, fails immediately, typically with a clear “network unreachable” style error, since the kernel itself has no route to send that traffic through at all. This is a fundamentally different kind of failure from a firewall blocking a connection: a firewall actively inspects and rejects specific traffic that could, in principle, otherwise flow; here, there is simply no path for the traffic to be evaluated on in the first place.

flowchart LR
    subgraph NS["Container's private network namespace"]
        LO["Loopback interface: 127.0.0.1"]
        P1["Process A"] --> LO
        P2["Process B"] --> LO
    end
    P1 -.->|"attempt to reach an external address"| X["No route exists: connection fails immediately"]

What a network-diagnostic command actually reports

Running an ordinary network-interface listing command from inside a none-network container is one of the clearest, most direct ways to see this mode in action for yourself. Instead of the usual handful of entries a bridge-mode container would show, including its own virtual interface and assigned address, the output lists exactly one entry: the loopback interface, typically shown as active and healthy, since it genuinely is fully functional, simply with nothing else alongside it. This single-line output is, in a very real sense, the entire story of none network mode made visible: not a broken or misconfigured setup, but a namespace doing precisely what it was asked to do, and nothing more.

Following one full start-up sequence shows exactly where none network mode shortens the usual path, and what a person actually sees afterward.

sequenceDiagram
    participant U as You
    participant CLI as Docker CLI
    participant D as dockerd
    participant K as Linux kernel
    U->>CLI: docker run --network none myapp
    CLI->>D: forward run request with none network option
    D->>K: create a fresh, private network namespace
    K-->>D: namespace created
    D->>K: bring up only the loopback interface inside it
    K-->>D: loopback ready, nothing else configured
    D-->>CLI: container running
    CLI-->>U: no IP address, no published ports, no external route

A person inspecting a running none-network container will find it has no IP address listed at all, since none was ever assigned, and no published port mappings, since publishing a port would have nowhere meaningful to forward traffic to in the first place, given there is no external interface for that traffic to arrive through. This can initially look like something failed to a beginner used to seeing a private IP address listed for every other container, but it is simply the expected, correct result of deliberately choosing this mode.

What the rest of the lifecycle looks like

Every other stage a container passes through, created, running, paused, stopped, and removed, works exactly the same way under none network mode as under any other, since those stages are fundamentally about the container’s main process, not its networking. The one meaningful difference is that there is simply nothing network-related to clean up or reconfigure at any of those stages, since nothing beyond the mandatory loopback interface was ever set up in the first place.

What a failed connection attempt actually looks like

The specific error a process receives when attempting to reach an external address from inside a none-network container typically indicates, quite plainly, that no network route exists to the destination at all, rather than a timeout or a connection being actively refused by something on the other end. This distinction is worth recognising, since a timeout or a refused connection would suggest the network path exists but something further along declined the request, whereas a no-route error correctly reflects the actual underlying situation: there was never a path out of the container’s namespace to attempt that connection through in the first place. Recognising this specific kind of error quickly is useful during troubleshooting, since it immediately points toward the networking mode itself as the explanation, rather than sending someone searching for a misconfigured firewall rule or an unreachable remote server that was never actually the problem.

Docker’s networking modes sit along a clear spectrum, from fully isolated to fully shared, and none network mode sits right at the opposite end from host network mode.

None network mode and host network mode are, in a genuine sense, mirror images of each other. Host network mode removes the boundary entirely, merging a container into the host’s own networking for maximum reach and performance. None network mode builds the strongest possible version of that boundary, refusing to connect the container to anything beyond itself for maximum isolation. Bridge mode occupies the practical, balanced middle ground most containers actually need, which is exactly why it remains the sensible default, with teams only stepping toward one extreme or the other for a specific, deliberate reason.

Overlay networks sit on a different axis entirely

It is worth briefly noting that overlay networks, mentioned in the comparison table above, are not really positioned on the same isolation spectrum as none, bridge and host network modes at all. Overlay networks solve a different problem: how containers on separate physical machines can communicate as if they were on one shared network, which matters for multi-host clusters managed by an orchestrator. None network mode’s concern is single-machine isolation, deciding whether a container can reach anything beyond itself at all, a question that remains meaningful and largely unrelated to whether an environment happens to span one machine or many.

Removing all connectivity is not a compromise most everyday applications want, but a handful of genuine situations call for exactly that guarantee.

A container with no networking still needs a way to receive its input and hand back its results. Docker’s other features cover exactly this.

Removing network access does not mean removing every way of moving data in and out of a container; it simply removes the network as one of those ways. Volumes and bind mounts, covered in depth elsewhere, remain fully available and unaffected under none network mode, since they operate through the file system rather than through networking. A none-network container can read input files placed into a mounted volume before it starts, and write its results back out to that same mounted location, all without ever needing a single network connection at any point in the process.

Similarly, environment variables and command-line arguments passed in when the container is started remain a perfectly normal way to configure a none-network container’s behaviour, since these are supplied directly by the engine at start-up time rather than fetched over a network connection from anywhere. A well-designed batch job or security-sandboxed task, built with none network mode in mind from the start, typically receives everything it needs this way: input through a mounted volume or passed-in arguments, configuration through environment variables, and its output written back to another mounted location once it finishes.

flowchart LR
    Vol["Input files: mounted volume"] --> Ctr["None-network container"]
    Env["Configuration: environment variables"] --> Ctr
    Ctr --> Out["Output files: written back to a mounted volume"]

A worked example, described in words

Consider a task that needs to compress a large batch of sensitive files sitting in internal storage, without any of that data ever leaving the machine performing the compression over a network. Such a task can be built as a container that mounts the folder of sensitive files as a read-only volume, mounts a second, separate folder as the destination for its compressed output, receives any settings it needs, such as a compression level, through an environment variable, and runs the entire compression process under none network mode from start to finish. Every requirement the task actually has, reading input, writing output, and being configured, is satisfied entirely through the file system and start-time configuration, leaving genuinely nothing for the removed network access to have been needed for in the first place.

None network mode is a genuine, deliberate trade, exchanging convenience for a structural guarantee, not a strictly better or strictly worse option than the default.

None network mode is one of the strongest tools available for containing a specific kind of risk, but it is important to be precise about exactly which risk it addresses.

Why exfiltration is the specific risk it targets so well

Among the many kinds of harm a compromised or malicious process might attempt, data exfiltration, the act of secretly sending information somewhere it should not go, is one of the few that almost always fundamentally depends on network access to succeed. A process that cannot write to sensitive files cannot damage them; a process with no elevated kernel privileges cannot easily escape its container; but a process attempting to leak data it can already read, whether that is a decrypted secret, a customer record, or the contents of an environment variable, needs some channel to send that data through to somewhere outside the container’s own boundary. None network mode removes precisely that channel, which is exactly why it pairs so naturally and so effectively with any workload whose main risk profile centres on protecting the confidentiality of the data it touches, even when other risks around that same workload are being separately managed through other means entirely.

Because none network mode removes an entire category of connectivity, it also removes several habits people normally rely on to observe and manage a container.

The most immediate practical consequence is that any monitoring or logging approach depending on the container sending data out over a network connection, such as forwarding logs directly to a remote logging service or exposing a metrics endpoint for something else to pull data from, simply cannot work under none network mode, since there is no network path available for that traffic at all. Logs must instead be captured the way Docker captures them by default, through the container’s standard output and error streams, which the engine records independently of the container’s own networking, or written directly to a mounted volume the container can access through the file system rather than the network.

Health checks defined for the container, if used, are generally still able to run correctly under none network mode, provided the check itself only needs to inspect something local to the container, such as confirming a specific file exists or a particular local process is still running, rather than making a network request to an endpoint the container would otherwise expose. A health check written assuming ordinary bridge-mode networking, expecting to reach a local web server over its usual address, needs to be reconsidered entirely for a none-network container, since that networking path is exactly what has been removed.

Auditing and after-the-fact review

Because a none-network container has no way to communicate externally while it runs, verifying what it actually did afterward relies entirely on what it left behind in its logs and in whatever mounted volume it was given for output, rather than on anything that might have been observed passing over a network at the time. For workloads specifically chosen for none network mode because of their sensitivity, this actually becomes a useful property in its own right: reviewing exactly what a completed task wrote to its output volume, together with its captured standard output and error streams, gives a complete, self-contained record of everything that container was capable of producing, since a network-based side channel that might otherwise have gone unrecorded or partially observed simply never existed as a possibility at all.

Certain ways of reaching for none network mode work reliably again and again. Others cause confusion the first time a task’s real networking needs were misjudged.

A short, practical checklist that resolves most of the problems people run into the first time they use none network mode for real.

Watching for a hang rather than a clean failure

Not every hidden network dependency fails immediately and loudly the way a direct connection attempt does. Some libraries are written to retry a failed network operation several times, with increasing delays between attempts, before eventually giving up, which can make a none-network container appear to hang or run unusually slowly rather than fail outright the moment it starts. Setting a reasonable maximum run time for any task expected to complete quickly, and treating an unexpectedly long run as a signal worth investigating rather than simply waiting it out, helps catch this particular, quieter failure pattern before it becomes a recurring, unexplained slowdown that is harder to trace back to its actual cause later.

None network mode may sound like an edge case, but it earns a real, ongoing place in how careful teams handle untrusted code and sensitive processing at scale.

Across every one of these situations, the underlying lesson stays the same one covered throughout this guide: none network mode is reached for deliberately, precisely because a task’s inputs and outputs are already fully accounted for without a network, and removing that network entirely converts an assumption into a structural guarantee.