I disable the cloud on every Shelly plug in my house. And that is exactly why I love Shelly.
Stay with me, because that sounds backwards. A friend called me on a different version of it: “You’re the local-LAN guy, but you use Ubiquiti’s UniFi cloud API to run your networks. Pick a lane.” Fair hit. It looks inconsistent. It isn’t — I was just naming the principle wrong.
My aversion was never to cloud. It’s to captivity — systems you cannot function without the vendor’s cloud software running and reachable. That’s the whole distinction, and once you measure on that axis instead of “local good, cloud bad,” everything lines up.
The axis that actually matters: can it function if the cloud vanishes? Shelly, UniFi, and BrightSign say yes. My Echos say no — and they're on the way out.
The Real Principle: Autonomy, Not Isolation
“Everything on the local LAN” is a slogan I’ve repeated for years, and it was always a proxy for something more precise. When I actually write down what’s bugging me, it’s three questions:
- Autonomy — does it still work if the vendor or the internet vanishes?
- Authority — where does the control plane live, and who holds the keys?
- Blast radius — if the vendor gets breached, what do they get?
This is just reactor-safety thinking in a hoodie. On the boat we never asked “is this component good or bad.” We asked what happens when it fails, who holds control authority, and how far the damage propagates. Assume the breach. Reason about the blast radius before it happens. Defense in depth.
Cloud, by itself, fails none of those tests. Cloud dependency — captivity — fails all three. That’s the line.
Shelly: The Gold Standard, and I Mean It
Let me gush for a minute, because Shelly has earned it.
I’ve been running home automation long enough to remember when “hacker-friendly” meant popping the case, finding the UART pads, and flashing Tasmota onto an ESP8266 just to get a relay I could talk to locally without phoning home. I loved Tasmota — still do — but that was work. It was the tax you paid to own your own gear.
With Shelly, that tax is gone. You don’t have to re-flash anything. You don’t have to void a warranty with a soldering iron. Out of the box, these devices already give you full local control, and they support a genuinely absurd number of ways to talk to them:
- A local HTTP REST interface and a proper JSON-RPC 2.0 API on Gen2+ (
Switch.Set,EM.GetStatus,Shelly.GetStatus, the works). - MQTT, so they drop straight into the broker-based setup I already run.
- WebSocket push (
NotifyStatus/NotifyFullStatus) so you get events instead of polling. - BLE, and on-device scripting (mJS) if you want logic to live on the relay itself.
- And yes — their cloud too, if you want it.
That last point is the whole thing. Shelly offers the cloud as a choice, not a leash. Disabling it is one call — Cloud.SetConfig {"enable":false} — and the device still answers /rpc/... on the LAN exactly as before. You lose nothing load-bearing. You just stop renting a door into your house that you were never required to open.
So when I say “I don’t use Shelly cloud,” hear it correctly: I’m paying Shelly the highest compliment I can pay a vendor. They built a product so respectful of the owner that I can take the cloud or leave it and the thing works beautifully either way. That is exactly how it should be done.
Go buy Shelly products. Seriously. If you’re still cracking cases to flash firmware for local control, you’re working too hard. Shelly already did it for you, every interface you could want, no captivity. I’ve got a whole lighting-control and energy-metering build coming together on their Gen3 gear, and the thing I keep marveling at is how many front doors they leave open for me while making the vendor cloud strictly optional. Love these devices.
UniFi: Cloud as a Severable Reach-Through
Same test, same pass — different shape.
- The control plane is local. The UDM on my LAN holds the authority. Ubiquiti’s cloud API is a reach-through to a box I own — not the box itself.
- It’s reversible. Cut Ubiquiti off tomorrow and the network keeps routing; I keep full local control at the UDM. Autonomy intact.
- The convenience earns its keep. I also manage a remote UDM at another location, and for that one the cloud connector is the sane way in. That’s cloud used for reach, not a surrender of authority.
There’s one honest cost: the UniFi cloud API key is a remote, network-wide credential — the single place this genuinely extends my blast radius. So treat it like the root key it is. Scope it, rotate it, and prefer the local controller API when you’re scripting from inside the LAN anyway. (More on that loose end below.) But autonomy and authority both stay home, so UniFi passes.
BrightSign Control: Same Philosophy, Different Industry
Here’s one from my day job, because it’s the cleanest example I know and it’s the same principle exactly. I lead software at BrightSign, and our players follow this model on purpose.
Turn off BrightSign Control — the cloud — and the players keep playing. The content keeps running, the schedule keeps rolling, the sign on the wall doesn’t care that the management cloud is unreachable. The cloud is how you manage a fleet conveniently from anywhere; it is not what makes a player a player. And if you want local hands-on access, you can always enable the local DWS (Diagnostic Web Server) and talk straight to the device on the LAN.
Autonomy: yes. Authority: on the player. Cloud: an optional reach-through for fleet management. That’s a commercial product built for exactly the property I want in my house. It’s not an accident that it feels right — it’s the same value applied at industrial scale.
The Honest Tradeoff: Convenience Has a Price
Let me not pretend the cloud is some necessary evil you merely tolerate. It isn’t. The cloud software these vendors ship is genuinely, enormously convenient, and it solves real problems that are a pain to solve yourself:
- Multi-site. One pane of glass across my house, my remote UDM, and whatever else — without me standing up a VPN and a jump host.
- Centralized control and state. Schedules, scenes, firmware rollouts, fleets of players in the field. The cloud does the fan-out, the retries, the “which of my 200 devices is offline right now” bookkeeping.
- Remote access that just works. NAT traversal, dynamic IPs, TLS — all handled, nothing for me to babysit.
That’s real value. When I flip the cloud off, I don’t get that value for free somewhere else — I inherit the job of providing it. And “inherit the job” usually means writing software, or finding software, to do what the cloud was doing for me.
That’s not hypothetical. gofi is exactly that kind of software — the glue I write so I can manage my own gear on my own terms instead of leaning on someone else’s console. Every device I pull off the vendor cloud is a small promise to myself that I’ll cover the gap with my own code, my own broker, my own scripts. Sometimes that’s a joy. Sometimes it’s a Saturday I didn’t plan to spend. Either way it’s work, and it’s honest to say so.
So the issue was never “the cloud is bad.” The cloud is great. The issue is freedom to choose not to connect to it — and to pick up the convenience tab myself when I do. Shelly gives me that choice. UniFi gives me that choice. BrightSign gives me that choice. The cloud is there, humming along and making my life easier, right up until the day I decide I’d rather own the problem — and on that day the device doesn’t fight me.
Which brings me to the gadgets that do fight you.
The Anti-Pattern: My Amazon Echos (Actively Being Evicted)
Now the counterexample that makes the whole principle snap into focus.
I have Amazon Echos. I hate them. Not because they use the cloud — because they are captive to it. Pull the internet and an Echo is a hockey puck. There is no local mode, no /rpc/ to fall back to, no “disable cloud and keep the useful parts.” The device’s entire reason for existing lives on someone else’s computer, and the microphone in my house points at it. Autonomy: none. Authority: not mine. Blast radius: a listening device I can’t fully reason about.
And it’s not just the Echos. Ring cameras are the same disease in a different enclosure — the footage lives on Amazon’s cloud, the features live on Amazon’s cloud, and “turn off the cloud and keep a local recording” is simply not an option they offer. You don’t get to pick up the convenience tab yourself, because they never hand you the bill. There’s no local mode to fall back to, so there’s no choice to make. That’s the tell.
So the Echos are on the way out. (How I’m replacing them is another post — and I’m genuinely enjoying building it.) But they’re the perfect foil: same category of gadget as a Shelly or a smart display, opposite philosophy. One hands me the keys and lets me decide when to use its cloud. The other keeps the keys and never asks.
The rule in one picture: authority stays home. Cloud is welcome to knock — it never gets to hold the keys.
The Rule That Reconciles All of It
So here’s the actual rule the slogan was always standing in for:
I don’t care whether a product uses the cloud. I care whether it can live without it. Keep the control plane local and authoritative; let cloud be an optional, severable reach-through; and never buy a device that bricks when the vendor’s servers do.
Run everything through that and the “inconsistency” evaporates:
- Shelly — cloud fully optional, full local API either way. Gold standard. Buy it.
- UniFi — local control plane, cloud as reversible reach-through. Passes.
- BrightSign Control — players run with the cloud gone, local DWS on tap. Passes.
- Amazon Echo / Ring — captive, no local mode, no choice to make. Fails. Evicting.
Same person, same principle, four verdicts that only looked contradictory while I was measuring on the wrong axis. BOTH can be true — love the product and turn off its cloud — when the product was designed to let you.
The Loose End I’m Not Hiding
Being honest about where my own setup isn’t “done done”: for LAN-side scripting I don’t strictly need the UniFi cloud at all.
My gofi tool originally worked against the local UDM — -H <udm-ip> with a local controller account — and only later grew the cloud connector (UNIFI_API_KEY + UNIFI_CONSOLE_ID). That means the local path is probably the less-exercised one now, and I don’t fully trust code I haven’t run in a while. So there’s a verification pass owed:
- Local UDM: move scripting back to
gofi -H <udm-ip>with local creds, and retire the cloud key for that controller entirely. - Remote UDM: keep the cloud connector — that one genuinely is the reach-through the rule allows.
The UniFi cloud key is the one spot where I’m carrying more blast radius than I need to, and I know it. Naming the loose end is how you keep yourself honest about closing it.
What’s Next for Me
- Verify
gofilocal mode still works against the local UDM; if so, drop the cloud key for local management and keep cloud only for the remote box. - Finish evicting the Echos. (That’s its own story.)
That’s the whole thing. “Local LAN only” was never the real rule — it was shorthand. The real rule is keep authority at home and refuse captivity, and vendors who respect that deserve your money. Shelly respects it so thoroughly that disabling their cloud is a compliment. UniFi and BrightSign respect it too. Amazon’s Echo doesn’t, and that’s why it’s leaving my house.
Pick the right axis to measure on. Then “go buy Shelly” and “turn off Shelly cloud” stop being contradictory and start being the same enthusiastic sentence.
If this helped you think about your own smart-home autonomy — or if you’ve got a good local-first replacement for an Echo I should look at — drop me a note on LinkedIn. And yes: pay it forward.