Two outages in a year, ten seconds each#
Pieter Levels runs his businesses alone, and by June he had spent almost a year letting Claude Code edit his production server directly. No staging. No local copy. The agent changes the live files and visitors see the result.
In a June post he said it “sounds like it should go wrong but it just doesn’t.” His count: “only twice in 12 months messed up,” and each time his site “didn’t load for 10 seconds.”
That’s a better uptime record than plenty of teams with full CI pipelines. So it’s worth asking what makes it work, because the workflow is spreading. ByteGrad just rebuilt the whole thing on camera in the video above, and his verdict was mixed: an “interesting setup,” but one that “feels a bit fragile.”
Both are right. The setup works for levelsio because of things that are easy to skip when you copy it.
What the setup actually is#
The pieces are simple, and each one does one job:
- A VPS with every inbound port closed. Levels uses an empty firewall at his host that blocks everything, and says to test that it does.
- Tailscale for you. Your laptop, phone and server sit on a private network. SSH only works from inside it.
- Cloudflare Tunnel for visitors. The server opens an outbound connection to Cloudflare, so ports 80 and 443 don’t need to be open at all.
- tmux, so one Claude Code session survives. Start it on the laptop, attach from your phone in Termius, and both screens show the same session.
Levels made the security case in a post he reshared on Oct 23, “now that everyone is getting hacked.” His point: an SSH key doesn’t protect you from the exploits AI is now finding, so take the box off the public internet. With Tailscale and the tunnel, he wrote, you’ve cut the attack surface down to those two, “much safer, not perfect btw, but nothing is.”
ByteGrad’s walkthrough shows how fast this goes. He has Claude Code install Node, Tailscale and the Cloudflare daemon itself, then edits the live site from his iPhone. But to get there he gives the agent passwordless sudo and tells it to skip permission prompts. That’s the part that should make you pause. You’ve locked the doors to outsiders and handed the only key to a process that acts on its own.
The parts people skip#
Here’s what gets lost when the setup goes viral.
Levels already has backups. ByteGrad closes by saying you’d need to add “other things like backups.” Levels covered that in the same June post: “I have 3-2-1 backups, multiple on-site and off-site backups.” Ten-second outages are survivable when you can restore anything. Without that, the first bad edit to a database is the outage.
He’s solo, and he says so. In the same post, Levels wrote that at a big company he’d recommend the same workflow but with a staging server, “so it wouldn’t touch production, for safety and regulatory reasons.” The no-staging part isn’t a rule. It’s a choice that only makes sense when you’re the only one who can break things, and the only one who has to fix them.
His work is a particular kind of work. He describes hacky projects that go live in seconds. An agent editing a file in place is a very different risk from an agent running a migration, rebuilding a frontend, or restarting a service other people depend on.
Where it broke for me#
I tried a version of this. On Oct 14 I ran Claude Code, with a coding bot on top of it, on my own small VPS, which I call Zeus. It didn’t last. It was too slow, and processes kept getting killed for running out of memory. My coding jobs went back to Claude Code on my Mac. Zeus is still up and still does other work. It just doesn’t do the coding.
Nobody mentions this one, and it hits before any security question does: a box sized for a web app is not sized for an agent.
A web app at rest is cheap. It sits there and answers requests. An agent doing real work isn’t at rest. It installs packages, runs builds, runs tests, sometimes several at once, all while the agent process itself holds memory. That’s the load of a developer laptop, on a machine you rented to serve pages.
When memory runs out, Linux doesn’t slow down politely. The kernel picks a process and kills it, and it won’t always pick the one you’d choose. If the agent shares the box with your production app, your site can be the one that goes. That’s how a careful agent still takes production down: not by writing bad code, but by running out of room while running the tests.
So before you copy the setup, check this first:
- How much memory is left with your app running? That’s the agent’s whole budget, builds and tests included.
- What happens to your site when something gets killed? Make sure the service restarts on its own, and find out before your users do.
- Can you restore yesterday? If the answer is “probably,” you’re not running levelsio’s setup. You’re running the risky half of it.
Who should actually do this#
If you’re solo, your sites are small, you have real backups, and your server has memory to spare, this is a fast way to work. Levels has a year of results to show for it.
If any of those is missing, keep the agent off the production box. Run it where builds can eat memory without taking your site down, push the result, and let the server do the one job it was sized for. That’s what I ended up doing, and my Mac is a lot better at it than my server was.