host.docker.internal: The Magic Docker DNS Name

When working with Docker containers, one common challenge is how to connect from inside a container to other services - whether they're running directly on your host machine or in other containers. While Docker provides several networking solutions, there's one particularly elegant solution that's often overlooked: host.docker.internal.

What is host.docker.internal?

host.docker.internal is a special DNS name that Docker Desktop provides to containers. It resolves to the internal IP address of the host machine, allowing containers to communicate with any service that's accessible through your host - whether that service is running natively on your machine or exposed by another container.

Think of it as a consistent, reliable way to say "hey container, when you need to talk to something through the host machine, use this address!"

Why is it useful?

Imagine these common scenarios:

• You're running a containerized application that needs to communicate with another containerized service
• You have multiple Docker Compose projects running independently that need to interact
• You're developing with a local database running directly on your machine
• You need to connect to development tools installed natively on your host
• You're building a microservices architecture where some services run in containers while others run directly on your host
• You have separate Docker environments that need to communicate with each other

Instead of dealing with IP addresses that might change or complex network configurations, host.docker.internal provides a stable, reliable way to reference anything that's accessible through your host machine - whether it's running natively or in another container.

How to use it

Let's say you have a service running on your host machine on port 3000. From inside your container, you can access it like this:

$hostService = 'http://host.docker.internal:3000';

Platform Support

• Windows: Supported out of the box with Docker Desktop
• macOS: Supported out of the box with Docker Desktop
• Linux:
  • Docker Desktop: Supported out of the box
  • Docker Engine: Requires additional configuration
  • WSL2: Supported out of the box

Best Practices and Considerations

1. Development Only: While host.docker.internal is incredibly useful for development, it's not suitable for production environments. Your production containers shouldn't need to access the host machine.

2. Environment Variables: Consider using environment variables to make your connection strings configurable:

   API_URL=http://host.docker.internal:3000

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com