Been running HA as a Docker container on my main server for about a year now and it’s finally time to give it its own box. Got a spare HP EliteDesk 800 G5 Mini knocking about (i3-9100T, 8GB RAM, 256GB NVMe) so the plan is to wipe it and go full HAOS. Before I actually do it I want a few more eyes on the plan in case I’m missing something obvious.
Current setup
HA container on my main server, stuck on a macvlan network to get it a real IP on my IoT VLAN, plus a bridge network so the host can actually talk to it (yeah, macvlan containers can’t reach their own host, that took me a while to figure out). Zigbee2MQTT and Mosquitto also run as containers on the same box, USB Zigbee dongle passed through.
It’s mostly worked but it’s been a bit of a pain. Matter needs its own bolt-on container under HA Container mode, HACS needs a manual zip install rather than the proper add-on route, and I’ve had firewall rules quietly break more than once when the container gets recreated and its internal IP shifts.
The plan
Wipe the EliteDesk, install HAOS proper (not Container, not Supervised - want the add-on store and the native backup/restore, and it kills off the privileged:true blast radius the current container has)
Full backup from the current instance via Settings > Backups, restore it onto the new HAOS install during onboarding
Move Zigbee2MQTT and Mosquitto over too, as HAOS add-ons rather than leaving them behind - want this box properly siloed off my main server, not half-migrated
Physically move the Zigbee dongle across and restore from the coordinator backup rather than re-pairing everything
Keep the same static IP so I don’t have to touch existing firewall/router rules pointing at it
Get it onto the NUT shutdown chain for my UPS, since it’s now a separate box that needs its own graceful shutdown on a power cut
Bits I’m not 100% sure about, would love input if you’ve done similar
Nabu Casa / HA Cloud - I’ve got a paid sub with a custom domain and Alexa linked. Their docs say restoring a full backup onto new hardware is the supported path for keeping Cloud working, but has anyone actually done this and had it carry over cleanly, or did you end up re-authenticating from scratch?
NUT on HAOS specifically - is there a proper add-on for this or does everyone roll their own? Coming from HA Container where I just used the built-in integration talking to an external NUT server.
Zigbee coordinator migration - restoring coordinator_backup.json onto a fresh Z2M install on new hardware, anyone hit issues with this or does it really just work as advertised?
Anything else people usually get bitten by going from Container to HAOS specifically, rather than a generic reinstall?
Not in a rush, want to get this right first time rather than debug it live. Cheers in advance.
Brilliant, thanks! Found the app-nut repo, going with network client mode pointing at my existing NUT server. That’s one of my four open questions sorted, appreciate it.
Yes, put it on its own box. I find HAOS runs better under Proxmox than on the bare hardware. I run Z2M on a Proxmox VM rather than it being an add-on to HAOS. Then on the old server run Proxmox Backup Server and back up the entire HAOS VM automatically, at least every day, or even every few hours as there is nearly zero cost. The Proxmox host is headless. This is a big deal as you now can get to the system console from any web server worldwide. And if the hardware goes up in smoke, it is trivial to stand up a new server in under 5 minutes or if you set up a cluster, you have automated failover.
People expect their lights and heating to “just work” for decades at a time. Some day you will be 70+ years old and do you still want to futz with this? No, it has to be automated and reliable to the point where years go by and you do nothing. The VM layer under HAOS adds a lot of maintainability and makes monitoring easy.
If you are building out an HA system, your goal should be to make it invisible and zero-maintenance. Today this is not possible, but we can try to get as close as possible
Appreciate this, v useful perspective. Couple of things pulling me the other way for this specific box though, keen to hear if you think I’m overweighting them.
Only 8GB RAM on the box I’m using. Proxmox host plus a HAOS VM plus Z2M as its own VM feels like a lot of overhead fighting over that compared to HAOS just running with the whole 8GB to itself. Is that actually a real concern in practice or am I being too precious about it?
Bigger one for me is USB passthrough for the Zigbee dongle and eventually a matter dongle. I got properly bitten on a different box recently by USB device state not surviving a host reboot cleanly through a layer (DAS enclosure that time, not a hypervisor, but same flavour of problem), so I’m wary of adding another layer between the OS and a USB device that needs to behave consistently. Is that a genuine risk with Proxmox passthrough or is it more solid than I’m assuming?
Also the whole reason I’m doing this move is to get HA fully siloed off my main server for redundancy. Stacking it back into a hypervisor with other VMs on it feels like it reintroduces some of that coupling, even if it’s a different box. Not sure if that’s a fair read or if I’m missing something about how isolated a VM actually is in practice.
Not trying to talk myself out of a good idea, just want to understand if these are real problems for my setup or just theoretical ones.
See my other thread on issue with HA after migration - especially after choosing to run over Proxmox.
My HA ran relatively well on a Beelink J4125. I wanted to add some upgrades so invested in a Hp elite mini 800g9.
Despite care, lots of backup and photos of add-on configs I suspect you will hit snags which will need to manage- eg
-Bios upgrades and switch changes on the hp.
VPN edits to move the unique (original) machine ID to allow you to use the same IP address toward your remote access route ( I used Cloudflare)
Decide if you want the default sizing on the Proxmox VM or if you want some “headroom” to allow expansion.
In my case the add-ons and integrations transferred well. Once you change IP and manage usb passthrough Zigbee devices showed up - I still have to work out if the assigned channel (25) survived the move since I now find significant interference on 2.4ghz channel.
I’m not yet finished the move so maybe more to come but Im struggling right now with the Proxmox layer going offline - taking HA with it.
I only run bare-metal here on an Intel NUC i3, 8gB. I measure my uptime in years; only rebooting for some updates. I neither need nor want the complications that containers and virtual operating systems introduce.
I have almost 100 devices or sensors on my system, mostly WiFi or Zigbee, and backup daily to an NAS using Samba Backup.
Thanks all, really useful thread. Landed on bare metal HAOS in the end.
The RAM argument against Proxmox mostly went away once I worked out I can bump the box to 16GB, so that’s not really the deciding factor any more. Came down to two things instead: I don’t actually have a second workload for this box that’d justify the hypervisor layer, it’s staying single purpose, and I want to keep the failure modes as simple as possible on something my family relies on. Lcdxr01’s post about the Proxmox layer going down and taking HA with it stuck with me, that’s exactly the coupling I’m trying to get away from by giving HA its own box in the first place.
Really appreciate the ethernet coordinator suggestion too, SLZB-MR looks like exactly the right answer for the Zigbee/Matter dongle question longer term. A bit pricier than I want to stretch to for this round though, so I’ll stick with the USB dongle for now and revisit that later.
Cheers for the sanity check, exactly what I was after.
HAOS as VM is useful because if any of these occur your VM snapshot/backup saves you
HAOS is unbootable
Supervisor fails
No internet
HA’s own backups don’t help here as they need internet and a healthy HAOS to apply.
I have some links to example cases of how a system can break in my why virtualize article.
It also gives you the flexibility to do whatever you want in the future. Some apps dont make a lot of sense to run inside HAOS.
As a note, this occurs if you use docker IP to connect containers and depending on issue if you don’t set static IP for docker container to external network(macvlan or bridge)
Container to container should use hostname
Container to external set static IP for docker container
@aceindy
Why would a VM snapshot/backup not help here? Why would you need internet?
If the hardware fails then this is no longer a software issue and the deal is the same. Re-install and restore on working hardware.
That is why I use Samba Backup app to back up my Home Assistant to my NAS.
I also back up the SSD in my Home Assistant server every few weeks using Rescuezilla. It is a fallback in case my Home Assistant server ever turns to crap. Which in my bare metal installation has never happened.
You usually cannot restore a HA backup without internet access, no matter where that backup is stored. See here what happens if you try to
CloneZilla/RescueZilla backups are useful (basically like a VM Backup) but require to take the system “offline” which is tedious, takes time and it cannot be automated. Not quite sure how you can have a long uptime that way.
By the way, I can easily show you this behavior because I have a HAOS VM where I can just disconnect the “cable” of the NIC and still administer it as if I had a monitor attached
PS, i too started 6 years ago with HyperV, later moved to VMworkstation, I agree, it is very easy to restore a snapshot, but the last time i needed to fully restore HA is in the meanwhile also 4 years ago.
So now i run bare metal haos, just because it is easier to maintain (and uses less energy).
If i need something that i accidentally deleted or messed up, i will copy it manually from a backup (as restoring the backup will mess up all everything else i did)
Uptime is the continuous duration during which a system operates without an unexpected failure. It measures stability, not activity. In other words, uptime only resets when the system experiences an unplanned interruption—such as a crash, kernel panic, hardware fault, or any other uncontrolled halt in normal operation.
Planned operational pauses do not break uptime, including:
Scheduled reboots for OS or firmware updates
Controlled shutdowns for maintenance
Brief, intentional pauses to support backups, snapshots, or migrations
Because these events are deliberate and predictable, I do not consider them as failures and do not reset uptime.
My definition of uptime is consistent with major providers.
AWS, Azure, Google Cloud, Cloudflare, Fastly, etc. all define uptime as:
