It seems that starting from 2027.02, it is no longer possible to use the http: block in the YAML-Configuration file, one needs to use the WebUI for that.
Now, if you install Home Assistant in an Environment which automatically sets up reverse proxy (without ever exposing Home Assistant directly), how does someone gain access to Home Assistant starting from 2027.02?
Am I missing something or is this yet another step to force users into Home Assistant OS?
Can’t you just go from the internal network to http on the internal HA IP, bypassing the proxy?
How would an reverse proxy (external or internal) affect Home Assistant at all? As @fleskefjes said, it just uses http on local…
Or am I missing something?
No, accessing Home Assistant directly circumventing the Reverse Proxy is not an option. We’re talking a secure, user friendly option, that is. A user does not understand or need to know how a reverse proxy works or how to circumvent it.
Yes you are missing something. Home Assistant blocks access via Reverse proxy per default. So it affects it in the most relevant way possible. You need to whitelist the proxy you’re using via http.trusted_proxies which will be disabled starting with 2027.02
Oh, is that what you meant.
That also moved to gui:
Either way, you still need to specify it manually in the gui (which used to be under http: yaml).
I assume though, as is the case for your setup, the user does know how it works and will be able to set it using local access, before switching to reverse proxy….no ordinary user should use reverse proxy in a docker environment, without knowing how it works 
I also find this a very weird and concerning change. If there’s any setting that should remain in the yaml, this is the one.
This is the one setting that every single software out there, even the ones with no configuration file at all, lets you configure without using a webUI, and that’s for very obvious reasons.
Is there anywhere we can read about the reasoning behind this deprecation?
The PR that implemented this doesn’t go in detail about why this deprecation was even remotely necessary, and I find it to be a concerning change: if ones current http config becomes unusable for whatever reason (unexpected server migration, new router from a shitty ISP, using the port for something else, etc), how would they change these access configurations if the webUI cannot be accessed?
Same goes for a first-time setup where the default port is inaccessible or whatever, how would one change the broken http settings if you need the http settings to be working in order to change the http settings?
This is also true for if you get something wrong when setting up https for the first time, I guess the backup settings would help in this case but otherwise you could end up needing a full reinstall if you do a single wrong configuration…
I truly hope this isn’t a move away from the ability to configure Home Assistant in yaml in general. The declarative yaml configuration and UI settings always coexisted in harmony in Home Assistant, see for example how you can have both yaml and UI automations at the same time and stuff, and the configuration file is a great way to declaratively configure the software without having to worry about manually doing these configurations on a new installation. Plus, sometimes wrong settings can break Home Assistant from launching (like any software out there) so the ability to change them without relying on a working connection to the web UI is very important. I see no reason why the UI couldn’t exist while still keeping the yaml configuration, just block the UI with an “already configured via yaml” alert when that’s the case, like is already done for the homeassistant: key in configuration.yaml.
I myself made Home Assistant totally inaccessible many times when trying to configure https and reverse proxies, until I eventually gave up. The only reason I was able to recover was the configuration being accessible without needing the web UI. I guess now I’m just never trying to configure that again, because I’m definitely not risking having to do a full reinstall and reconfigure all my zigbee devices if something goes wrong.
I really hope they revert this yaml deprecation, the new UI can coexist just fine with it.
Completely and strongly disagree.
Home Assistant without a reverse proxy is insecure per default. Claiming this is the supposed way for a regular user is just stupid.
Update: It’s even worse, it stops working already from 2026.8 alas NOW on an new install as it fails to import the http: config on a new install, meaning home assistant fails to start with the trusted_proxies settings.
2026.7 still had the http section, so that doesn’t make any sense. You likely had yaml issues. From 2026.8 will migrate the section to the UI on startup, post 2027.2, it’ll need to be setup via the ui (or storage files if you’re savvy enough).
Anyways, these values can be adjusted offline from the storage files if needed.
Yeah you’re right. Somethings off. After trying again, it just worked. Even 2026.8 worked now after previously failing to import the settings and clearly stating this in the logs.
Why is that?
The only insecure thing would be to expose plain http to the outside (enabling remote access)
But there are other ways to establish that securely, https, vpn, nabucasa…
Exposing http is insecure, period. If you have not set up the service (ha in this case) hence not yet put behind a login makes things worse.
Local only doesn’t make it secure, it’s just not as risky as non-local.
Running HomeAssistant 2026.8.2 via docker, after getting the deprecation warning, I’m not seeing this Server configuration or the ability to add trusted proxies.
Is this an oversight, or is there no way to add a trusted proxy configuration in the docker version? Or was it moved to a different place for the docker version?
Clear your cache and refresh the page
EDIT: @petro’s response is the answer. Clearing cache and refreshing the page fixed it. Thanks!
@trisweb I’m running HA in Proxmox and have the same issue. Running 2026.8.2 and have the deprecation warning but no HTTP server settings under network (see screenshots below).
@aceindy, can you point out where those HTTP server settings in your screenshot are meant to be?
/Settings/System/Network
I have to say this is a pretty dumb change. So in order for us to set trusted proxies to access the UI, we must use the UI to set the trusted proxy so that we can access the UI? WTF. No one saw an issue?
This JUST bit me now. As I am running a lot of services in docker, sometimes during restarts, the docker network IPs change. Annoying, but it happens. I’ve lost access to home assistant because it doesn’t trust the reverse proxy. I cannot log onto the UI to update the reverse proxy.
I do not run HA in host networking mode, so there is no exposed HTTP port. I’m effectively locked out because for some reason the devs thought it was a good idea to move HTTP proxy information to the UI THAT YOU MUST HAVE VALID PROXY SETTINGS FOR. What in the world was the thought process on this?!
Yes, I fixed it by editing /.storage/http to fix this. But WHY was this is a necessary change?! it was so simple in the configuration yaml.
You can edit the http file in .storage, it has the same parameters.
It’s not only insecure, most browsers now refuse to access insecure sites by default.
