Ghost: self-hosted publishing for newsletters, memberships and paid content

What Ghost actually replaces

Ghost bundles four things that are usually four separate products: a public website, a newsletter sending system, member accounts with signup and login, and paid subscriptions with billing. The README describes it as "a publishing platform for websites, newsletters, memberships, subscriptions, and paid content," and the repository backs that up with a Stripe integration directory (docker/stripe/) and Mailgun compose files for development mail.

The audience is narrower than "anyone with a blog." It is for a publisher who wants the subscriber email list to live in their own database rather than in a third-party newsletter service, and who wants the payment relationship to run through their own Stripe account. If your content is a marketing site for a product, or a documentation set, Ghost's membership machinery is dead weight you will still have to upgrade.

The MIT license matters here. The core is permissively licensed, so you can read and modify the source. The trademark is separate: the README points to a trademark policy for acceptable usage of the Ghost name and logo, which is the usual arrangement and worth reading before you brand a fork.

The monorepo shape and what runs where

The repository is a pnpm workspace driven by Nx, not a single application. The top level holds apps/, packages/, ghost/, koenig/ (the editor), configs/, docker/ and e2e/. The root package.json is named ghost-monorepo and is marked private, so you do not install this repository as a dependency; you either run it from source or install a released version through the CLI.

That split explains the two audiences in the README. Most operators never touch the monorepo. They install ghost-cli and let it fetch and manage a release. Contributors work inside the workspace, where the build is orchestrated by Nx targets: build:production runs the TypeScript build, the asset build and the admin client build in sequence.

Development is container-first. The dev script delegates to a docker:dev target, and the compose files at the root layer optional services: compose.dev.sqlite.yaml for a SQLite database, compose.dev.mailgun.yaml and compose.dev.fake-mailgun.yaml for mail, compose.dev.storage.yaml, compose.dev.analytics.yaml, and compose.dev.stripe-tunnel.yaml with docker/stripe/with-stripe.sh for webhook forwarding. The .env.example file exists to be copied to .env and edited, and it documents the Stripe keys and Mailgun credentials those profiles consume. That layering is a real convenience for contributors and irrelevant to someone running a production site.

Installing Ghost with ghost-cli

The README gives one install path for self-hosting: the CLI tool, installed globally with npm. The local flag is described as getting you running in under a minute, and it is the right first step because it avoids the server, SSL and mail questions until you have seen the product.

npm install ghost-cli -g

Then, for a local instance:

ghost install local

The README states this uses the local flag and links to the local install docs. What you should expect is a Ghost instance you can reach in a browser and an admin account created during setup; the exact printed URL is in the CLI output, not in the README.

For a server, the same CLI runs the full install, which the README says includes automatic SSL setup using LetsEncrypt:

ghost install

That is the whole documented surface. The README does not document rollback, backup, or what happens if the SSL step fails partway; it defers to the update and hosting documentation. Before running the server install, read those pages, because the CLI assumes a specific host layout.

Where self-hosting gets expensive

The README is unusually direct that the managed service is the recommended path for most people: "The easiest way to get a production instance deployed is with our official Ghost(Pro) managed service." It frames the trade as time saved, and notes that revenue goes to the Ghost Foundation, which funds development.

Read that as a statement about operational cost, not marketing. A self-hosted Ghost needs a Node.js runtime, a database, a reverse proxy, TLS certificates, and an email path for member signups and newsletters. The repository gives you development compose files for Mailgun, but the README does not document a built-in transactional mail provider. If your server cannot send mail, member signup confirmation and password reset are the first things that break, and they break quietly.

The second cost is upgrade cadence. Releases are frequent: v6.59.0 on 2026-08-19, v6.60.0 on 2026-08-25, and v6.61.0 on 2026-08-27. That is three minor releases in eight days. The project is maintained, and the last push was on 2026-08-27. Frequent minor releases are normal for this codebase, but they mean you need a repeatable upgrade procedure rather than a one-time install. The README points to the update documentation for this and does not describe the procedure itself.

Ghost is the wrong tool when your content is static and rarely changes, when you have no interest in memberships or email, or when you need a CMS your non-technical editors can extend without touching a theme. A static site generator plus a hosted newsletter tool is less to operate, even if it is more vendors.

Ghost compared with WordPress and static site generators

WordPress is the obvious alternative, and the difference is architectural rather than cosmetic. WordPress is a PHP application with a plugin ecosystem that extends the core in-process; Ghost is a Node.js application in a pnpm monorepo, where the editor (koenig/) and the admin client are separate build targets. In practice, WordPress gives you a much larger pool of third-party plugins and themes, including ones that will happily modify your database. Ghost gives you a smaller, curated surface, and the membership and newsletter features are in the core rather than bolted on.

The other alternative is a static site generator such as Hugo or Eleventy paired with a hosted newsletter service. That combination is cheaper to host and has no upgrade treadmill, because there is no server-side application and no database. What you give up is exactly what Ghost sells: member accounts, gated content and subscription billing in the same system as the site. If you never intend to charge for content, the static route is the more honest choice.

A fair summary of the trade: Ghost sits between the two. It is more opinionated than WordPress and less operationally inert than a static site.

Licence and what a fork can and cannot do

The code is MIT, per the LICENSE file and the package.json license field. That permits commercial use, modification and redistribution, provided the copyright notice and permission notice are retained. It is not legal advice, and the practical questions are the ones the licence does not answer.

The trademark is the constraint. The README states that Ghost and the Ghost Logo are trademarks of Ghost Foundation Ltd and links to a trademark policy covering acceptable usage. If you fork, strip the branding rather than argue about it. The README also notes that the project is a Digital Public Good, which is a designation rather than a licence term and does not change your obligations.

One consequence of the monorepo layout worth knowing: because the root package.json is private and the workspace is not published as a single package, a fork is a fork of the whole tree, not a drop-in library substitution. You inherit the Nx build, the workspace tooling and the release cadence along with the source.

Development setup for contributors

If you intend to work on Ghost itself rather than run it, the README routes you to the contributing guide and the codebase documentation in docs/README.md. The development loop is Docker-based, and the environment file is meant to be copied before editing:

cp .env.example .env
pnpm dev

The .env.example comments state that .env is where you set the compose profiles and credentials, and that you can list available profiles with docker compose config --profiles. The Stripe variables it documents are STRIPE_SECRET_KEY, STRIPE_PUBLISHABLE_KEY and STRIPE_ACCOUNT_ID, all commented out by default. The Mailgun variables are MAILGUN_DOMAIN, MAILGUN_FROM, MAILGUN_API_KEY, MAILGUN_API_URL and MAILGUN_BASE_URL, with the file noting that EU domains use https://api.eu.mailgun.net variants.

There are narrower entry points too: pnpm dev:sqlite swaps in the SQLite compose file, pnpm dev:mailgun and pnpm dev:fake-mailgun cover mail, and pnpm dev:analytics and pnpm dev:storage add those services. The README does not document what the fake-mailgun profile does beyond its name, so read the compose file if that distinction matters to your work.

Editorial conclusion

Adopt Ghost if you are publishing regularly and want the website, the newsletter list and paid subscriptions in one system you control, and you are willing to run Node.js and a database. Do not adopt it if you only need static pages, or if nobody on the team wants to own upgrades. Before committing, verify three things: that your host matches the recommended stack in the install docs, that your mail sending is configured (the repository ships Mailgun compose files, and the README does not document a built-in SMTP fallback), and that your theme works on your current release, because upgrades are versioned and released frequently. The 6.61.0 release on 2026-08-27 is the version to read the changelog for first.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes