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.
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
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.