I wrote a series of articles describing in detail how I define all my electronic devices and automate them entirely with Nix.
Defining your house in Nix is awesome and fun - before you know it, you’ll have forgotten about that other service that used to automate your home non-declaratively.
I would say it’s pretty beginner friendly - Have fun & enjoy!
This is pretty cool, very interesting ideas. From reading your tutorial however I get the impression that automation must be handled by the coordinator in your setup, do you support ZigBee bindings to avoid that dependency?
Thanks!
I wonder if it’s possible to use HA in a more declarative manner rather than bypassing it altogether?
there are other ways to run your home than with a big locked pool of Python dependencies
Are you aware of the NixOS module for Home Assistant that actually does not use upstream’s mechanism of pulling in random packages from PyPI? Instead, it uses the usual python3Packages from Nixpkgs (except for a few overrides)
Using that has the advantage of integrating with many more devices than those using Zigbee.
It 100% is. Home Assistant automations can e.g. be specified in the list services.home-assistant.config.automation. You can easily translate the YAML code for existing automations into Nix.
I personally set
services.home-assistant.config."automation ui" = "!include automations.yaml";
so that people in the household who want to automate stuff without touching Nix code can do so in the UI. The two can coexist.
Note that setting up most integrations nowadays requires clicking buttons in the UI though.
Doesn’t this conflict with your claim that we can make HA declarative?
You asked about making it more declarative 
I don’t like that they got rid of cofiguration via YAML but it’s not that big of a deal IMO since touching the Home Assistant UI is only required when setting up a new integration, so not even for adding Zigbee devices.
Yes I am aware. Can you give some examples of those other (non-Zigbee) devices?
Maybe I am not quite awake yet, but I think I don’t understand why I would need Home Assistant to control them?
For example - if I want to control my TV I use ADB, why on earth would I go HA > ADB? Seems redudant to me.
You might want to activate a specific lighting scene when the TV is turned on.
A great use for home automation is running energy-hungry devices only when solar power is available, which requires Home Assistant to connect to your inverter.
Or what if you already own e.g. Z-Wave devices but want to add Zigbee devices?
And don’t forget about the option to build DIY devices using ESPs.
I’m trying to decide between going the QuackHack route or running HAOS on a VM. Recently, there was an issue with an update in HAOS that corrupted my backups and kept HAOS from starting, and even on a clean install - all of my backups seem to keep Core from starting. So, after losing 5 yrs of work on HAOS, I’m looking for something more robust. This led me to the QuackHack route or running HAOS in a VM.
I asked Claude what it thought and here’s the response, but I’m curious if anyone would be willing to share their experience with either of these two options. Is the VM laggy? Any issues accessing USB devices like my Coral TPU? If you went the QuackHack route, are there any features that you miss? Anything else noteworthy? Any other options worth considering?
This is a great question. Both approaches have real merit, and the right choice depends on your priorities and comfort level.
HAOS as a VM (e.g., Proxmox)
Pros:
VM-level snapshots are rock solid — snapshot before every update, instant rollback if things break
Keep the full add-on ecosystem (Zigbee2MQTT, Node-RED, ESPHome, etc.)
Hypervisor handles backups at the block level — bypasses HA’s flaky backup system entirely
Easy to clone, migrate, or restore the whole system
Lower learning curve
Cons:
Still a “black box” OS you don’t fully control
Another layer to manage (the hypervisor)
NixOS with a custom Home module
Pros:
Declarative and reproducible — your entire system is defined in code
Version control your config in git — “backup” becomes just
git pushAtomic rollbacks built into the OS (
nixos-rebuild switch --rollback)You understand and control everything
No weird container-in-container issues
Cons:
Steep learning curve — Nix is notoriously tricky to learn
No Supervisor — you lose the add-on ecosystem entirely
You manage everything yourself (MQTT, Zigbee2MQTT, databases, etc. as separate NixOS services)
Less community support for troubleshooting
That linked module is someone’s personal config — you’d own maintaining it
My take:
Priority Best choice Robustness with minimal effort HAOS on Proxmox with VM snapshots Full control + reproducibility NixOS (if you’re willing to learn Nix) Keep add-ons + easy setup HAOS on Proxmox
If your main complaint is HA’s backup system, running HAOS as a VM solves that problem with much less friction — just use Proxmox snapshots/backups instead of HA’s. You get robustness without giving up the convenience of add-ons.
The NixOS route is powerful but it’s a lifestyle choice — worth it if you’re already into declarative infrastructure or want to go down that rabbit hole.
I’ve been running HomeAsssistant from nixpkgs on my own custom built Linux distribution in a variety of container-like environment for years now. Never had any issues. I run HomeAssistant itself, PostreSQL, z2mqtt and mosquito. I think that the recommendations of “run it in a VM, running it normally is complicated” come from a very different level of Linux expertise than what’s the average in Nix land. No offense to the people running it in a VM, everyone excels at something else. But if you’re already running NixOS and are comfortable enabling a few NixOS options and doing some minor debugging if something goes wrong, you’ll be fine with running HomeAssistant on NixOS imo