•
3 min read
The Server That Didn't Come Back

A server rack in a dark room

For a long time, my personal projects ran on one small VPS. This website, a wedding planner I built for my own wedding, a self-hosted analytics dashboard, a WhatsApp bot. It had been running smoothly for a long time.

Then work got busy. For weeks my focus was on client projects and deadlines, and I didn’t have time to look at my own server. When I finally had a quiet moment to check on it, it was gone. The server had died, and it wasn’t coming back, along with the data that lived on it.

What survived, and what didn’t

All of the code survived. Every app lived in Git, so nothing I had built was lost. What went with the server was the data the apps had collected while they ran: databases, analytics history, a WhatsApp session, and a few configuration details that only existed on that machine.

That’s the part that’s easy to overlook in personal projects. Git protects your code by default. Data is different. It grows quietly on the server, and unless you set up something to copy it elsewhere, that server is the only place it exists.

Rebuilding

Rebuilding went quickly, because of how the apps were set up from the start. Every app had its own docker-compose.yml, and one shared reverse proxy handled domains and HTTPS certificates. Bringing a site back meant installing Docker, starting the proxy, copying the app over and running one command. This website was back online in under an hour, most of it spent waiting for DNS to update.

One detail stood out after the move. The site felt slow, even though the server answered in a fraction of a second. I traced it to the analytics script, which still pointed to the old server. Browsers waited for it to time out before the page finished loading. Disabling it brought the load time back to normal, and it was a good reminder of how one external dependency can hold up an entire page.

How I run things now

  • Back up data, not just code. Databases and uploaded files get copied off the server on a schedule, to a different location.
  • Keep the whole setup in files. Every configuration lives in the repository, so a new server can be built from scratch.
  • Keep external dependencies from blocking the page. A page should still load fast when a third-party service is down.
  • Treat every server as replaceable. If it can be rebuilt in an hour, losing one is an inconvenience, not a disaster.

Personal projects are easy to put on autopilot. This one was a push to give them the same care I give the systems I build at work.