HomeKit
Apple's smart home framework. End-to-end encrypted home data, on-device camera processing.
Private alternatives to Google Home, Amazon Alexa, Samsung SmartThings, Philips Hue, vetted against our public criteria.
Grouped by threat level
Apple's smart home framework. End-to-end encrypted home data, on-device camera processing.
Local-first, open-source home automation hub with thousands of device integrations and no mandatory cloud.
Vendor-neutral, Java-based home automation platform with local control and a large binding ecosystem.
Lightweight open-source home automation system that runs well on low-power hardware like a Raspberry Pi.
Open-source IoT and home automation platform built on Node.js with a large adapter ecosystem.
No matches for those filters.
Smart speakers and hubs from Google and Amazon turn your home into an always-on microphone and a data feed, with device states and routines logged to a cloud you do not control. The platforms below run the automation locally, on hardware in your own home, so your lights and sensors answer to you instead of an advertising company. The result is a home that keeps working when the internet drops and keeps quiet when it does not.
Google Home and Alexa are front ends for a cloud service, and that is the architecture, not a preference you can change. The voice processing and the automations live on the vendor’s servers because that is the product being sold, so the data has to travel there for the device to do its job. Muting a microphone or deleting a recording after the fact does not alter the design; it still routes your home through a company whose business is knowing what happens inside it. No settings screen turns a cloud product into a local one. A hub that runs the logic in your house takes the server out of the loop entirely, which is the only change that actually moves the data home.
Every platform here is held to our public listing criteria, weighted for where the automation actually runs. We want local control by default, so routines fire without a round trip to someone else’s cloud, and an open-source core so the community can audit what the hub really does. Broad device support matters just as much, so you are not locked to a single vendor’s catalogue. A mandatory cloud account counts against a platform, because it reintroduces the dependence we are trying to remove. We only list a hub we would trust to run our own homes.
Local control is the whole point, so start there: the hub should keep running when the connection drops, and your device states should never need to leave the house to trigger a routine. Broad device support comes next, because a hub that speaks Zigbee and Z-Wave, Matter and Wi-Fi, frees you from buying into one ecosystem. An open-source core matters too, since it lets the community verify the behaviour rather than take it on faith. Treat a required cloud account as a red flag, because it quietly puts a company back in the middle of your home.
You gain more than you give up, with one honest catch. A local hub typically offers deeper automation and supports more devices, and it keeps responding during an outage, which the cloud assistants cannot. What you trade is the polished out-of-box voice experience and the no-setup convenience of a branded speaker, at least until you configure a local voice option of your own. For most people the swap is a clear win: the automations get more capable, and the home stops reporting to anyone.
Start with one hub on a small computer or a Raspberry Pi, then add your existing devices through their local integrations. Rebuild your handful of routines there and keep the vendor app running in parallel until the new setup is stable. When it is, unplug the cloud speakers. If you are leaving Google’s assistant specifically, our Google Home alternatives page walks through the move, and the broader de-Google playbook covers the rest of the ecosystem. Pairing a local hub with open-source router firmware keeps the network underneath it as honest as the home on top.