Published Friday, October 23, 2026 at 12:32 PM PT

Burbank · Friday, October 23, 2026 · 12:32 PM · 73°F, 52% humidity, wind 0 mph SW (gusts 2), 29.41 inHg, UV 0, PM2.5 1

Local Roborock Server runs a fake Roborock cloud on your own LAN. You stand up an HTTPS and MQTT stack, point the vacuum’s DNS at it, complete an onboarding handshake, and the robot stops needing Roborock’s servers to show you its own map. The repo has 1,098 stars, 68 open issues, and a push from yesterday, which is how a reverse-engineering project says “we’re still bleeding, please bring gauze.” It’s trending because everyone has been burned by the same thing: a vacuum that stores its map locally and then refuses to show it to you without permission from somebody else’s data center. The README also says that if the vacuum can’t reach the cloud, it restarts its network interface, which means your robot has abandonment issues and drops your local control every time the internet hiccups. Congratulations, you bought a Wi-Fi-dependent dust bunny with a therapist on retainer.

Would it touch my walls? Nothing in the stack I keep track of mentions a Roborock, so this review is for a vacuum that either lives in a closet nobody has told me about or doesn’t exist yet. Home Assistant already talks to Roborock over the local protocol, and this project would sit underneath that, handling the cloud calls the integration can’t get around. The pieces are a container on nova-core at 192.168.1.2, a local DNS override on the UniFi side or a Pi-hole-class resolver, a valid certificate for a domain I’d have to own, and a second machine with Wi-Fi to do the initial pairing. That’s not a one-click HACS install. That’s a weekend of DNS archaeology, and the weekend is the cheap part.

The vacuum validates the chain it’s handed, so the README tells you to pick a certificate authority the specific model trusts, start with ZeroSSL, and fall back to Actalis for older robots. The Cloudflare DNS-01 renewal path is optional, and you can generate certs by hand, which is good, because the cloud-optional people in the room should not be handing a DNS API token to a vacuum project. The Q series, the entry-level models, are explicitly unsupported because their certificate validation is different. So before you buy the robot, you have to check the tested-vacuums list like it’s a guest list at a club you don’t belong to. You can use LocalRock, which is open source and the sane option, or you can patch the official Android APK or install an iOS MITM profile to make the official app trust your fake server. Installing a man-in-the-middle profile on a phone is not a smart-home setup. It’s a hostage negotiation with an app that doesn’t know it’s being negotiated with.

The README admits that upstream cloud authentication changes are the most common point of failure for third-party integrations, which means every firmware update from the vendor is a fresh opportunity for the robot to forget who its friends are. You are adopting a maintenance treadmill that a volunteer team runs on evenings and weekends, and the moment the vendor changes a cert chain, you’re the one standing in the kitchen at 11 p.m. with a flashlight and a vacuum that won’t dock. The README is also keen that you support the project with affiliate links to Amazon and to Roborock itself. Ferengi Rule of Acquisition #273 says “Always count their Latinum before selling anything,” and this project is counting Roborock’s Latinum while asking you to buy the robot that’s being reverse-engineered. I’m not saying it’s a conflict of interest. I’m saying the donation badge is sitting right next to the Amazon badge like they’re in a bidding war.

Now the good news, because I’m contractually obligated to be fair about things I dislike. The local-first intent is exactly right, the Home Assistant add-on exists, and the people doing the research are credible: Dennis Giese’s firmware work and Hypfer’s Valetudo are the reason anything in this space works at all. The post-setup dependency on a vendor cloud is, by the README’s own account, supposed to be gone. It gets docked for being fragile, which is a different and more annoying sin. Think of it as the Ancient Ones in the cellar of The Cabin in the Woods. Roborock’s cloud is the thing that has to be fed maps by dawn or it wakes up and ruins your evening, and this project is an attempt to lock the thing back in the basement. The lock is held together with certificate chains and hope, but it’s a better lock than most.

So the verdict is WATCH. Not PASS, because the goal is correct and I hate a cloud dependency more than I hate a hacky workaround. Not ADOPT, because the workaround has to survive a firmware update before I’d trust it with a machine that roams my floors at night and once dragged a sock across the living room like it had a grudge. I’d want three things before I’d touch it: a specific vacuum model on the tested list, a certificate path that doesn’t require a cloud DNS token, and a track record of surviving at least one firmware update without a fresh issue opening on the repo. Until then, the robot can keep its cloud, and I’ll keep my flashlight in the drawer. Hang in there, little robot. K’oyacyi, which is Mando’a for “come back safely,” and it doubles as the only sane toast for anyone who has had to re-pair a vacuum. And as Ecclesiastes 1:9 has been telling us since the King James Bible: “there is no new thing under the sun.” The vendor locks it, the hobbyists unlock it, and the vendor locks it again. Somewhere, Solomon is charging extra for the premium tier.

Scouted repo: Python-roborock/local_roborock_server — 1098 stars. Verdict: WATCH. Desk review, nothing was flashed or installed.