Docker, network_mode: host and container discovery

I use docker-compose to run my Home Assistant instance in network_mode: host together with an MQTT server and ozwdaemon in separate containers.

I can use the container name in ozedaemon to connect to the MQTT server (since they end up on the same custom compose network). However, to connect to the MQTT server from Home Assistant, using the MQTT server container name doens’t work, since Home Assistant runs in network_mode: host and isn’t part of the same docker composer network.

Now, I can manually lookup the MQTT servers IP address and setup the MQTT integration in Home Assiatnt using the IP address, but when the docker compose network ends up being recreated (e.g. when running upgrades or something else), I may end up with a different IP address for the MQTT server container and then Home Assistant fails to connect.

I’ve been scavenging through the Docker documentation trying to figure out how to set this up in a way that I can refer to my MQTT container by name instead of fixed IP address, but without moving Home Assistant off of network_mode: host, I don’t see an option to do that.

Any advice or thoughts greatly appreciated.

Figured out a way that works. Instead of using

- port

to expose the service port to the docker network, I now just use


to map the service port to the local host address on the host machine. That way I can point Home Assistant at to look for the MQTT server.

1 Like

Hi, where doyyou find this solution? II hhave assimilar problem, I need HA docker connect to my nginx network for the reverse proxy and also fully connect with my network.

network_mode: host should do that. What exactly is your problem?

The problem is that I need HA Docker in my nginx network for external accese, and as I far know i can’t have both.

What do you mean by “nginx network”. Is it in docker with a different network, or another machine in a different vlan?
As HA uses host, you can reference it thru <host_ip>:8123, whatever network your nginx is in, assuming there is a route between the two.

I have create a docker network call nginx-proxy where all my containers which needs a reverse proxy to be acces from outside are. HA is in this docker network, they are all in the same server. But so far if I change HA to host network, It can’t connect to nginx reverse proxy container so I can’t acceese from outside.

It’s not HA that needs to connect to nginx, but nginx that needs to connect to HA, and that works with host networking, as said above.

I may not have all the theory behind the nginx and lets encrypt docker, but the HA docker needs to connect one or both containers so can ask for the cert and be accesible from outside.

Before the 1st port I allready test the host networkl and doesn’t work, just in case i made a mistake, I just test it again and still doesn’t work.

Fair enough. Not sure how those add-ons work, really.

I have NGINX access to Home Assistant Container working fine with Home Assistant running in Host Network mode. I’m using the SWAG docker container and there is more about it on this thread with sample composes, configs, and instructions - Nginx Reverse Proxy Set Up Guide – Docker . The important key here is that as @koying pointed out above you need to reference the whole IP of the host machine and then add :8123 in you NGINX config. For example in the nginx config pasted below you reference home assistant by Because of host networking mode you cannot reference it by docker container name, and since Home Assistant is not a part of the docker network you cannot reference it by the docker IP either. When you use Host network mode, it’s as if the container is running on the “bare metal” of the host machine from a networking perspective. You have to spell out the whole IP of the machine it is running on in your nginx config. Additional configuration is necessary in nginx to allow websocket connections that Home Assistant relies on as well, which is in the example below too. The example has Home Assistant running on a subdomain from duckdns using SSL and a letsencrypt cert, accessible by

## Version 2020/05/23 - Changelog:

# redirect all traffic to https
server {
	listen 80 default_server;
	listen [::]:80 default_server;
	return 301 https://$host$request_uri;

# main server block
server {
	listen 443 ssl http2 default_server;
	listen [::]:443 ssl http2 default_server;

	root /config/www;
	index index.html index.htm index.php;

	# enable subfolder method reverse proxy confs
	include /config/nginx/proxy-confs/*.subfolder.conf;

	# all ssl related config moved to ssl.conf
	include /config/nginx/ssl.conf;

	# enable for ldap auth
	#include /config/nginx/ldap.conf;

	# enable for Authelia
	#include /config/nginx/authelia-server.conf;

	# enable for geo blocking
	# See /config/nginx/geoip2.conf for more information.
	#if ($allowed_country = no) {
	#return 444;

	client_max_body_size 0;

	location / {
		try_files $uri $uri/ /index.html /index.php?$args =404;

	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;


### HOMEASSISTANT ##############################################################
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name hass.*;
    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver valid=30s;
        set $upstream_app homeassistant;
        set $upstream_port 8123;
        set $upstream_proto http;


    location /api/websocket {
        resolver valid=30s;
        set $upstream_app homeassistant;
        set $upstream_port 8123;
        set $upstream_proto http;

        proxy_set_header Host $host;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
# enable subdomain method reverse proxy confs
include /config/nginx/proxy-confs/*.subdomain.conf;
# enable proxy cache for auth
proxy_cache_path cache/ keys_zone=auth_cache:10m;

I understand what you are saying, thanks. But my problem is that I’m usuing another complement other than swag, the one I’m using configure it self. I pass my duckdns info through docker enviromentals and do it’s magic. Docker Hub

The letsencrypt-nginx-proxy-companion relies on binding to the host docker socket and changing/reading the socket to work, which is actually a terrible security risk - Get informed of the risks associated with docker.sock

Also, Since Home Assistant is running in Host network mode it isn’t part of the docker network and it’s not going to work with this proxy, as the proxy companion container relies on accessing and manipulating the docker network to function, as you have experienced. I don’t believe there is any way you can make it work, and issues on the containers github related to this were closed and the user ultimately went with another option for their reverse proxy. "Host" Network containers · Issue #746 · nginx-proxy/acme-companion · GitHub Cert renewals fail when nginx proxy runs in network mode "host" · Issue #600 · nginx-proxy/acme-companion · GitHub . If you insist on trying to make it work maybe you can open a new github issue and gain feedback directly from the developers.

I know it sounds nice that it can configure things for you and is simpler, but “simple” doesn’t always work. Unless I’m missing something proxy companion won’t work with a container running in Host networking mode and Home Assistant requires running in Host network mode for a supported home assistant docker install. You’re better off with something like Swag that others are using reliably even if it is more work to setup. You also can pass duckdns info to Swag through environment variables and it renews the lets encrypt certs automatically. The only difference really is you have to modify the nginx config yourself and I posted an example of a working one for you above.