Support http.server_host for Docker installations

[AliveDevil]

The problem

I'm unhappy with the introduction of #155849, as people who deployed Home Assistant using Docker, and put a reverse-proxy infront of it, are now forced to find new ways to limit which interfaces Home Assistant binds to.

You are specifically calling out "--network host", and expect us admins to deal with it: https://www.home-assistant.io/installation/linux#platform-installation

However, when putting a reverse proxy infront of Home Assistant, I don't want Home Assistant to bind to everything, but the loopback device so I don't have to think about it anymore. With this change, and deprecation, this got much more cumbersome to use.

Please revert, just because one installation method got deprecated, and another one doesn't support this, doesn't mean the third, which is similar to the deprecated one doesn't still have valid use cases for binding to a specific interface.

What version of Home Assistant Core has the issue?

2025.12.0

What was the last working version of Home Assistant Core?

2025.11

What type of installation are you running?

Home Assistant Container

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response

[home-assistant[bot]]

Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (http) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of http can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign http Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

http documentation http source _{^{(message by IssueLinks)}}

[skandalfo]

I didn't choose or support the deprecation of the "Core" installation method.

I'm running a "Core" install with a Caddy reverse proxy handling virtual host-based application multiplexing, TLS termination and certificate management. This has worked very well for a long time for me.

The removal of http.server_host for all installation methods (including Core) means I now need to meddle with firewall settings elsewhere to prevent access to my HA non-TLS port 8123 from the Internet, as my machine also has a globally reachable IPv6 address. Now port 8123 is exposed when before it was not (HA was publicly accessible only via 443 and only if the client knew the right virtual host to use).

Given the docs already caution in a big warning box against using this setting outside of the Core installation method, the motivation given in https://github.com/home-assistant/core/pull/155849 feels extremely feeble.

Even if for different reasons, I second @AliveDevil 's request for a revert of the above change.

[skandalfo]

See related: https://github.com/home-assistant/core/issues/157981

[reflectivecode]

I attach macvlan networks to my docker container so that my HA installation can sit in multiple VLANs. There is no easy way to setup firewall rules INSIDE the docker container to prevent access from those VLANs. Removing interface binding would be a big step backwards in backwards in securing an installation like mine.

[graelo]

I agree 100% with the comments above. I'm in the same situation, and honestly don't see why remove this popular & desirable option to bind a service to an address.

[obi11235]

I also disagree with the decision to remove the server_host configuration option. I'm using the docker installation method, which is continuing to be. The note in the instructions is wrong about the setting only being used for the core installation method. In order for some integrations to work with docker, it's necessary to use host networking for the container in order for auto detection for those integrations to work correctly, this gives the container access to all interfaces on the host and HA will bind to all of them. I don't want to run dedicated hardware for HA and i run multiple copies of HA in docker (some with host networking and some with out, for development and other purposes). With out this setting it makes it more complicated to manage the networking for HA. I can't leave all the instances on the standard port on the system.

Using VMs is not an acceptable solution for me since i don't use VMs in my setup and do not want to add them because this functionality is being removed.

If the setting causes problems for HA OS I'd support adding it as an environment variable that way it can be set for container installations and wouldn't be confusing for HA OS.

[jaredmontoya]

I also don't see why this option has to be removed. As far as I understand it just sometimes causes issues when used with HA Supervisor. This isn't something that can't be solved through just informing users about this in the documentation, they'll have to read it anyway if they are editing yaml. But if it really has to be removed then just remove it from the supervisor installs and keep it everywhere else.

[bjoernwuest]

Since 2025.12.2 I get the warning that the server_host config is deprecated. Yet, I use the KVM image from the Home Assistant web page and wondering where to adjust this config value. Adding some more information on how to fix, e.g. a link to the proper documentation page, would help. E.g. the nextcloud software does so, which is very helpful.

[quinndiggity]

Yeah, this change is extremely anti-community, and outside that is nonsensical - maintaining a config option/env var/cli parameter for selecting a bind address is absolutely trivial, and is a standard convention for applications which expose network services. This makes no sense outside of it being a subtle attack against self-hosting community members.