Ever wondered why the address for your own home has a random number stuck on the end?
Nope. That thought has never crossed my mind.
What I’ve always wondered and keep wondering is how to debug these dang thread pairing failures. I want that to be more approachable.
The address for my home doesn’t have a random number stuck on the end… Unless they’re talking about the Zip code, which is a super useful thing, so I don’t wonder why it exists.
Edit: Read the article. Even with the added context that home, in this case, means home assistant, no, I didn’t wonder why the service has a random number on the end of it, as that’s how all services work. That is a weird way to put it, even though the change seems to make sense.
They’re changing HA’s port from 8123 to 80? That seems inconvenient for anyone not running HA on its own dedicated machine.
You can change it, not compulsory. New installs will default to 80.
Looks like it only applies to Home Assistant OS which would be a dedicated machine/VM, not container or other installation strategies.
EDIT: The internal listen port is still 8123: https://github.com/home-assistant/core/blob/938a78275e9a858a0364fe13390d2f583f70ebe4/homeassistant/const.py#L970
Ah, that makes more sense.
There’s two supported ways to run Home Assistant:
- Home Assistant OS
- Docker container
In both cases, it’s running on its own IP address, so nothing else will be using port 80.
With Docker, you’d normally either use its standard NAT network, or bridge it to your LAN using a macvlan or ipvlan network. Bridging is usually better because some devices rely on broadcasts.
You used to be able to run Home Assistant directly on an existing Linux system, but that’s been deprecated for over a year and unsupported since December last year.
A docker container’s IP usage heavily (entirely) depends on how the container’s networking is defined by the host machine. And in an overwhelming amount of cases, that host networking will be a “here’s a device-local subnet your containers can join to”, so no, a Docker container won’t by default “get it’s own IP address” (colloquially, “its own IP address” would refer to a device getting a LAN-local address assigned to it from the local gateway/DHCP server), at least not one other devices on the network can access.
Also claiming that “nothing else will use port 80” is a gross over-simplification.
The move to port 80/443 on HAOS makes sense as it simplifies setup for total beginners.
Your comment isn’t entirely accurate.
in an overwhelming amount of cases, that host networking will be a “here’s a device-local subnet your containers can join to”, so no, a Docker container won’t by default “get it’s own IP address”
With the default NAT network, it gets its own IP in the 172.16.x.x range that Docker decides to use. That IP is accessible from the Docker host. It doesn’t matter that it’s not on your LAN - it’s still a dedicated IP. Port forwarding (or a reverse proxy) to it is a separate thing, and you can map a different port if you want to.
Plenty of Docker containers use the same port (often 80, 3000 or 8000), and the reason you can use multiple of those containers concurrently is because each one is on a separate IP.
The default NAT network isn’t commonly used for Home Assistant, though. It usually has a direct network connection to the LAN, since plenty of smart home devices rely on broadcasts for discovery.
Also claiming that “nothing else will use port 80” is a gross over-simplification.
It’s true for both the Home Assistant Docker container and for HAOS. In both cases, there’s no other web servers running in the container/VM. For the Docker container:
-
If you’re using the default Docker NAT network, the port you use to expose it to other devices is completely unrelated to the port used in the container. When you expose a Docker port, you specify the host port and container port separately.
- Sometimes the port isn’t exposed to the LAN at all, for example if you’re using a reverse proxy. In that case, you usually use the docker container name as the upstream in your Nginx config or whatever, like
proxy_pass http://hass/
- Sometimes the port isn’t exposed to the LAN at all, for example if you’re using a reverse proxy. In that case, you usually use the docker container name as the upstream in your Nginx config or whatever, like
-
If you bridge the Docker container to the LAN, it has its own IP on the LAN and no other web servers will be running on that IP.
The actual reason that Docker containers don’t use port 80 by default is so they’re able to run in rootless mode without any extra capability grants. I don’t think Home Assistant supports rootless mode though.
-
The port can now also be configured in the web ui.
I’ll just wait for my reverse proxy to tell me it can’t find HA lol
@Bakkoda
If you were to implement that change, would you apply it to existing deployments?
No?
So why do you expect them to be dumber than you are?We can’t all aspire to be as wise as you
If you are already running Home Assistant, nothing changes and there is nothing you need to do. This only affects new installations of Home Assistant OS. Your existing installation is completely unchanged, keeps the exact port it has always used, and keeps working just as before.
Sounds like it’ll work as usual with proxies.
Good call out. Thank you.
