I would suggest reconsidering the no VMs part, especially if your laptop is overpowered for HA alone. I’ve been running HAOS in proxmox on a refurbished gaming laptop for a couple of years now and couldn’t be happier.
Re the clean shutdown part, you need to be 100% sure this is being handled by the BIOS and not by Windows or whatever OS is currently installed.
I’d err on the side of caution and set an HA automation to do a clean shutdown if battery gets too low. Happy to share my automation with you if you need it.
If it supports the prerequisites then yes. If it does not support UEFI booting you could also virtualize HAOS. I think it makes for a much more reliable setup. I wouldn’t trust HAOS to run bare metal remotely like that.
Now that you mention it, the auto-shutdown is in the bios (and also the required boot on power up) so it should ‘just-work’. What about the display (X), I assume HASOS is a ‘server’ so the only access to the host OS is the console (no X & no SSH). I can enable SSH/terminal in HA but I assume that only gives me access to the HA docker instance, not the host OS.
It’s just like any other install. You can either use the laptop for direct console access (built in screen & keyboard come in pretty handy here), or else use SSH or samba for network access.
Host OS can still be accessed remotely if you install the correct SSH addon. (Hint: there are 2 addons with similar names. Can’t remember which one is the “right” one)
Auto shutdown is a mix of BIOS and OS.
HA core is not that good at listening for shutdown events from the OS, so you will need some automation, but it is pretty simple to do.
What do you need display for?
SSH access should provide you with console access (if using Proxmox, then that can be used too), but if you want to show a dashboard, then you need an addon for it (it is named something with kiosk).
Are you sure https://github.com/home-assistant/os-agent/releases/download/1.5.1/os-agent_1.5.1_linux_aarch64.deb and https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb will continue to be build?
When I first saw this, I was a bit annoyed. I’ve been using HA under Debian for quite some time now and have been a Linux user from the start, very familiar with Linux.
I run QEMU/KVM on an older Dell XPS laptop, and my HA instance is a VM on it running Ubuntu Server as the hypervisor. I installed HAOS alongside it, exported backups, and imported them into HAOS. Just a few small changes were needed. I was using Postfix on my Debian setup for the mail server, so I had to install the SMTP add-on in HAOS instead. I passed through my USB ports for my Z-Wave/Zigbee stick, Bluetooth adapter, and APC UPS, and everything worked fine.
I’m a huge fan of running VMs for one simple reason: snapshots. They save the current state of the VM before doing any work or major upgrades. That feature has saved me in the past when I accidentally messed something up and needed to restore the snapshot.
My Dell XPS has also had its battery replaced, so it’s fresh and basically acts as a built-in UPS, giving me around six hours of runtime if I lose power. I’ve configured the Dell XPS to automatically boot when AC power is restored, so if there’s an extended outage, it will come back online once power returns.
So basically, transitioning to HAOS wasn’t that difficult or that much of a PITA.
Then, I believe someone will have to take over the maintenance of the debian packages of both os-agent and superviserd-installer.
Can the HA team give the community the instruction/documentation/code they have how to build these debian packages?
It’s been a long time since I’ve installed my supervised installation and that I haven’t upgraded Debian, so I don’t recall very well, but: Is this now the reference (community) documentation how to install HA supervised on Debian? Installing Home Assistant Supervised using Debian 12
I just found out about this after a 2025.6 upgrade; I haven’t ovbiously read the full thread but probably anything I will say has already been said.
My fear going forward is that Supervised being deprecated will eventually cause add-ons and/or the core systems to be unworkable; but I guess I’ll soldier on as long as I can and hope that this decision is somehow reversed.
I use the Supervised installation in two ways: one on a RasPi 5, one on a NAS. Both of these complain that they are “unsupported” due to the other docker containers present. The only logical “supported” system for me now would be HAOS - if I were more of a docker expert Container would be fine but I’m not (every time I try a docker-compose that I find on the web, it doesn’t work - I kid you not, they never work for me; there’s something special/cursed about me and my systems).
And so I went with Supervised for two reasons on the Pi:
(1) an old Pi4 died and I erroneously assumed a replacement Pi5 would be fine; it took a lot of effort to make it work.
(2) the Pi5 (and Pi4) is an amazingly powerful kit for such a small package. It is grossly unreasonable to assume that such a kit can only handle HA and (maybe) some add-ons (as in HAOS). I have plenty of other services on the Pi5 and none of them have ever caused problems for HA/Supervisor (except the “unsupported” warnings).
On the NAS naturally I can’t install HAOS. Supervised was the next best thing although, again, it took a lot of tweaking to get it right.
Core and Container installs are both well beyond my capabilities.
Then you have something else going on. I have HAOS running on an 8GB RPI5 that is actually using a HAOS VM via KVM! Also, that was installed on Aug 1, 2024 as vanilla (generic) then doing a google backup addon restrore restoring from an HA Supervised instance backup, I was up and running very quickly and it has been running smooth as a top ever since.
I don’t see how running HAOS from a VM is related to their comment. They were talking about running HAOS directly on RPi. You avoided the problem they described by not running HAOS on an RPi (instead you run it in a VM).
Not saying what you did was incorrect and it was likely a good idea even. I’m just pointing out it’s not the same thing.
Yes my bad I went from an RPI4 bare metal HA Supervised (running from an SSD on USB) to a VM HAOS on an RPI5 (with an NVME). The RPI4 would occassionally go on vacation with one line of binary data at the end of the syslog, requiring log cleanup and reboot. Evidently that problem was an “open secret (known)”. I got around that by having HA reboot the RPI4 reboot twice a week. I hope the bare metal RPI5 install doesn have the same “open secret” issue (I was able to remove that reboot logic with no issue)…
