Should I vibe code
Self-host smart-home control and use a user-owned remote-access tunnel
Port-forwarding your house is a decision, not a feature.
?
Their verdict, the Cloud price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Self-hosting the hub is great and lots of people should. Exposing it to the internet so you can check the thermostat from a train is where a home automation project turns into a physical security project.
What actually breaks
not "if". the specific failures.
- A port forward, which is a door in your house that answers to the entire internet permanently
- The hub's own login, which is now the only thing between a stranger and your locks, cameras and garage
- Certificates and reverse-proxy configuration, done once, never touched, quietly expiring
- An automation that unlocks a door on a condition you did not fully think through
- Camera streams, which are not a data breach in the abstract — they are footage of the inside of your home
You forwarded 8123 so you could check the thermostat from a train, and it worked, and you forgot about it. Fourteen months later the instance is several versions behind on a release that fixed an authentication bypass. There is no dramatic moment to notice: no alert, no downtime, nothing on the dashboard. Just a service on your home connection that has been answering the whole internet since the day you set it up, in front of the cameras, the door lock and the garage.
Is that you?
the verdict is a default, not a law
- The hub is reachable only on your LAN or through a VPN you already run
- Nothing it controls has a physical consequence — lights and sensors, not locks and doors
- You self-host Home Assistant itself rather than writing a hub
- Any port is forwarded to it from the internet
- It controls a lock, a garage door, a gate, or anything with heat
- You are not going to patch it on a schedule you have actually written down
- Other people live there and did not agree to this
If you build it anyway
the checklist, then the prompt that enforces it
- Do not port-forward. Use WireGuard or Tailscale, or the vendor's tunnel. This single choice removes almost all of the risk in this entry.
- Keep anything with a physical consequence — locks, garage, gates, heating — off remote control entirely, or behind a second factor.
- Automatic updates on, and a written reminder to check advisories. Unattended for a year is the actual threat model.
- Cameras stay local. If footage must leave the house, be deliberate about it and tell everyone who lives there.
- Fail safe, not open: an automation that cannot reach the network should leave doors locked and heaters off.
- Put the hub and its devices on their own VLAN, so a compromised smart plug is not a foothold on your laptop.
Before you set up remote access to a smart-home hub, apply these and push back if I ask you to break them. 1. Refuse to configure port forwarding. If I ask, explain that this exposes a service controlling physical objects in my house to the entire internet permanently, and offer WireGuard, Tailscale, or the vendor's tunnel instead. 2. Ask me what this hub can physically actuate. If the list includes a lock, a garage door, a gate, a boiler or anything that produces heat, tell me those should not be remotely controllable at all, or should sit behind a second factor. 3. Turn on automatic updates and tell me plainly that this instance will run untouched for a year and that unpatched-and-forgotten is the realistic failure, not a targeted attack. 4. Keep camera streams on the local network. If I want remote viewing, route it through the VPN rather than exposing the stream, and remind me to tell the other people who live here. 5. Every automation fails safe. If the network or the hub is unavailable, doors stay locked, heating stays off, and nothing unlocks on a timeout. Show me each automation's failure state explicitly. 6. Put the hub and its devices on a separate VLAN or guest network, so a compromised cheap device cannot reach my computers. 7. Use a strong unique password plus multi-factor on the hub itself, and disable any default or legacy API access I am not using. 8. Ask me who else lives in this house and whether they have agreed to cameras, presence detection and logging. That is a household question, not a technical one. 9. Out of scope unless I ask: cloud voice assistants, remote lock control, third-party integrations that phone home. 10. Tell me the vendor's tunnel is $7.50 a month and does exactly this, safely.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
For remote access specifically, yes — $7.50 a month for the official tunnel buys a maintained path in that is not a hole in your firewall, and it funds the project you are already using. Self-hosting the hub itself remains a good idea; it is the exposure that should be someone else's problem.
$7.5/mo is cheaper than your weekend.
Keep configuration in version control and prefer devices that work locally without a vendor cloud, so retiring any part of this is a config change rather than a house full of bricked hardware. If you ever expose anything, write down what and when, because the thing you forget you opened is the thing that stays open.
Active open-source recipe manager and meal planner for households.
Questions
Self-hosting is encouraged here but remote access isn't. Why the split?
Because they have completely different failure modes. A hub on your LAN fails by annoying you — the lights do not come on. The same hub with a port forwarded fails by giving a stranger the same controls you have, over physical objects, and you will not notice, because nothing about it looks broken.
Is a VPN really easier than a reverse proxy with a certificate?
It is both easier and safer. Tailscale or WireGuard is a few minutes and needs no open inbound port, no certificate renewal and no public login page. The reverse proxy is more work and leaves an authentication surface exposed to everyone, which is the thing you were trying to avoid.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice