From Jekyll to Pressbin — what changes when you drop the build

Jekyll mattered. It convinced developers that a repository is a content system, and GitHub Pages made that feel official: push Markdown, CI runs jekyll build, the world sees HTML.

Years later, many of us still blog from repos — but the toolchain around Jekyll aged. Ruby versions, gem bundles, Actions minutes, and _site/ artifacts in CI logs are familiar friction.

Pressbin is a thought experiment turned binary: what if the server ingested Markdown directly and skipped the static compile step?

What Jekyll still does better

Credit where it is due:

• Free hosting on *.github.io without maintaining a VPS
• Liquid templates and a vast theme ecosystem
• _drafts, collections, data files as first-class concepts
• Pure static output — nothing to patch on the server because there is no server

If your requirements stop at “beautiful personal site on Pages,” Jekyll (or Hugo, or Eleventy) may already be finished work.

The hidden cost of “just push to main”

Even on Pages, each push triggers:

bundle install
jekyll build
# deploy _site/

Plugin compatibility breaks CI in exciting ways. Ruby 3.x vs 2.x drama visits every upgrade cycle. Monorepo layouts confuse baseurl settings.

Pressbin’s CI is thinner:

pip install requests pyyaml
python3 .github/scripts/push.py posts/changed-file.md

The heavy lifting — Markdown parsing, HTML rendering, FTS index updates — happens inside the running binary when the API accepts the sync payload.

Repos stay clean

A Jekyll repo often debates:

• Commit _site/ or not?
• Store build output in a gh-pages branch?
• Use Actions artifacts?

A Pressbin content repo holds Markdown and workflow files only. No generated HTML in Git. The database on your server is the rendered cache.

That separation matches how teams treat application code: source in Git, binaries elsewhere.

Features you might miss — and workarounds

Jekyll feature	Pressbin approach
Liquid in templates	Default theme in binary; override path planned via config
Plugins	Pre-sync processing in CI if you must
github-metadata	Hard-code site.url in config.yml
Giscus comments	Front matter + theme hooks (comments config in example)

Pressbin is opinionated: one default theme, fast path for essays. Customization goes through template overrides and CSS, not gem plugins.

Who should migrate

Good candidates:

• You moved off Pages because you wanted a custom domain and control
• You are tired of Ruby in CI for twelve posts a year
• You want search without adding Pagefind
• You already split “engine” and “content” mentally

Poor candidates:

• You rely on GitHub’s free static hosting and zero ops
• Your site is mostly Liquid wizardry and Jekyll plugins

A weekend migration plan

1. Export posts to posts/{slug}.md with front matter (title, date, tags, summary, slug)
2. Fork pressbin_blog_template for .github/workflows/sync.yml
3. Deploy Pressbin on a VPS; save the first-run admin key
4. Create a pb_sync_ key; add secrets to the content repo
5. Push — first sync uploads all posts; fix URLs with explicit slug fields
6. Point DNS; keep the old site read-only for a month

Why this is not “anti-Jekyll”

Jekyll proved Git-backed writing works. Pressbin assumes you believe that and asks the next question: does the build step still earn its keep?

For many personal blogs, the answer became no. The build was ceremony between git push and “it is live.” Pressbin removes the ceremony and keeps the Git part — which was always the valuable half.