Introduction

When people ask how to pass --net=host to docker build, they usually mean "how do I make build steps use the host network." The important detail is that build-time networking is separate from container runtime networking. For image builds, the relevant flag is --network=host, and it affects RUN steps during the build, not the networking mode of containers started later from the image.

Build Networking Versus Run Networking

docker run --network=host changes how a running container uses the network. docker build --network=host changes how the build container reaches the network while executing RUN instructions.

That distinction matters because developers often expect a build flag to be baked into the final image. It is not. The build network mode only applies while Docker is constructing image layers.

The Correct Build Command

If your Docker version supports it, the build-time flag is:

docker build --network=host -t my-image .

This is the modern spelling. Some older discussions mention --net=host, but for docker build the commonly used form is --network=host.

It helps when build steps need to reach services exposed only on the host network, or when host-style name resolution is required during package installation or artifact fetching.

Example Dockerfile Scenario

Suppose a build stage needs to contact a package cache running on the host.

1FROM python:3.12-slim
2
3WORKDIR /app
4COPY requirements.txt .
5RUN pip install --no-cache-dir -r requirements.txt
6COPY . .

If the RUN pip install ... step must access a host-only service, building with --network=host may solve it:

docker build --network=host -t my-image .

The network mode is only relevant during the RUN layer execution.

What This Does Not Do

This does not mean containers created from my-image will automatically run in host networking mode. You still need to specify that separately at runtime if you want it:

docker run --network=host my-image

That separation is often the source of confusion.

Platform and Builder Considerations

Host networking behavior is most straightforward on Linux. On other platforms, especially where Docker runs through an additional virtualization layer, host-network semantics can be different or more limited.

Also remember that BuildKit and the legacy builder may differ in behavior around build-time features. If a networking trick behaves unexpectedly, confirm which builder is active and whether the environment actually supports host-style networking the way you expect.

When You Really Need This Flag

Use --network=host only when the build step has a concrete networking requirement, such as:

• reaching a service bound only to the host
• using a host-local package mirror
• debugging restrictive build-network conditions

If the build only needs internet access, the default build network is usually enough.

Security and Reproducibility Tradeoffs

Host networking gives build steps broader access to the machine's network environment. That can make builds less isolated and less reproducible.

A build that depends on host-only services may work on one machine and fail on another. So even when --network=host fixes the immediate issue, ask whether the dependency can be moved into a more portable build setup.

Common Pitfalls

The biggest mistake is assuming docker build --network=host changes the final image permanently. It does not; it only affects build-time RUN instructions.

Another mistake is confusing docker run networking flags with docker build networking flags. They solve different problems.

People also forget platform differences. Host networking is much more predictable on Linux than on environments that rely on a hidden VM.

Finally, do not use host networking as a default habit. If the build does not actually need it, the extra isolation of the default network is usually better.

Summary

• For build-time host networking, use docker build --network=host.
• The flag affects RUN steps during the build, not the final image's runtime behavior.
• If a container should also use host networking later, set that again with docker run.
• Host networking is most straightforward on Linux and may behave differently on other platforms.
• Use the flag only when the build genuinely needs access to host-network resources.