TryGhost/Casper: the Ghost theme that stopped being the default

What Casper is for, and who should pick it

Casper is a theme, not a publishing platform. It supplies the templates, styles and partials that Ghost renders your content through. The README states it was originally the default theme and that Ghost's default is now Source, so Casper's role has changed from the thing everyone gets to a maintained alternative you choose deliberately.

The audience is narrow and specific. If you run a Ghost site and want a conventional blog or magazine structure (a post list on the home page, individual post pages, tag archives, author archives), Casper already defines all of those. The package.json categorises it under "Minimal" and "Magazine". If you want a storefront, a documentation site or a highly custom landing page, the templates here do not attempt that.

One constraint decides most adoption questions before anything else: package.json declares engines.ghost as >=5.0.0 and engines.node as >=22.12.0. On an older Ghost install, this theme is not the right file to upload.

The template files that actually drive the site

Casper is built on Handlebars. The README lists the main files and what each one renders: default.hbs is the parent template holding the global header and footer, index.hbs generates the post list, post.hbs renders a single post, page.hbs handles individual pages, tag.hbs covers tag archives and author.hbs covers author archives.

The mechanism worth understanding is the slug-based override. According to the README, you can create one-off templates by putting a page or tag slug into the filename. A file named page-about.hbs becomes the template for an /about/ page; tag-news.hbs becomes the template for the /tag/news/ archive; author-ali.hbs becomes the template for /author/ali/. That is the whole customisation model at the template level: you add files whose names match the content they render, and Ghost picks them up.

Icons follow the same partial-based pattern. The README says Casper uses inline SVG icons stored in /partials/icons and included through Handlebars partials, so a file at /partials/icons/rss.hbs is pulled in with {{> "icons/rss"}}. Adding an icon means adding a file in that directory and referencing it the same way.

This design is legible but it is not configurable. There is no settings panel described anywhere in the README. If you want to change what the home page shows, you edit index.hbs.

Installing Casper and running the dev build

The README points people who only want a released version to the GitHub releases page rather than the repository's main branch, which it describes as the latest development version. That distinction matters: cloning main gives you unreleased template changes.

For local development, the README requires Node, pnpm and Gulp installed globally. From the theme's root directory you install dependencies and start the development server:

# install dependencies
pnpm install

# run development server
pnpm dev

After that, edits to files under /assets/css/ are compiled automatically into /assets/built/, which is where the rendered stylesheet lives.

To produce something you can upload to a site, the README documents a zip task that packages the theme into dist/<theme-name>.zip:

# create .zip file
pnpm zip

That archive is the artefact you install through Ghost's theme upload. The README does not describe an alternative installation path, so the zip is the route it documents.

Two PostCSS features are called out: Autoprefixer, which the README says handles browser prefixes automatically with support for the latest two major versions of every browser, and Color Mod. If you write CSS expecting prefixes to be added by hand, you are working against the build.

Version bumps, shipping, and the pnpm migration trap

Casper's release process is scripted rather than manual, and the README flags a change that will catch anyone following older instructions. Releases ship in two steps. First you bump the version, which updates package.json and creates the matching commit and v<version> git tag:

# pick one of: patch | minor | major (or an explicit version, e.g. 5.13.0)
pnpm version minor

Then you run ship, which the README says checks the working tree is clean, pushes the commit and tag, and drafts the GitHub release from the changelog:

pnpm ship

The README adds a note that pnpm version must be run first, because unlike the old yarn version, pnpm version is not interactive and pnpm ship no longer performs the bump itself. Anyone porting a fork from the yarn era will find that ship alone no longer produces a release. The ship script itself exits with an error if git status --porcelain returns anything, so a dirty tree stops the push rather than shipping a partial release.

The test path is also wired into the release: preship runs pnpm test, and test runs gscan against the theme. The test:ci variant runs gscan with --fatal and --verbose, and both test scripts have a pretest step that runs pnpm zip first. Gscan is Ghost's theme validator, so a failing scan blocks the release before the tag is pushed.

Where Casper is the wrong choice

The clearest limitation is that Casper is a theme for Ghost and nothing else. The templates assume Ghost's Handlebars helpers and content model. If your site runs on another static site generator or CMS, none of this transfers, and the CSS is only useful if you rebuild the markup around it.

The second limitation is customisation depth. Because there is no settings layer described in the README, every change beyond content is a source edit. That means your modifications diverge from upstream, and the next release (the repository shows v5.12.5 published on 2026-09-21, with v5.12.4 and v5.12.3 before it) has to be reconciled against your fork. A site owner who wants to tweak layout without touching Handlebars will find Casper the wrong tool.

The third is the version floor. With engines.ghost set to >=5.0.0, Casper is not a drop-in for older Ghost installations, and the README does not document a supported path for those.

Finally, the README is a developer document. It explains how to compile, package and release the theme. It does not document rollback, and it does not walk through what a non-developer sees when they upload the zip and something looks wrong.

Casper against Source, and against building your own theme

The obvious alternative is Source, which the README names as Ghost's current default theme. The difference is not just visual. Source is the theme Ghost ships by default, so it is the one that receives the default-theme treatment: it is what a fresh Ghost install gives you, and it is the baseline that platform changes are tested against first. Casper now sits in the position of a maintained classic, which the README acknowledges by describing it as a classic theme that was originally the default.

If you are starting a new Ghost site and have no attachment to Casper's layout, choosing Source means you are on the path the platform itself defaults to. Choosing Casper means you are opting into a specific look and a specific template structure, and you accept maintaining that choice across releases.

The other alternative is writing your own theme. Ghost themes are Handlebars plus the theme API, and the README links to the full theme API documentation. Casper's value in that comparison is that it is a working reference: the README notes the theme has lots of code comments intended to explain what is going on just by reading the code. If you are learning Ghost theming, reading Casper is a reasonable starting point even if you do not ship it.

Licence, maintenance and what upgrading costs you

Casper is released under the MIT licence, with copyright held by the Ghost Foundation from 2013 to 2026. MIT is permissive: it allows modification and redistribution provided the licence and copyright notice are preserved. That is a statement about the licence text, not legal advice about your situation.

The practical consequence of MIT here is that forking is permitted, which is exactly what makes the customisation model workable. You can edit the templates, keep your changes in your own repository, and still pull from upstream. The cost is that you own the merge. Nothing in the repository automates reconciling a fork with a new release.

On maintenance, the last push recorded for the repository is 2026-09-26, and the most recent release is v5.12.5 from 2026-09-21. The repository is not archived. The release cadence visible in the facts is a patch-level stream, which suggests fixes and small changes rather than structural rework; the version bumps in the README's release instructions are patch, minor or major.

Upgrade cost is dominated by the build toolchain rather than the templates. The package.json pins packageManager to [email protected] and requires Node >=22.12.0, so an environment running an older Node or expecting yarn will need to move before pnpm install or pnpm dev will behave as documented. Translations are handled outside this repository: the README directs readers to the theme-translations package under TryGhost/Themes for building, editing or contributing translations, so locale work is not something you do by editing files in locales/ alone.

Editorial conclusion

Adopt Casper if you run Ghost 5 or newer, want the classic blog and magazine layout, and are comfortable editing .hbs templates rather than configuring a settings panel. Do not adopt it if you need a visual builder, or if you are on a Ghost release older than 5.0.0, because package.json declares engines.ghost as >=5.0.0. Before you commit, run pnpm test, which invokes gscan, and confirm the theme passes for your Ghost version; then check whether the layouts in index.hbs and post.hbs match the structure of your existing content.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TryGhost/Casper on GitHub