I moved Home Assistant onto a machine of its own this month — a small cloud VM, nothing sitting at home. Before I did, I wanted a straight answer to something the documentation does not give you: what does it actually need?
What I settled on is a Hetzner cx23. Two vCPU, 4 GB of memory, 40 GB of disk, in Nuremberg, on Ubuntu 24.04. That comes to 7.09 euro a month before tax. Home Assistant 2026.8.2 runs in a container on Docker 29.7.2, with network_mode: host.
What the machine serves: a dashboard built from stock cards, running on demo sensors.
What it actually uses
With the container stopped, the machine sits at 611 MB. That is Ubuntu plus the Docker daemon and nothing else. Two minutes after starting Home Assistant it reads 960 MB, and the container accounts for 339 MB of that.
The figure moves, which is why the timing belongs next to it. Immediately after start it reads 850 MB. After 22 hours of uptime I measured between 969 and 985 MB. Anyone quoting a memory number for Home Assistant should say when they took it; I got all three of these on the same machine.
From docker compose up to an HTTP 200 on port 8123 took 6.6 seconds, measured in half-second steps. The interface answers before the integrations have finished initialising, so the 6.6 seconds measure the web server coming up. The integrations take longer.
The image is 625 MB. After the base setup the disk sat at 5.4 GB of 38 available, and at 9.4 GB once I added a 4 GB swap file. The jump is the swap file.
Two vCPU and 4 GB is more than a container install with no add-ons needs today. I would not go lower, because the recorder database grows steadily and swap on a 4 GB machine is what keeps an upgrade from being killed for memory.
Why this is not running on the Kubernetes cluster
I already run a single-node k3s for other things, so the obvious question was whether Home Assistant belonged there. I measured that machine first: 11.7 percent CPU as a baseline across seven days, before any workload of mine runs at all, and 1 to 1.5 GB of memory for the control plane sitting idle.
What decided it was networking. Home Assistant needs mDNS and broadcast traffic to find devices on the network. In Docker that is network_mode: host, one line. The Kubernetes equivalent is hostNetwork: true, and that gives up the network isolation which was the reason to run Kubernetes in the first place.
One correction while I am here, because it comes up often: there is no Docker in K3s. K3s runs containerd, and the Docker backend has been deprecated for a while. The image is the same OCI image; only the runtime underneath differs.
What a standard setup leaves open
I went over the machine the day after cloud-init built it, and found four things that were worth fixing. None of them shows up as an error.
ufw was installed and never enabled. The package was in the cloud-init list, and without an explicit enable the result is a firewall reporting inactive. It does not matter while the provider firewall in front of it filters everything, and it starts mattering the moment ports 80 and 443 open for TLS.
sshd had password authentication on, which is the Ubuntu default. Root itself is key-only, so nothing was exposed yet — but any additional user created later could have logged in with a password.
There was no swap on a 4 GB machine, and the SSH allow-list held exactly one address: a home connection whose IP rotates. I have locked myself out that way on another project, so a fixed second address went in as an anchor.
All four are fixed on the running machine and written back into the cloud-init file, so rebuilding does not quietly undo them.
What a machine in a data centre cannot do
This is the part most posts about hosting Home Assistant leave out, and it is the first thing you should check before copying my setup. Your devices are on your home network. A VM in Nuremberg is not, and mDNS discovery stops at your router. Anything that speaks only on the local network — Zigbee sticks, KNX, most cheap WiFi plugs — is unreachable from there.
For this build that is on purpose. It binds no device at all in its first phase; it exists to be set up cleanly and photographed. The house is still run by the old instance, which sits where it can see the hardware.
If you want a cloud machine and local devices, you need a tunnel back home, and then the tunnel becomes the part most likely to fail, rather than the server. A machine at home avoids that entirely. What it costs you instead is the uptime, the backups and the upgrade discipline that the provider otherwise handles.
What I would keep
The container install, because nothing about it has needed attention. No Supervisor, no add-ons, one compose file, and an upgrade is a changed image tag. What I gave up is the add-on ecosystem, and for a machine that does nothing but run Home Assistant I have not missed it yet. Worth separating two things that get confused here: add-ons are a Supervisor feature and a container install has none, while HACS works fine in a container and gives you integrations, cards and themes.
If you want the install itself rather than the machine choice, I wrote that up separately for Docker on a Linux VM. And once it runs, the first thing worth doing is a backup that covers the whole host, not just the config folder.
Top comments (0)