Real version control for your Ghost posts

If you have ever made a sweeping edit to a Ghost post and then wished you could see exactly what changed, or roll the whole thing back, you have run into the limits of how Ghost tracks history. Ghost does keep some history — but it is far more modest than the safety net most people assume they have. This guide explains what Ghost actually stores, where it falls short, and how Specter gives your blog a real safety net behind every change.

What Ghost’s built-in revisions actually do

Ghost is not a complete blank slate here. The editor has a post history feature: open a post, go to the settings menu, and you can browse previous versions of that post and restore any one of them with a click. When you are working with a team, it even shows who made each change. For catching a single bad edit on a single post, it works.

The catch is in the fine print. Ghost only keeps the last handful of revisions for a post — historically around the most recent ten, after which older versions are dropped for good. So if you have edited a post a dozen times since the version you actually want, that version is simply gone. The history is per-post too, surfaced one post at a time inside the editor. There is no view of your blog’s history as a whole, no way to ask “what changed across the site last Tuesday,” and no diff that shows you the precise lines that moved. And because the revisions are tied to the editor, a bulk change made through the Admin API or a script is not something you can browse and restore the same comfortable way.

For the kind of work this site is about — running an AI recipe across every post at once — that gap matters most. The moment you are editing dozens or hundreds of posts in one sweep is exactly the moment a few per-post editor revisions stop being enough.

How Specter changes the story

Specter connects to your Ghost blog in the browser and brings every post into one workspace, and two things follow that the editor’s revisions never offered.

First, every change goes through a diff before it ships. Before anything touches Ghost, you see exactly which posts would change and what would change in each — the whole blast radius of a bulk edit, reviewed in one place, not surfaced one post at a time. Reviewing it is free.

Second, every publish keeps a snapshot behind it. Reverting a post to an earlier state is a decision, not a recovery project — and there’s no ten-revision ceiling quietly dropping the version you wanted. That snapshot-behind-every-publish is the safety net that makes a sweep across hundreds of posts survivable: you ran the recipe, the diff looked right on most and wrong on a few, you sent those back, and anything you change your mind about later is one revert away.

If you haven’t connected yet, start with connecting Specter to your Ghost blog. Subscribe now and your workspace opens with 500 free credits — browsing, reviewing diffs, and reverting cost nothing.

The pattern fits neatly with the rest of how Specter is meant to be used. If you’re running large metadata sweeps, see how to bulk edit Ghost posts for SEO; if you’re letting AI rewrite content, see editing Ghost posts with Claude. In both cases the rule is the same: review the diff, then publish — with a snapshot waiting behind it. Ghost stays your publishing home; Specter becomes the memory it never quite had.

Want permanent, diffable, whole-blog history?

If you want version control the way a developer means it — every committed state kept forever, line-level diffs, branches for risky work — the move is to mirror your posts to disk as plain .md files and put the folder under git. That’s exactly what the desktop and open-source edition is for, and version control for your Ghost blog with git walks through the commands. For recovering an earlier version of a single post either way, see how to undo a change to a Ghost post.