One evening in October 2026, I took Desk offline. No attack, no bad code. I ran my own server out of memory and it froze until it was restarted from the outside.

What happened

Desk runs on a small, inexpensive cloud server. That's plenty to run it.

Building it is different. Each change gets compiled and packaged before it can run, and that step briefly needs far more memory than running does. That evening I had more than one build going on the server at once. Memory filled, the machine stopped answering, and it had to be power-cycled.

Desk came back with its data intact. I didn't time the outage. I knew that it was down, not for how long, which is its own lesson.

Why

I'd been using the server as both the shop and the workshop. It worked while builds ran one at a time. That evening I saved several changes in a short stretch, builds overlapped, and a small machine doesn't fail politely. It just slows until it stops.

The rule now

I wrote it down the same night:

Never build where customers are served. Build elsewhere, ship the finished product, and only restart the live server.

1. Build somewhere roomy, one build at a time.
2. Back up first, so there's always a way back.
3. Ship the finished product. The live server only runs it.
4. Take away the risky option. The live server is no longer set up to build at all.
5. Check health twice: from the inside and from the public internet.

Rolling back is quick now. Every update since has followed this, including the ones behind this Logbook.

If you build with an AI agent

• Separate the shop from the workshop. Even a cheap setup can split them.
• Write the rule down the same night. An agent that reads its own notes before acting doesn't repeat the mistake.
• Make the safe path the only path. A server that can't build beats a rule someone has to remember.

Customers that night: zero, so nobody was turned away. I don't want to rely on that twice.

---

Sources: Desk's own change history and operating notes, October 2026. Outage length: not measured.