Why your smart home should run locally, not in someone's cloud

A light switch should not have a service dependency. Yet most connected devices route a command that travels three metres through a data centre possibly on another continent — which is why an outage at a company you have never thought about can leave you standing in the dark.

The path a cloud command actually takes

Press a button in a typical smart-home app and the request leaves your phone, crosses your internet connection, reaches the vendor's servers, is authenticated and authorised, then travels back to a hub or directly to the device on your network. The bulb three metres away receives an instruction that has covered thousands of kilometres.

Every one of those hops is a potential failure: your connection, their servers, their authentication service, the DNS resolution in between. A local system removes all of them. The command goes from your phone to a hub on your own network to the device, and nothing outside your house is involved.

What breaks, and how often

Cloud-dependent homes fail in ways that are memorable. An internet outage disables lighting and heating controls that have no physical dependency on the internet. A vendor's authentication outage locks everyone out at once. A rate limit during peak load makes responses take ten seconds.

The more serious category is deliberate. Vendors have discontinued cloud services and turned working hardware into inert plastic. Others have moved previously free functionality behind a subscription, or reduced what the free tier does. When the intelligence lives on someone else's server, the terms of use of your own hardware are subject to revision without your agreement.

What local-first actually means

The distinction is where the decisions are made, not whether internet access exists at all. In a local-first setup, a hub in your home holds the automations and talks to devices over local protocols. Remote access and voice assistants may still involve the internet, but they are conveniences layered on top. Pull the internet out and the house still works.

The test is simple and worth running on any system you already own: unplug the router and see what still responds. Whatever fails was never really yours to control.

The protocols that make it possible

1. Zigbee and Z-Wave. Low-power mesh networks designed for exactly this. Devices relay for each other, so coverage improves as you add mains-powered devices, and neither protocol requires internet access to function.
2. Thread and Matter. Thread is a modern low-power mesh; Matter is the application layer above it, designed for cross-vendor interoperability and explicitly supporting local control. Matter is the first serious industry attempt at making local operation the default rather than an enthusiast configuration.
3. Local Wi-Fi APIs. Some Wi-Fi devices accept commands directly on the local network. This works well but varies by vendor, and firmware updates have been known to remove local endpoints.
4. Wired protocols. For anything you truly cannot have fail — heating, primary lighting — wired systems remain the most reliable option, at meaningfully higher installation cost.

The privacy dimension

Home automation data is unusually revealing. Motion sensors, door contacts and lighting patterns together describe when your house is empty, when you sleep, how many people live there and when your routine changes. Cloud systems necessarily transmit this, and retention policies are typically vague about how long the record persists.

Cameras and microphones raise the stakes further. A local system with local recording keeps footage on a drive in your house. A cloud camera uploads continuously to storage governed by someone else's policy, breach exposure and legal process.

What local-first costs you

Being honest about the trade-offs matters, because the enthusiast case for local control routinely undersells them.

Setup is more work. Cloud devices are designed for a five-minute onboarding; a local hub involves choosing software, pairing devices and writing automations. You also become the support desk — when something misbehaves there is no company to call, and the troubleshooting is yours.

Maintenance is real. The hub needs updates, backups and occasional attention. And some genuinely useful cloud features are hard to replicate locally: voice assistants with broad natural-language understanding, and machine-learning features like person-versus-animal detection, though local versions of the latter now run acceptably on modest hardware.

A pragmatic middle path

The all-or-nothing framing is unhelpful. A more sensible rule: anything whose failure is annoying can be cloud-dependent, and anything whose failure matters should be local.

In practice this means lighting, heating, door locks and security sensors run locally, on a hub, with physical controls that work regardless. Novelty and convenience devices — a speaker, a display, a robot vacuum — can stay cloud-connected, because a broken vacuum is an inconvenience rather than a problem.

Alongside that, keep the physical layer intact. Smart bulbs behind a smart switch mean two systems must work for a light to turn on. Smart switches that still function as switches mean the worst case is a house that behaves like a normal house.

How to start without replacing everything

Install a local hub and add new devices to it rather than to vendor apps. Choose Matter-certified or Zigbee devices for anything new. When an existing cloud device fails, replace it with a locally controllable equivalent rather than the same thing again.

Before buying anything, check the specification for local control support and read the app store reviews for outage complaints — they are the most honest available documentation of how a device behaves when the vendor's servers have a bad day.

The hub is the single point of failure — plan for it

Moving the intelligence into your house concentrates the risk there. If the hub's storage fails, the automations, device pairings and history go with it, and re-pairing several dozen devices is a genuinely miserable weekend.

Two habits prevent this. Take automated configuration backups to somewhere off the hub — a network drive or a cloud storage account holding only the config, which is small. And run the hub from reliable storage: cheap memory cards are the most common cause of hub failure, and a small solid-state drive removes the problem for a modest cost. Adding a small uninterruptible power supply is worthwhile too, since sudden power loss during a write is what usually corrupts the storage in the first place.

Device capabilities and local-control support vary by manufacturer and firmware version. Check current documentation before purchase, as support can change between revisions.