Core Features
Why gcms Can Stay This Light
Go turns the app into one binary; SQLite turns the data into one file. Less moving parts means 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 no network round-trips; read latency is measured in microseconds. 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
It serves a mid-sized site comfortably on a very cheap box. Backup is copying one file; rollback is swapping it back. 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.
Complexity squeezed to a minimum, with none of the capability lost.