If you are new to HA, read this first; it might assist you with choices as you start your journey

I have created this TLDR with the hope it can assist newcomers, and not only, with decision making. This post uses a lot of acronyms and it is best viewed on my portal as I provide full real-time glossary. In any case, I hope it is useful to someone.


There are several methods to install [[HA]], listed and compared here. I consider the [[HAOS]] method the most production worthy, for the simple reason it provides long-term reliability. A lot of people will try to convince you otherwise, but take it from someone who looks after more than 100 [[HAOS]] instances running for years with no issues. [[HA]] has a large technology ecosystem with a lot of moving pieces, which also happen to change frequently (the nature of the tech industry); the last thing you want is add unnecessary dependencies and complexity into a system that is already complex and updated at a fast pace.

As someone who has designed, engineered and programmed systems for AMX, Dynalite, ELAN, Control4, Crestron, HomeSeer, Loxone, Lutron, OpenHAB, RTI, Tuya, URC, and others, plus worked with almost any protocol in existence, like BACnet, CAN-bus, KNX, [[LoRa]], [[MQTT]], [[RF]], RS-485 Zigbee, Z-Wave, you name it I have most likely deployed it, I can confidently say, [[HA]] is the best overall [[domotics]] platform there is. In the hands of a competent technology designer/engineer, it will shine orders of magnitude brighter than any other galaxy in the [[domotics]] universe. Even for simple setups it is hands down the most flexible and in many ways the most enduring [[domotics]] platform out there.

With all this power and complexity the least you want to do is add even more dependencies and complexity, which is why I suggest the [[HAOS]] installation method is the most appropriate for anyone seeking long-term reliability from their [[domotics]] system. If you are just tinkering and your smart home does not depend on [[HA]] to function, any of the other methods of installation (container, core, supervised) are fine. For anyone looking for long-term, rock-solid deployments [[HAOS]] is the only reasonable choice.

[[HAOS]] Options

You can install [[HAOS]] in two ways:

  • Bare-metal on a variety of compute platforms (64-bit is the preferred choice)
    • [[arm-64]] (e.g. HA Blue, HA Yellow, RPi, Odroid, Khadas)
    • [[x86-64]] (e.g. NUC and hundreds of other options) you will find a greater variety of hardware and configuration options and face less issues on this platform
  • Virtualised in a [[VM]]
    • Type-1 [[Hypervisor]]: this requires a [[BM]] installation on a dedicated computer - I strongly suggest [[PVE]], but other [[hypervisor]] options are also available
    • Type-2 [[Hypervisor]]: it does not require a dedicated system and can be installed on most Linux/Mac/Windows PCs - examples are [[Hyper-V]], [[PVE]], [[VirtualBox]], [[VMware]]
    • [[NAS]]: install [[HA]] as a [[VM]] in a [[NAS]] system, like [[QNAP]], [[Synology]], [[TrueNAS]], etc.

[[VM]] [[HAOS]] Benefits

[[PVE]] virtualisation has many benefits, some of the most important are:

  1. Ability to run production-grade, test and beta [[HA]] workloads side-by-side (tinker to your heart’s content on test instances/workloads, while running a robust production-grade [[HAOS]] instance in parallel)
  2. Ability to automate backup of the entire [[HAOS]] instance (the entire [[VM]]) in seconds with almost no downtime (includes all backups inside [[HAOS]])
  3. Ability to backup on-demand the entire [[HAOS]] instance prior to a version which might break things in seconds (includes all backups inside [[HAOS]])
  4. Restore a backup in seconds (includes all backups inside [[HAOS]])
  5. Create a robust infrastructure (compute, network, storage); e.g. running a [[PVEc]]
  6. Consolidate all server (even desktop) workloads on a single physical computer; you just need a lightweight client PC running a web-browser to access the [[PVE]] infrastructure

[[PVE]] has one consideration you should be aware of

  • When [[HA]] is updated it needs to be restarted leading to downtime. In the same manner, when the [[PVE]]-kernel is updated, it requires full system restart for the new kernel to activate, which means all workloads will have to be rebooted including [[HA]]. In [[PVE]], a kernel update is available almost bimonthly. To reduce downtime you could update [[PVE]] as well as all workloads including [[HA]], all at the same time; then one reboot will update everything [[PVE]], [[HA]] and all other workloads

[[HAOS]] Recommendations

Some people suggest, install [[HA]] and then never update or update infrequently (say once a year). Although it is possible to freeze the installation if you will never have the need to change something, I believe it defeats one of the primary motivations of using [[HA]], which is to keep pace with technology advances. If you rarely update your system, chances are something will break next time you try to update. This is why Apple, Google, Microsoft and everyone else in the industry insist your system is updated at frequent intervals and also the reason why immutable [[OS]] deployments have started gaining traction.

I therefore suggest you update [[HA]] at least every 3 months (say 3rd week of the 1st month of every calendar quarter) and preferably once a month towards the end of the 2nd week. You might not want to update at the beginning of every month (say avoid the first 1 or 2 weeks of every month) as sometimes there might be issues introduced by updates, which although usually solved fast (within the 1st week) could lead to problems with your system, which although addressable, you might not have the time or the knowledge to solve.

