One server is enough

Every few months someone publishes a diagram of the stack behind a personal website, and it has a queue in it. A queue, a cache, a container platform, a managed database, and somewhere near the bottom, the blog. I have built versions of that diagram myself, and each time the part that failed was never the blog. It was the plumbing around it.

So this site runs on one server, in one folder, with one process that answers requests and one file that holds every post. The web server passes a request to PHP, PHP asks SQLite for the rows it needs, and the page is rendered in a few milliseconds. There is no build step because there is nothing to build. There is no deploy pipeline because a deploy is a copy. When something breaks, the whole system fits in my head, which is the only observability tool I have ever found reliable at three in the morning.

The usual objection is scale, and it deserves a straight answer. A page here is a few hundred kilobytes of HTML. A modest machine serves thousands of those a second from memory, and the edge in front of it absorbs any spike before it reaches the box at all. The archive would have to grow by a thousand posts before the database layer noticed, and by then I would have other things to be proud of.

The second objection is durability, and that one I take seriously. The database is streamed to two object stores as it changes, a nightly copy goes to a third, and the restore procedure is rehearsed rather than assumed. Backups you have not restored are a feeling, not a backup.

What I give up is the ability to tell a story about architecture. What I get is an afternoon back every month. On a site whose only purpose is to hold my writing, that trade is not close.

One server. One folder. Write more, operate less.