Ghost: an MIT publishing platform whose self-hosted path runs through ghost-cli, Mailgun and a pnpm monorepo

Ghost(Pro) pays for the code you can run for free

Ghost is a publishing platform for websites, newsletters, memberships, subscriptions and paid content, released under the MIT license and copyrighted by the Ghost Foundation from 2013 to 2026. The repository opens with a pitch for Ghost(Pro), the managed service, before it shows a single install command. A Ghost(Pro) site launches in about two minutes and comes with a worldwide CDN, backups, security and maintenance handled for you, and 100% of that revenue goes to the Ghost Foundation to fund development of the project itself. That arrangement matters when you evaluate the self-hosted route: the open source code and the paid service are the same product, and the paid service is what keeps the open source side moving. Sponsors listed in the repository include DigitalOcean, Fastly, Tinybird and BairesDev.

ghost-cli has one command for a laptop and another for a server

The supported way to run your own instance is the Ghost CLI, installed globally from npm:

npm install ghost-cli -g

For a local copy, the `local` flag gets a site running in under a minute, with the details on docs.ghost.org/install/local/:

ghost install local

On a server, the plain command runs the full install, which includes automatic SSL setup through LetsEncrypt:

ghost install

The difference between the two is the whole production story. The local flag is for trying Ghost or building a theme on your own machine. The server install is the one that provisions certificates, and the production install guide linked next to it is written for Ubuntu (docs.ghost.org/install/ubuntu/). If your server runs something else, plan to read that guide closely before running the command, because it is the path the project points production users to.

Self-hosting moves backups, security and upgrades onto your desk

Everything Ghost(Pro) bundles becomes your responsibility the moment you run `ghost install` on your own machine. The CDN, the backups, the security work and the routine maintenance are listed as things the managed service does for you, which means a self-hosted site gets none of them by default. The project itself argues that for most people the managed service ends up being the better value because of how much time it saves, and it links a hosting page and a separate guide on properly upgrading Ghost. The consequence for a reader: a self-hosted Ghost site is cheap to start and expensive to neglect. Budget time for applying upgrades, for taking and testing backups, and for watching the server, or the cost comparison with Ghost(Pro) stops being honest. Support follows the same split. Everyone gets the community forum at forum.ghost.org, while 24/7 email support is reserved for Ghost(Pro) customers.

Newsletters depend on Mailgun, and EU domains need different endpoints

Bulk newsletter email and transactional email both go through Mailgun, and the development environment file shows exactly which settings that takes. MAILGUN_DOMAIN is the sending domain. MAILGUN_FROM is the from address for transactional mail and falls back to postmaster@MAILGUN_DOMAIN if you leave it empty. MAILGUN_API_KEY holds the key. Two URLs are configured separately: MAILGUN_API_URL, the origin for transactional email, defaults to https://api.mailgun.net, while MAILGUN_BASE_URL, the base for newsletter and bulk email, defaults to https://api.mailgun.net/v3. For an EU domain, the first becomes https://api.eu.mailgun.net and the second https://api.eu.mailgun.net/v3. The practical risk is that these are two variables with two different shapes, one with the /v3 path and one without. Changing only one of them for an EU account leaves the other pointed at the US endpoint, so transactional mail and newsletters can end up on different regions. If newsletters are the reason you chose Ghost, have a Mailgun account ready before launch.

The source tree is a pnpm and Nx monorepo named ghost-monorepo

Contributors do not work in a single package. The root package.json is named ghost-monorepo, marked private with the version string "private", and its scripts call Nx through pnpm. The build script is `pnpm nx run-many -t build`, archive runs `pnpm nx run ghost:archive`, and dev runs `nx run ghost-monorepo:dev:host`. The top level holds apps/, ghost/, koenig/, packages/ and e2e/, plus nx.json, pnpm-workspace.yaml, pnpm-lock.yaml, a .nvmrc and .node-version to pin Node, and a Dockerfile.production. The repository also carries configuration for coding agents: AGENTS.md, CONTEXT-MAP.md and folders for .claude, .codex, .cursor and .agents. Newcomers are pointed to the contributing guide in .github/CONTRIBUTING.md and to docs/README.md for how the monorepo fits together. The cost for a casual contributor is real: you need pnpm, Nx and Docker in your toolchain before you can change a line and see it run.

Optional services attach through compose.dev overlay files

Each external service in development has its own Docker Compose file, and the dev scripts layer them in through the DEV_COMPOSE_FILES variable. `pnpm dev:mailgun` adds compose.dev.mailgun.yaml, dev:fake-mailgun swaps in a fake mail service, dev:fake-upgrades adds compose.dev.fake-upgrades.yaml, dev:storage adds storage, and dev:jobs-redis adds a Redis-backed jobs service. dev:analytics adds compose.dev.analytics.yaml and sets ANALYTICS_PROXY_TARGET=127.0.0.1:7182. dev:full combines analytics and storage and wraps the run in docker/stripe/with-stripe.sh. dev:lexical sets GHOST_DEV_KOENIG_WATCH=1 for work on the Koenig editor, and dev:docker binds to 0.0.0.0 through GHOST_DEV_LISTEN. Settings for these live in a local .env file, created from the template:

cp .env.example .env

Compose profiles such as COMPOSE_PROFILES=stripe switch services on, and you can list what exists with:

docker compose config --profiles

Stripe webhook forwarding needs STRIPE_SECRET_KEY, STRIPE_PUBLISHABLE_KEY and STRIPE_ACCOUNT_ID, all test keys in the template.

The code is MIT, but the Ghost name and logo are not

The MIT license covers the code, so you can fork it, modify it and run it commercially. The name is a different matter. Ghost and the Ghost logo are trademarks of Ghost Foundation Ltd, and acceptable use is governed by a separate trademark policy at ghost.org/trademark/. The consequence for anyone building a hosted service or a rebranded distribution on top of this repository is that the license does not settle the branding question. You can ship the software, but calling your product Ghost or reusing the logo needs to clear the trademark policy first. Agencies hosting client sites and companies selling a Ghost-based offering should read that policy before they name anything.

Minor releases land about a week apart on the 6.x line

The project is under active development. The last push to the main branch was on 2 November 2026, and the three most recent releases arrived close together: v6.71.0 on 15 October 2026, v6.72.0 on 20 October 2026 and v6.73.0 on 27 October 2026. For a self-hosted operator, that cadence is a scheduling question rather than a quality signal. A site that skips upgrades for a couple of months falls several minor versions behind, and the guide on properly upgrading Ghost on docs.ghost.org is where the project sends you to catch up. Release notes and product news go out through the changelog newsletter at ghost.org/changelog/, which is the simplest way to know when a new version is waiting.

Editorial conclusion

Ghost suits publishers who want newsletters, memberships and paid content in one MIT licensed codebase, and who are ready either to pay for Ghost(Pro) or to run the server, SSL, backups and upgrades themselves. Teams that only want a static blog or cannot operate a Mailgun account for bulk email should look elsewhere. Before committing, read the production install and upgrade guides on docs.ghost.org, confirm your Mailgun region, and check the trademark policy if you plan to rebrand a fork.

Frequently asked questions

Official sources

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