Ghost vs Pressbin — product UI vs Git as CMS

Ghost started with a clear thesis: WordPress was the wrong shape for blogging. Ship a modern editor, a clean theme layer, and a Node stack that feels current. For many independent publishers, Ghost delivered — especially with Ghost(Pro) handling the ops.

Pressbin starts from a different thesis: the CMS is already Git. The server’s job is to store rendered posts, serve them quickly, and expose a small API — not to compete with Notion in the browser.

Ghost admin path vs Pressbin Git sync path

Two legitimate publishing cultures

Ghost culture: open Admin, draft in the editor, preview, publish or schedule, manage members and newsletters in the same product. The UI is the workflow.

Pressbin culture: open your content repository, edit posts/my-essay.md, push to main, let CI sync changed files. Review happens in pull requests if you want it. Rollback is git revert.

Neither is “more professional.” They optimize for different authors.

What Ghost gives you that Pressbin will not

Be direct about gaps:

  • Memberships and paid newsletters are first-class in Ghost’s product story
  • Email delivery integrated with the same dashboard
  • A beautiful writing surface for people who do not want to touch Markdown
  • Managed hosting with a vendor who understands Ghost upgrades

If your business model is “paid list + posts behind a paywall,” Ghost (or Substack) is solving a problem Pressbin does not attempt to solve.

What Pressbin gives you that Ghost does not

  • Single-binary deploy — no Node version pinning, no pm2, no separate DB container unless you choose to add one elsewhere
  • No public admin — smaller attack surface; writing happens off-box in Git
  • Content portable by construction — your repo is the canonical source, not an export ZIP
  • Automation-first API — admin routes for posts, keys, settings; sync route for CI

Pressbin sync pipeline

Sync keys only carry posts:write (and delete via DELETE /api/sync/{slug} when you remove a file). Admin keys are for humans and scripts that manage the instance.

Self-hosting Ghost vs running Pressbin

Self-hosted Ghost still means:

  • Node.js runtime maintained on the server
  • Database (often MySQL) running alongside
  • Theme and Ghost core updates on Ghost’s schedule
  • Admin app exposed (you should put it behind auth and TLS)

Pressbin on the same VPS is closer to:

./pressbin --config config.yml

Behind nginx with Let’s Encrypt. Content arrives via webhook-shaped CI, not via typing into a textarea on the server.

When we chose Ghost at a previous job

A editorial team of four non-engineers, a paid newsletter, and no appetite for Git — Ghost was correct. The cost was real money and real ops, but the human workflow matched the team.

When the authors are engineers (or technical writers happy in Markdown), the Ghost admin becomes an extra place to log in. Every post exists twice: in Git for review and in Ghost for publish — unless you build bridges.

Pressbin removes the duplicate. Git is the only draft store.

How to decide in one meeting

Question Lean Ghost Lean Pressbin
Do authors need WYSIWYG? Yes No
Is paid email core revenue? Yes No
Do we already standardize on Git for docs/code? No Yes
Can we operate Node + DB? Yes Prefer minimal

Bottom line

Ghost optimizes for publishers who want a product. Pressbin optimizes for developers who want a deploy.

If that sentence stings, Ghost is probably your tool. If it sounds like relief, try the binary on a spare VPS and push one post from a content repo - you will know within an afternoon which workflow fits your hands.