This guide describes the Mac sensing implementation. See Mac and Windows options for platform availability; features and permissions vary by platform.
Keeping Smart-Home Data on Your Own Hardware: Why No-Cloud Security Matters
Ask what a smart home knows about you and the answer is more intimate than most people expect. Not the individual events — a light turning on is trivial — but the pattern: when you wake, when the house empties, which rooms you use at night, when you're away for a week. Assembled over months, that pattern is a diary you never chose to write. The architecture question of the decade for smart homes is simple: where does that diary live?
What your smart home actually records
Even a modest setup generates a running behavioral record:
- Occupancy rhythms — arm/disarm times, motion events, presence per room. This is, functionally, a schedule of when your home is empty.
- Routine fingerprints — scenes and automations reveal habits: "Good Night" at 11:15, coffee machine at 6:40, thermostat setback on weekdays.
- Device inventory — what you own, where it sits, when it's reachable.
- Sensing streams — the richest tier: microphone, camera, and radio-based sensing, whose raw signals say far more than the events derived from them.
None of this is hypothetical telemetry. It's the working data any smart-home system needs to function. The only question is who else is in the room when it's processed.
What changes when it routes through a vendor cloud
The dominant smart-home architecture sends device state and sensor events to the manufacturer's servers, which run the logic and send commands back down. That design is convenient for vendors — and it has consequences for you:
Your data outlives your intentions
Once occupancy data sits on someone else's servers, its future is governed by their retention policy, their acquisitions, and their terms-of-service updates — all of which can change after you've bought the hardware. You can delete an app; you can't audit a datacenter.
You inherit their breach surface
A vendor cloud aggregates the schedules of every customer in one target. Your own Mac is a target only for someone who cares about you specifically; a platform database is a target for everyone. When a platform is breached, the customers absorb the harm.
Third parties can compel or request it
Data held by a company is subject to legal process served on that company, and to whatever sharing its policies permit. Data that exists only on hardware in your home enjoys the strongest practical and legal footing you can give it: to get it, someone has to deal with you.
Your house breaks when their servers do
Cloud-routed control means an automation as basic as "lights on when I walk in" makes a round trip through a datacenter. Vendor outage, discontinued product line, or your ISP having a bad night — and switches stop switching. A home shouldn't need permission from a server farm to run itself.
The subscription treadmill
When the logic lives on their servers, continued function becomes a service you rent, and features you bought can migrate behind new fees. Owning the compute means owning the behavior.
What "no vendor cloud" means concretely
The alternative is an architecture where the hub is hardware you own, on your own network:
- Discovery and control happen on your LAN. Protocols like Bonjour/mDNS and SSDP let a hub find and command devices directly — lights, plugs, speakers — with no external round trip. With the internet down, the automations keep running.
- Sensing is processed on-device. This is the tier where architecture matters most. Raw microphone, camera, and radio-sensing streams should be consumed and reduced to events (occupied / empty / motion / breathing) on the machine you own, with the raw signal never leaving it. Our room-sensing guide explains why the raw streams are the sensitive part.
- Logs live on your disk. An activity history you can open, export, and delete — in a folder you control, not a dashboard you're allowed to view.
- Alerts go where you point them. Instead of a vendor's notification service, an on-device system can POST alert text to an endpoint you choose. That destination receives the data, and HTTPS is essential when the text is sensitive. This pairs naturally with self-monitored security.
The honest trade-offs
Keeping everything on your own hardware isn't free of costs, and it's worth naming them:
- Remote access takes intent. Cloud systems give you an anywhere-app by default; an on-device system reaches you remotely only through channels you set up, like a webhook-to-phone push path.
- You administer it. Updates, backups of your own config, and the hub machine's health are yours to mind. For many people that's the point; for some it's a chore.
- Some devices are cloud-bound by design. Gear whose only API is the manufacturer's server can, at best, be tracked and labeled honestly by a hub that refuses to pretend otherwise. Check for open, locally controllable devices (WLED and plain HTTP devices are good citizens here) when buying.
How Vigil implements this
Vigil is built as the on-device answer: the hub is the Mac you already own. Device discovery and control run over your LAN; scenes and automations evaluate on the Mac; acoustic sonar, optional camera pose, and optional through-wall radio frames are processed on-device. The activity log lives in Vigil's local application-support database. Core control and sensing can run with the internet off. Optional Away Alerts send derived alert text to your chosen destination, and a manual update check fetches a public version manifest. If part of your goal is dropping cameras from the equation entirely, start with home security without cameras.