This site runs on a CMS that is literally one binary and one SQLite file. Compare that to a classic LAMP CMS — PHP, Apache, MySQL, a thousand PHP files, and a package manager to keep it all patched. The difference is not cosmetic.

What single-binary actually gives you

  • Deployment is a file copy. Build once (GOOS=linux go build), copy the binary, run it. No dependency installation on the server, no version drift between machines.
  • A tiny attack surface. There is no PHP interpreter parsing requests, no MySQL port, no web of third-party plugins. One process, one config file.
  • Upgrades are boring. Replace the binary, restart. Rollback is keeping the old binary.
  • The database is a file. SQLite means no database server to install, secure, or tune — and backups are VACUUM INTO.

The honest tradeoffs

  • You trade ecosystem for control. A single-binary Go CMS does not have a plugin marketplace or a million themes. What it has is code you can read and change.
  • Concurrency and scale have the limits of a single node. For a content site that fits one server — which is most of them — that is a feature, not a bug.
  • You maintain it. The upside is full control; the cost is that maintenance is yours.

Why I went this way

I wanted the operations of a CMS (drafts, media, comments, ad slots, a web editor) without the LAMP baggage. A single Go binary with SQLite gives me all of that and removes the parts I never wanted: package soup, an interpreted runtime, and a database server to babysit.

The stack I run it on — systemd, nginx, Cloudflare, GoAccess — is covered in another post. The short version: one binary, one file, one cheap VPS, and backups that are a single command.