"Local-first" gets thrown around a lot in the Home Assistant community, sometimes as a purity test. It's more useful to think of it as a practical engineering tradeoff: where should the logic that controls your home actually run? Understanding the tradeoff helps you make better buying and setup decisions, even if you don't go 100% local.
What "local-first" actually means
A local-first smart home processes device state and automation logic on a computer inside your own home — typically the machine running Home Assistant — rather than relying on a manufacturer's cloud servers to decide "the door opened, so turn on the light." The device data still might touch the internet for things like remote access or voice assistants, but the core automation loop doesn't depend on it.
Contrast this with a typical consumer smart-home setup: your smart plug talks to the manufacturer's cloud, your automation is defined in the manufacturer's app, and that app tells the cloud, which tells the plug what to do. Every step depends on a company's servers being up.
Reliability: the biggest practical difference
Cloud-dependent automations fail in a specific, annoying way: your internet blips for ninety seconds and suddenly your "turn on porch light at sunset" automation just... doesn't fire. Or your voice assistant can't tell your lights to turn off before bed. With local-first automations in Home Assistant, the automation engine runs on your network, so a WAN outage doesn't touch your lights, thermostat, or door locks — because nothing in that loop ever needed to leave your house.
Privacy: your data stays on your network
Every time a device is cloud-dependent, its usage data — when your door opens, when you're home, what time you go to sleep — travels to and is stored by a third-party company, subject to whatever their data retention and sharing policies say (and those policies can change after you've already bought the hardware). A local-first setup keeps that data on your own network by default. You choose what, if anything, leaves.
Speed
A round trip to a cloud server and back, even on a good connection, typically adds a noticeable delay before a light responds to a switch. Local processing on your own network is usually near-instant because the traffic never has to leave the building.
Where local-first isn't the whole answer
Being dogmatic about "zero cloud, ever" usually makes a smart home worse, not better. A few places where cloud connectivity is genuinely useful:
- Remote access. Checking your cameras or unlocking the door while you're away requires some form of connection out of your home — Home Assistant's own remote-access options, or a self-managed VPN, handle this without full cloud dependency.
- Voice assistants. Cloud-based speech recognition (Google Assistant, Alexa, or Home Assistant's own Assist voice pipeline using cloud speech-to-text) is still generally more accurate than fully local alternatives, though local voice options are improving quickly.
- Weather and location data. There's no local substitute for a weather forecast; this is inherently an external data source.
The practical goal isn't "no internet, ever" — it's making sure the automations that matter for daily life and security keep working without it, and that your day-to-day usage data isn't unnecessarily leaving your house.
How to bias your setup toward local-first
- Prefer Zigbee, Z-Wave, and Thread/Matter devices over Wi-Fi-only cloud devices where practical — see our protocol comparison for the tradeoffs.
- Check for local API support before buying. Many Wi-Fi devices (e.g. Shelly, some ESPHome-based devices) expose a local API that Home Assistant can use directly, bypassing the cloud entirely.
- Build automations in Home Assistant itself, not in a manufacturer's app, so the logic lives on your network.
- Keep backups current so your local setup, once built, is resilient — see our backup guide.
Local-first isn't about rejecting the cloud entirely — it's about making sure your home doesn't stop working when someone else's server does.