Below find my suggestions in a nutshell (they apply to most people who are not experts):

  1. Install [[HAOS]] preferably in a [[KVM]] in [[PVE]] or alternatively [[BM]] install in a [[x86-64]] PC
  2. Preferably use [[NVMe]] [[SSD]] or alternatively [[AHCI]]/[[SATA]] [[SSD]] or [[eMMC]] for storage; DO NOT use [[SD]] cards as they have terrible performance and are not as reliable as any other option
  3. Rough sizing guidelines for most [[HAOS]] installations: note: how many CPUs are required depends on how performant the CPU cores are; if running in a VM start with 1 CPU and monitor):
    1. baremin: 1 [[CPU]] :white_medium_small_square: 512MB [[RAM]] :white_medium_small_square: 32GB [[SSD]]
    2. minimum: 1 [[CPU]] :white_medium_small_square: 2GB [[RAM]] :white_medium_small_square: 32GB [[SSD]] :small_blue_diamond: 2 [[CPU]]
    3. optimum: 2 [[CPU]] :white_medium_small_square: 4GB [[RAM]] :white_medium_small_square: 64GB [[SSD]] :small_blue_diamond: 4 [[CPU]]
    4. maximum: 4 [[CPU]] :white_medium_small_square: 8GB [[RAM]] :white_medium_small_square: 256GB [[SSD]]
  4. [[HA]] requires a wired [[LAN]] connection to create a reliable network link
  5. [[HA]] does not require Internet access to communicate with the local [[domotics]] infrastructure; however, it requires Internet access when you try to update [[HA]]; at no time your local [[domotics]] infrastructure is exposed to the Internet, unless you use [[domotics]] hardware which has been designed for cloud operations, like for example [[Google]] and [[Tuya]]. However, even for these cloud services there is usually a local-only installation method
  6. You can securely access [[HA]] over the Internet, using the Nabu Casa subscription service and/or Cloudflare. These two methods are vastly superior to any other remote access method. The next two methods, Tailscale and ZeroTier, are also very good, but Cloudflare edges them out
  7. Automate [[HAOS]] backups (use [[PVE]] as it offers the most robust and fastest backup method)
  8. Set a static [[IPv4]] in [[HA]], using a [[DHCP]] [[MAC]] reservation, instead of setting a static [[IPv4]]; it is easier to setup and more flexible when changes are called upon
  9. Do not enable [[HTTPS]] in [[HA]]; it just complicates matters without real benefits in residential-[[LAN]]s (a better strategy is to ringfence and secure your [[LAN]])
  10. Take a full [[HA]] backup prior to updating; ensure the backup is saved outside the [[HA]] instance
  11. Randomly test backups can be restored; a backup is no good if we cannot restore from it
  12. Habitually update [[HA]] on the 3rd week of the 1st month of every calendar quarter (i.e. every 3 months) or something similar or more frequently; aim for a max update interval of no more than 4 months; ideally you want to update monthly, anytime the last 2 weeks of every month
  13. Only install well-maintained [[HAAC]] and/or [[HACS]] packages
  14. Primarily choose [[domotics]] hardware which natively supports [[IP]] protocol stacks (e.g. [[matter]]/[[thread]], [[WiFi]])
  15. With [[matter]]/[[thread]], protocols such as Zigbee, Z-Wave and possibly [[BLE]] will become obsolete, in the not too distant future; [[IMHO]]
  16. Advanced: consider [[LoRa]] hardware in favour of other wireless standards, except possibly [[matter]] and [[WiFi]]. [[LoRa]] has exceptional range (rated in km) with extremely low power consumption, designed for large industrial-scale [[IoT]] deployments, but also fantastic for residential/commercial use
  17. Advanced: consider learning [[MQTT]], which is the glue to connect dissimilar protocols together; although [[HA]] supports a plethora of protocols there are things that only [[MQTT]] can muster
  18. Advanced: consider learning [[Node-RED]], a flow-based [[domotics]]/[[IoT]] development platform
  19. Lastly apply for a subscription to Nabu Casa to keep this wonderful project alive and kicking butt, even if you decide to use Cloudflare, Netmaker, Tailscale, ZeroTier or anything else for [[HA]] [[WAN]] access

In case you are wondering what performance looks like on baremin ([[PVE]] [[KVM]] on i7-3517U CPU @ 1.90GHz, 12 integrations, no [[HAAO]], [[HAAC]], [[HACS]]):


Nice writeup.

I would add: test your recovery process to make sure it works - a backup is useless unless you can prove it can be used to recover your system.

1 Like

Some migration code is only kept for 2 months. I would be careful about recommending only updating every 3 months


Update every release.


Agreed. When I don’t know what a piece of software with some kind of DB might do with every upgrade, I will often run the larger updates in between (meaning, at the time of the upgrade, if I’ve skipped a month). In this case, we usually know when there are DB changes (thanks to you), but even so (because we know many people don’t read the changelogs) I’d still install each monthly update before the final upgrade.

I agree with everyone updating monthly is the best choice. However, we need to be realistic that non technical people do not want to spend time for maintenance. We therefore need to offer some sort of compromise if we want people to update at “reasonable” intervals.

I just wanted to emphasise that not updating or updating once a year is a very bad habit.

I also agree testing a restore is good practice. However, most people do not have the infrastructure or the confidence to do it. Reality is, backups taken outside HA are very reliable and the ones I highly recommend are using hypervisor-based backups, which by nature are reliable, especially if done on zfs-based systems.

Thank you for your feedback. Based on everyone’s feedback I have updated the guide.