The easiest path when building a short-term rental platform is to pick whichever cloud-based smart lock has the nicest API and commit to it. Every major competitor does some version of this. The lock is online, the API is documented, and you can ship an integration in a long weekend.
We don't do that. Staykey's default path is a Home Assistant hub that lives in the property, talks to locks over Z-Wave, Zigbee, or Matter, and treats the vendor cloud as optional. That's a harder path to build. It's also the only path we've found that keeps working when things get weird.
Here's what "when things get weird" actually looks like.
The cloud outages hosts never see coming
Smart lock vendors have outages. Not often. But often enough to break guest check-ins, always at the worst possible moment.
In any given year you can google the vendor name plus "outage" and find a reddit thread. The pattern is always the same: a vendor's API goes down, automations that depend on it stop firing, hosts scramble to manually send codes through whatever app is still working. The outage lasts 2–6 hours. The affected bookings last 2–6 days. Some of them leave 1-star reviews.
What cloud-only platforms offer in these moments is either "the vendor is working on it" or "reset the lock manually, here's the admin code." What you actually need is for the code to keep working, because the guest is in the driveway.
A Z-Wave lock paired to a local hub doesn't care that your internet is down. The code is already on the lock. The guest types it. The door opens. The outage might prevent you from creating a new code, but it doesn't touch the codes that are already set. That's the difference.
The subscription creep nobody talks about
Cloud-only locks come with their own subscriptions, separate from the hosting tool that drives them. Some are honest ($3–5/month per lock for "premium features"). Some are hidden until you hit a feature gate mid-stay.
A host running 4 properties on cloud-locked hardware is often paying:
- $25–50/month to the hosting tool (for the automation layer)
- $12–20/month to the lock vendor (for the ability to create codes programmatically)
- $0–15/month to a thermostat vendor (because the lock vendor doesn't do thermostats)
And the math only gets worse at scale. At 10 properties, the per-device fees eat a non-trivial portion of net revenue.
With Home Assistant, the platform itself is $0/month. The hub is a one-time purchase (a Home Assistant Green runs ~$149 and has a 5+ year lifespan). You pay for Staykey, you pay for the hardware once, you're done.
The "we shut down" risk
Cloud-only platforms have a real failure mode: the company pivots or shuts down, and your integration breaks. If you've built your entire stack on a vendor cloud, your hardware is suddenly dumb plastic.
I've watched this happen in adjacent spaces. A smart home startup raises a Series A, ships hardware, gets acquired, the acquirer sunsets the cloud, and customers are left with devices that no longer respond to commands. The hardware is physically fine. The cloud just isn't there anymore.
With Home Assistant underneath Staykey, that failure mode is decoupled. Staykey could disappear tomorrow and your hub would keep executing your automations. Your locks would keep accepting codes. You'd have time to migrate. That's a promise we can make because the architecture actually supports it.
The thing we give up
Being honest: there's a reason cloud-only is easier. The first lock pairs in 30 seconds. The customer never thinks about protocols or hubs or radio range. It works, right now, no hardware decisions.
The cost of our approach is that the first setup is longer. A host buying their first smart lock with Staykey is also buying a hub, maybe reading about Z-Wave for the first time, and absorbing concepts that cloud-only platforms hide.
We've made that setup as smooth as we can — the hardware planner gives you an Amazon-ready parts list, the setup guide walks through the first property in a single sitting, the add-on handles the networking. But we can't hide the fact that you're setting up a local hub, because that local hub is the thing that makes everything else work.
We think that's the right trade-off. Every host who's lived through a cloud outage agrees.
What "local" actually means in practice
Concretely, running Staykey on Home Assistant means:
- Codes are programmed onto the lock. When a booking lands, Staykey writes the code to the lock over the local radio. The code now lives on the device's own memory.
- Unlocks happen locally. The guest types the code, the lock checks its local table, the door opens. No cloud round-trip.
- Your internet can drop. Cloud-dependent features (new bookings syncing in, guest portal loading) pause. Already-scheduled codes keep working.
- The vendor cloud is optional. Some locks still call home to their vendor by default — you can disable that in most cases, or just ignore it. The vendor cloud isn't in the path of anything Staykey does.
The one-sentence version
Cloud-only smart locks are faster to set up and slightly cheaper per-device. Local-first smart locks are faster to unlock and don't care about outages. For a vacation rental, "doesn't care about outages" is what your 4.95 rating depends on.
That's why Staykey defaults to the harder path.
Related reading
- Why we built Staykey on Home Assistant — the architectural essay
- The complete guide to smart locks for Airbnb hosts — which locks actually work
- Matter for Airbnb hosts — the new protocol, and when it's a fit
- Smart Control — the product page