How to Self-Host a Smart Home with Home Assistant

Why this matters

Most smart home gear is rented, not owned. Your lights, locks, and cameras depend on a company’s cloud, and when the internet goes out — or the company changes its terms — your home stops working. Home Assistant is the self-hosted alternative that puts you in control.

What I tested on

• OS: Home Assistant OS (on a VM), plus a Docker container for testing
• Home Assistant: 2026.9.x (Core)
• Hardware: Raspberry Pi 5 (4 GB) as the main install, Intel N100 mini PC for heavier add-ons
• Devices: ~25 mixed Zigbee, Wi-Fi, and Matter devices
• Duration: daily driver for 14 months at the time of writing

⚠️ A smart home that controls locks or alarms needs a reliable host. Don’t run it on a server you reboot for fun.

How I tested

I moved one room at a time from a vendor cloud to Home Assistant, kept the vendor app as a fallback for a month, then cut over. This prevented the “nothing works on day one” disaster.

Step 1: Choose your install method

Method	Best for	Effort
Home Assistant OS	Beginners, Raspberry Pi	Low
Docker	Existing server users	Medium
Core in a venv	Maximum control	High

For most people, Home Assistant OS is the right answer — it includes the supervisor and add-on store.

Step 2: The Docker route (for existing homelabs)

services:
  homeassistant:
    image: homeassistant/home-assistant:stable
    container_name: homeassistant
    restart: unless-stopped
    volumes:
      - ./ha-config:/config
    environment:
      - TZ=Europe/London
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    ports:
      - "8123:8123"

/dev/ttyUSB0 is your Zigbee stick or other serial device. Pass it through so Home Assistant can talk to it.

Step 3: First login and integration

Open port 8123, create your account, and Home Assistant will scan your network for devices. Add integrations one at a time — the “Integrations” page is where everything starts.

Start with one brand you actually use. Trying to add everything at once is how people give up.

Step 4: Automations that actually help

The classic first automation is “turn on a light when motion is detected.” It’s a good test, but the real value comes later:

• Turn off all lights when nobody is home
• Notify your phone when a door opens and you’re away
• Dim lights at bedtime

Keep them simple at first. A complex automation that breaks silently is worse than none.

Step 5: Backups

With Home Assistant OS, use the built-in backup feature and copy the backup off the device. With Docker, back up the /config volume the same way you back up everything else.

Test a restore. This is the step everyone skips until they need it.

Zigbee, Wi-Fi or Thread: what to buy first

The protocol decides how much of your house keeps working when the vendor shuts down, so buy for that rather than for the box art.

Zigbee needs a coordinator (a USB stick, around $25) and builds a mesh where every mains-powered device repeats for the ones further away. It is local by design, cheap, and the devices do not phone home. Downside: pairing is fussy, and a weak mesh shows up as “sometimes it does not respond”.

Wi-Fi needs no coordinator but does need good access points. Twenty Wi-Fi bulbs on a consumer router is how people end up with a network that drops video calls. If you go this route, put IoT devices on a separate SSID and VLAN — a step that also matters for the reverse proxy and firewall setup I describe in the Caddy guide.

Thread is the newer mesh, and it needs a border router (a newer Apple TV, HomePod, or a dedicated dongle). It is the right long-term bet for battery devices, and the wrong first purchase if half your existing gear is Zigbee.

My rule after 25 devices: Zigbee for sensors and switches, Wi-Fi for anything that streams, Thread only when a device I want has no other option. Mixing three protocols on day one is how a weekend project becomes a month.

What broke in 14 months

Three things, in order of how much they cost me.

An integration broke on a Home Assistant update and took a light group with it. The fix was a rollback of the add-on, then waiting a week for the patch. This is why the backup routine matters more than any automation: a snapshot from yesterday is a five-minute recovery, not an evening of rebuilding.

A Zigbee stick moved to a different USB path after a host reboot, so Home Assistant started without a coordinator and half the house went dumb. Passing the device by vendor and product ID instead of /dev/ttyUSB0 fixed it permanently.

One automation looped. A motion sensor triggered a light, the light triggered a scene, the scene re-triggered the motion sensor’s condition. The house blinked for a minute before I killed the automation. Now every new automation gets a single-action test before it gets conditions.

Pros and cons

Pros:

• Vendor-neutral: one app for devices from many brands
• Runs locally — your home works when the internet doesn’t
• Huge integration library (thousands of devices supported)
• Active community and frequent releases

Cons:

• Learning curve is real; YAML editing is sometimes required
• Updates can break integrations (less often now, but still)
• You become your own support for everything in your home

Best for / Skip if

Best for: anyone with devices from more than one brand, or who wants their home to work offline.

Skip if: you only have one or two devices and the vendor app does everything you need.

Alternatives

• OpenHAB — older, Java-based, very powerful but steeper
• Node-RED — flow-based automation; often used alongside Home Assistant
• Vendor hubs — easier but vendor-locked

Verdict

Home Assistant is the one self-hosted service that directly improves daily life, because it makes your home more reliable and less dependent on the cloud. Start with one room and one brand — that’s enough to learn the system without drowning in it.

References

• Home Assistant installation — supported install methods
• Home Assistant automations — triggers, conditions, and actions