Guide · Smart Home
Smart Home Without the Cloud
Direct answer
How to design a home automation system that runs locally and keeps working when the internet drops. Why local-first matters and what it actually means in practice.
A “smart home” that depends on the internet to work isn’t smart. It’s a remote control with a single point of failure on the other side of the planet. Local-first design means the system works regardless of what’s happening with your internet, the vendor’s cloud, or their business. It’s the only architecture that makes sense for a system you depend on for ten years or more.
What “cloud-dependent” actually means
Most consumer smart home brands are cloud-dependent by default. When you press a switch on your phone, the command goes:
- Phone → Internet → Vendor’s cloud server (often in the US)
- Vendor’s cloud server → Internet → Your house
- Your house → The light comes on
Even though both endpoints are in your house, the round-trip goes through a server thousands of kilometres away. If the internet drops, the vendor’s cloud goes down, or the company shuts the API off, none of it works. Examples of devices that fail this test by default:
- Most Wi-Fi smart plugs (TP-Link Kasa, Wyze, etc.)
- Most cloud-tied lighting brands (LIFX, Nanoleaf)
- Most cloud cameras (Ring, Arlo, Nest)
- Many “Works with Alexa” devices that don’t have a local mode
- Almost any device that requires a vendor account to use
What “local-first” means
A local-first system runs the automation logic on hardware in your house. The path looks like:
- Phone → Local Wi-Fi → Local controller in your house
- Local controller → Light comes on
The internet is involved only when you’re outside the house and want remote access. Even then, the path goes through a VPN to your local controller, not through a third-party cloud.
The implications:
- Internet drops: The system keeps running. Lights, climate, security, automations: all functional.
- Vendor’s cloud goes offline: Doesn’t matter. You don’t depend on it.
- Vendor goes out of business: Doesn’t matter. The system in your house keeps working.
- Vendor changes the API or pricing: Doesn’t matter. Your local installation is unaffected.
- You move house: Take the controller and devices with you. Reconfigure on the new network.
What you need for local-first
Three components:
1. A local controller
This is the brain. It runs in your house, ideally in a comms cabinet or a quiet corner. Power consumption is around 5W, less than a phone charger.
Common choices:
- Home Assistant Yellow, purpose-built hardware, $400–600
- Home Assistant Green, entry level, $200–300
- Intel NUC or similar mini PC running Home Assistant OS, $400–800
- Raspberry Pi 4 or 5, cheapest option, $150–300, slightly less reliable for heavy use
The controller stores your configuration, your historical data, your automations, and the local copies of any cloud-replacement services. Backups go to a separate location (NAS, off-site cloud storage, or another property) so you can recover if hardware fails.
2. Devices that work locally
Not every smart device supports local control. Picking the right ones matters. The categories that work locally:
- Matter and Thread devices: designed to work locally by default. Matter is the standard backed by Apple, Google, Amazon, and Samsung.
- Zigbee devices: most Zigbee devices work locally. You need a Zigbee coordinator (separate USB stick or built into Home Assistant Yellow).
- Z-Wave devices: same as Zigbee, also local
- ESPHome devices: open firmware that runs entirely locally. Common on relays, sensors, and DIY hardware.
- Shelly devices: local API support. Popular for behind-the-switch relays.
- Some Wi-Fi devices with local mode: including most TP-Link Tapo, some Sonoff, and others. Check before buying.
What to avoid for local-first installs:
- Anything that requires you to create a vendor account before using it
- Anything that lists “internet connection required” in its setup
- Devices where local control is “in beta” or “experimental”
- Devices that work locally but require cloud for firmware updates (subtler. You may be locked out from updates if the vendor disappears.)
3. Local network with redundancy
If the local controller is on Wi-Fi and the Wi-Fi is shaky, the system feels slow and unreliable even though it’s local. The right answer is:
- Wired Ethernet to the controller. Never Wi-Fi for the brain.
- Enterprise-grade Wi-Fi (Peplink, Ubiquiti, Aruba) for the device endpoints
- Multi-WAN router with automatic failover so internet drops don’t break remote access
- Segmented VLANs: IoT devices on a separate network from your work and personal devices
Iron and Air’s standard install uses Peplink for the router, with NBN as primary internet and 5G as automatic failover. For waterfront properties where NBN reliability is poor, the failover becomes the primary, with Starlink as a third path.
What still needs the internet
Local-first doesn’t mean isolated. Some things genuinely require external services and should:
- Weather forecasts (used for automation triggers, like closing blinds before a storm)
- Time synchronisation (NTP)
- Software updates
- Remote access (when you’re outside the house)
- Notifications to your phone when you’re out
The principle is: any function that has to work for the house to be liveable must work without the internet. Anything else can use the internet, but should degrade gracefully when it’s unavailable.
What this looks like in practice
A typical local-first house at Iron and Air:
- 40+ smart devices: lighting, climate, blinds, security, energy, water
- Home Assistant controller on dedicated mini PC, wired to network
- Devices spread across Matter, Thread, Zigbee, and a few local Wi-Fi
- Peplink router with NBN + 5G failover
- VPN (WireGuard) for remote access
- Daily configuration backups to off-site storage
- Power consumption of the brain plus network: under 30W continuous
When the NBN drops at 6pm during storm season:
- Lights still work, controllable from phones on the local network
- Climate keeps running its schedule
- Security keeps recording (locally to NVR)
- Smart blinds still operate on schedule
- Voice control via Alexa or Google fails (cloud-dependent), but local voice via Home Assistant Voice keeps working
- The 5G failover takes over remote access within seconds; from outside the house you don’t notice the switch
Common questions
Can I keep my Alexa or Google Home and still go local-first? Yes. Home Assistant integrates with both. You can keep the voice assistants for natural language convenience and have them control your local devices. When their cloud goes down, voice fails but everything still works manually and via the local app.
My existing setup is all cloud. Can it be migrated? Mostly, yes. About 80% of common cloud-tied devices have local replacements that perform the same function. Migration is typically done device-by-device over weeks rather than a single switchover. A System Audit identifies which of your existing devices support local control and which need replacement.
Is local-first more expensive? Initial hardware cost is similar or slightly higher (the local controller is $200–600 you wouldn’t otherwise buy). Ongoing cost is significantly lower (no monthly subscriptions, no annual dealer fees). Over 5 years, local-first is meaningfully cheaper. Over 10 years, the difference is substantial.
Will it still work in 2035? Yes. The protocols (Matter, Thread, Zigbee, Z-Wave) are open standards. The platform (Home Assistant) is governed by a non-profit foundation. The hardware is replaceable with current-generation equivalents whenever needed. There is no vendor with the power to make your system obsolete.