Introduction

On Linux, --network host lets a container share the host network stack directly. On macOS with Docker Desktop, that behavior does not exist in the same way because containers run inside a lightweight Linux VM rather than on the native Mac network stack.

Why Host Networking Is Different on macOS

Docker Desktop for Mac inserts a virtualization layer between the container and the actual macOS host. Because of that, Linux-style host networking does not map directly onto the Mac host interfaces.

That means the real question is not "how do I force --network host on Mac?" It is usually one of these:

• how do I expose a container port to the Mac,
• how does a container call a service running on the Mac,
• how do containers talk to each other locally,
• or how do I avoid awkward development networking.

Each of those goals has a different practical replacement.

Alternative 1: Publish Ports

If the goal is "I want to reach the containerized service from my Mac browser or another local program," publish the container port.

docker run --rm -p 8080:8080 myapp

Then use the service through:

http://localhost:8080

This is the standard answer for many local development workflows that might otherwise have used host mode on Linux.

Alternative 2: Reach the Mac from the Container

If the goal is the opposite and the container needs to call a service running directly on the Mac, use host.docker.internal.

docker run --rm alpine sh -c "apk add --no-cache curl && curl http://host.docker.internal:3000"

This is the usual solution when:

• the database is running outside Docker,
• a local API server is running on macOS,
• or a containerized tool needs to call a host-only development service.

It is much more reliable than guessing the host IP from inside Docker Desktop.

Alternative 3: Use a User-Defined Network

If the goal is container-to-container communication, use a custom Docker network or Docker Compose. That way containers can reach each other by name.

docker network create devnet
docker run -d --name api --network devnet my-api
docker run --rm --network devnet alpine ping -c 1 api

A Compose version is even more common:

1services:
2  web:
3    build: .
4    ports:
5      - "8080:8080"
6    depends_on:
7      - db
8  db:
9    image: postgres:16
10    environment:
11      POSTGRES_PASSWORD: secret

Inside that network, the web service can reach the database using the hostname db. For many local stacks, this removes any need to think about host mode at all.

Choose the Replacement Based on the Actual Need

A good rule is:

• use -p when the Mac host needs the container,
• use host.docker.internal when the container needs the Mac,
• use a user-defined network when containers need each other.

Trying to reproduce Linux host mode exactly on macOS is usually the wrong level of abstraction. The better path is to identify which communication pattern you actually need and choose the matching Docker Desktop-friendly mechanism.

Common Pitfalls

• Expecting --network host on macOS to behave like native Linux host networking.
• Using host-mode thinking when explicit port publishing would be clearer and safer.
• Hardcoding guessed host IP addresses instead of using host.docker.internal.
• Mixing up container-to-host and container-to-container requirements.
• Treating Docker Desktop networking behavior as a bug instead of a platform constraint.

Summary

• On macOS, Docker Desktop cannot provide Linux-style host networking in the same direct way.
• Use -p port publishing when the Mac needs to access the container service.
• Use host.docker.internal when a container needs to call a service on the Mac.
• Use user-defined networks or Compose for container-to-container communication.
• Pick the alternative that matches the actual networking requirement instead of trying to force true host mode.