Setting up a local-only smart home with no cloud

The internet goes down for an hour and the lights stop answering. A company is bought and its servers are switched off, and a shelf of devices becomes plastic. Those two failures share one cause: the control path leaves the house. A local-only smart home keeps that path inside the walls, and it is easier to build today than it has ever been.

What local-only means

Local-only means every part of the loop from your finger to the device runs on your own network. The app or switch talks to a controller in the house, the controller talks to the device over a local radio or the local network, and nothing in that chain needs a connection to a server elsewhere. The internet can be down. The vendor can be gone. The house still works.

It does not mean no internet ever. You can still choose to reach the house from outside, to pull weather data, or to update firmware. The difference is that those are additions, and the home works without them.

There is a spectrum. A fully local home uses only devices that need no cloud account and a controller that runs on hardware you own. A mostly local home adds a few cloud devices for jobs where it does not matter if they fail, and keeps them away from anything important. Both are big improvements on the default, where every device has its own cloud and the house is a collection of subscriptions.

Choose a local controller

The controller is the box that runs your automations and talks to every radio. It replaces the vendor apps as the brain of the house. Several open-source and commercial controllers are designed for local operation and run on a small single-board computer, a mini PC or a purpose-built hub that you buy once.

What to look for:

• Runs on hardware you own, in the house, with no requirement to sign in to a service to use it.
• Speaks the radios you want either directly through USB coordinators or through add-ons. Zigbee and Thread support are the priority; Z-Wave if you own or want Z-Wave devices. The radio comparison explains the trade-offs.
• Supports Matter as a controller, so that new devices commission straight into it.
• Has a large device database, because the difference between a device “working” and working well is usually a definition somebody has already written.
• Backs up and restores easily. Your automations and device pairings are the most valuable thing in the house; keep a copy.

Put the controller somewhere central, on wired Ethernet if possible, with the Zigbee or Thread coordinator on a short USB extension cable away from the computer and the router. The coordinator’s position sets the shape of your mesh.

Pick devices that work without a cloud account

The rule is simple: if a device cannot be controlled without creating an account on the manufacturer’s service, it is a cloud device, whatever the box says about “smart”.

Zigbee, Z-Wave and Thread devices are almost always local by nature, because their radios cannot reach the internet at all. Once paired to your coordinator, they answer to your controller and nobody else. This is the main reason a local-only home is built mostly on mesh devices.

Matter devices are local by design too, as the article on how Matter works explains. Commissioning happens between your controller and the device, control runs over your network, and the manufacturer’s app is optional. For a Wi-Fi device, “Works with Matter” is currently the clearest signal that it can be run locally.

Wi-Fi devices without Matter need checking one by one. Some expose a documented local API that your controller can use. Some can be re-flashed with open firmware that turns a cloud device into a local one, which is popular for cheap plugs and bulbs but voids any warranty and takes an afternoon. Others are cloud-only with no way around it. Community device lists for the major controllers record which is which, and a search for the model number plus “local” usually settles it.

For each purchase, ask three questions. Can I set it up without an account? Can my controller talk to it directly? Will it still work if I block it from the internet? Two yes answers make it a good local device; three make it a great one.

Keep cloud-dependent devices off the internet

You will end up with some cloud devices. The television, the robot vacuum and the doorbell you already own are the usual suspects. The aim is to stop them from being a way in, and to stop them from being a single point of failure for anything important.

Put them on a separate VLAN or, if your router lacks VLANs, on a guest network that genuinely isolates clients from each other and from the main network. That keeps them away from your laptops and from the controller, and the device security checklist covers what else to change on each of them.

Then decide, device by device, whether it needs the internet. Many cloud devices keep working for local jobs when their outbound traffic is blocked at the firewall: the vacuum still cleans on its button, the television still plays from local sources. Block first, then unblock only the ones that stop doing something you care about. The devices that must reach the cloud to function are the ones to plan to replace.

Do not run anything important through a cloud device. A cloud light switch is a nuisance when it fails. A cloud lock or a cloud heating control is a problem.

Remote access without a vendor cloud

The one thing the vendor cloud gave you was control from outside the house. You can have that without them, in two common ways.

A VPN into your home network is the strongest option. Your router, or the controller itself, runs a VPN server; your phone connects to it when you leave the house, and from then on it is on the home network as if you had never left. Every local device is reachable and nothing is exposed to the internet except the VPN port. Modern VPN protocols are light enough that phones can keep the tunnel up all day.

A reverse proxy with authentication is the alternative when you want the controller’s web interface reachable from a browser without a VPN. It exposes one HTTPS endpoint, protected by strong login and ideally a second factor, and forwards to the controller. It is more convenient for family members and more exposed, so it needs keeping up to date.

Some controller projects also offer their own relay service, which is a paid or optional cloud that connects your phone to your controller through their servers. That is still a cloud, but it is one the house does not depend on: if it goes away, everything inside still works, and only remote access is lost.

Whichever you choose, treat remote access as a separate project from the local home. Get the house working locally first. Add the door in afterward.

What you give up

Convenience at setup. A cloud device is designed to be added in two taps from the vendor’s app. A local device is added to your controller, which may mean a pairing mode, a coordinator, and reading a device page. It is not hard, but it is more than two taps.

Some features. A vendor’s cloud may do things your controller does not, such as fancy energy reports, voice control through their assistant, or integration with a service you like. You can often rebuild these locally, but it is work.

Some products. The cheapest devices in a category are often cloud-only, and some categories have few local options at all. You will sometimes pay more, or wait for a better product.

Somebody has to run it. A local controller is a small computer in your house. It needs updates, a backup, and a person who knows where it is when something breaks. In a shared house, that person should not be the only one who knows how the lights work; keep physical switches working alongside the automations.

What you get in return is a house that answers to you, survives the internet going down, survives a company going under, and sends nothing about your habits to a server you cannot see. For most people who try it, that trade is easy.