Introducing trunkcms

trunkcms is a small, stateless blog engine written in Go. Your content lives in a GitHub repository. Editors sign in with GitHub, write Markdown in a web UI at /admin, and every save is a commit. Each running instance picks up the new commit, rebuilds the site in memory, and swaps it in.

There’s no database. There’s no object storage, queue, or Redis. GitHub is the only external service.

Why another blog engine?

Static site generators get a lot right: content in Git, Markdown files, no database to babysit. But they push the build somewhere else. A post becomes a CI run, a new artifact, and a deploy. And the people who write the posts have to be comfortable with all of that.

Hosted CMSes fix the editing experience and take the files away from you.

trunkcms tries to keep both halves:

• Writers get a browser. A plain Markdown editor with a live preview rendered by the real theme, drafts, scheduling, and image uploads.
• The site stays a repo. Every save is a real commit, authored as the person who made it. You can git clone your whole site, review it in a PR, or edit it on github.com, and the site rebuilds either way.

Rebuild in place

The trick is that “rebuild and redeploy” happens inside the process. When a new commit lands, each instance streams the tarball at that SHA, renders the whole site, and swaps an atomic pointer. A blog with a few hundred posts renders in well under a second, so rebuilding everything every time is fine.

That means the container image is only the engine. Content changes never rebuild it, and the same image runs on Kubernetes, Cloud Run, ECS, or Lambda.

Try it

git clone https://github.com/nullism/trunkcms
cd trunkcms
TRUNKCMS_CONTENT_DIR=./testdata/site go run ./cmd/trunkcms

Then open /admin and sign in as dev-admin. The getting started guide covers running it against a real GitHub repo.

This site is built with trunkcms too. Its theme, docs, and this post are all in one content repo, and every page here is a commit.