Core Features
gcms Architecture: One Go Binary, SQLite, and When It Fits
Go turns the app into one binary; SQLite turns the data into one file. Fewer moving parts make a site you can maintain for years.
A content site's real needs are humble: store content, render HTML, let people and crawlers read it reliably. gcms keeps that shape light with Go + SQLite.
One binary
Go compiles the whole app into one static executable; embed.FS bundles templates and assets in. No runtime, no dependency install, no environment config — upload, run, done. Cross-compiling to any platform is just a different GOOS.
One file
SQLite has no separate process, and reads never cross the network. With WAL, reads don't block writes and writes don't block reads — the only limit is one writer at a time, which a read-heavy content site barely notices.
A low-maintenance trade-off
So a small server is usually enough. One database file doesn't mean a one-file backup, though: gcms keeps SQLite in WAL mode, so the latest commits can still be sitting in -wal. For a live backup, write a consistent copy with VACUUM INTO or the sqlite3 .backup command; if installing sqlite3 is inconvenient, stop the service first, then take the .db together with any -wal and -shm next to it. Back up uploads and your startup config alongside. To roll back, stop the service, move the current .db, -wal and -shm out of the way, then put the backup in place — a leftover -wal can be replayed onto the restored file and corrupt it. Until you genuinely need multi-machine shared data, this simplicity is the better architecture.
When a heavier stack is better
If your editors write concurrently at high volume, need complex approval workflows, or require multiple machines to write the same dataset, a traditional database and collaboration suite may fit better. gcms bets that most content sites first need to be deployable, backup-friendly and maintainable for years.