# Ghost is MIT for the code and trademarked for the name, logo and support tier

> A JavaScript publishing platform for sites, newsletters, memberships and paid subscriptions, installed through a global CLI. The code is MIT but the name and logo are trademarks, local development is a matrix of eight compose overlays, and v6.67.0 was published seven minutes before v6.66.0.

**TryGhost/Ghost** — Ghost is a publishing platform for websites, newsletters, memberships, subscriptions, and paid content.

- Repository: https://github.com/TryGhost/Ghost
- Website: https://ghost.org
- Stars: 55,444 · Forks: 11,990
- Language: JavaScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/tryghost-ghost

## MIT covers the code, and a trademark policy covers the name

The licence section is two paragraphs and they say different things. The first is the ordinary one: copyright from 2013 to 2026, held by the Ghost Foundation, released under the MIT licence. The second says the name Ghost and the Ghost logo are trademarks of a separate company, Ghost Foundation Ltd, and points at a trademark policy for acceptable usage. The distinction matters more here than in most projects, because Ghost is a product people self-host and then rename. Under MIT you may read, modify, self-host and redistribute the code without asking anyone. What you may not do, without checking that policy, is ship your fork under the Ghost name or keep the logo. The consequence is that a fork is straightforward and a rebrand is a legal question, and the repository does not summarise where that line sits, so the policy document is the thing to read before a launch rather than after one.

## v6.67.0 was published seven minutes before v6.66.0

The three most recent releases are worth reading as timestamps rather than as a list. v6.65.0 went out on 2026-09-22. Then on 2026-09-29, v6.67.0 was published at 17:23:19 and v6.66.0 at 17:30:21, so the higher version number carries the earlier publication time by seven minutes. That is a small thing and it has one very concrete consequence. Any automation that picks the newest build by date rather than by version will install 6.66.0 over 6.67.0, and any dashboard that sorts releases by recency will show the wrong one at the top. The cause is almost certainly a backfill or a re-publish rather than a mistake, since the numbering is monotonic and the contents are presumably fine. The lesson for a self-hoster is simply to pin an explicit version string and never resolve latest from a release feed.

## Local development is eight compose overlays, so the database is a choice

There is no single development environment, and the package manifest is where you find that out. The dev script delegates to a task, and a variable called DEV_COMPOSE_FILES selects which compose files get layered in. The tree carries compose.dev.yaml plus overlays for sqlite, mailgun, fake-mailgun, orb, storage, stripe-tunnel and analytics, with named scripts for several of them, including a combined one that layers analytics and storage together and runs through a Stripe helper script. Two consequences follow. First, getting a working local stack is a decision about which overlay rather than a single command, and the failure mode is quiet: the wrong overlay changes your database engine, your mail transport or your storage backend without telling you why a feature misbehaves. Second, since SQLite is one option among several, the database you develop against is not necessarily the one you will run in production.

## Payments and email are stubbed locally, and the fake overlay can pass falsely

Look at the environment template and you can see exactly which parts of the product are hard to exercise locally. Stripe needs a secret key, a publishable key and an account id, and the comment states they are used to forward Stripe webhooks to Ghost, which is the mechanism behind memberships and paid subscriptions. Mailgun needs a sending domain, a from address, an API key, and two separate base URLs, with explicit notes to use the EU endpoints for EU domains, one for transactional mail and a different one with a version path for newsletter and bulk mail. On top of that there is a dedicated fake-mailgun overlay and a stripe-tunnel overlay. The consequence is that the paid half of Ghost cannot be tested end to end without either real credentials or a stub, and a developer validating the subscription flow against the fake transport can get a green result that tells you nothing about production behaviour.

## The self-host route is documented and deliberately positioned second

The README leads with the managed service rather than with the software. It calls the hosted offering the easiest way to get a production instance deployed, says it takes about two minutes to launch a site with CDN, backups, security and maintenance handled, argues it is the best value because of the time saved, and states that all revenue goes to the Ghost Foundation funding maintenance and development. Self-hosting gets its own section further down, and the sequence is deliberate.

```bash
npm install ghost-cli -g
```

Then a local flag for a sub-minute setup, or the full install on a server with automatic certificate setup.

```bash
ghost install local
```

The consequence is not that self-hosting is second class, it is that support is. The help section says everyone gets the community forum, and that hosted customers get 24 hour email support. So a self-hoster has chosen the path that saves money and inherits the path that stops at a forum, which is a reasonable trade and should be made knowingly.

## The root manifest is private and versioned 0.0.0, so it is not what you install

The package manifest at the root is named for the monorepo, marked private, and carries the version string 0.0.0-private. The description is a sentence about being a professional publishing platform, the author is the foundation, and the licence field says MIT. Everything about that file says this is a workspace, not a distributable artifact. The build scripts confirm it: production builds are expressed as a sequence of named tasks across packages and apps, clean steps reset the task runner and delete build output, and the dev variants all layer compose files before delegating. The consequence is practical and it trips people up. You cannot read a version out of this repository and learn what you have installed, because the repository has no version. The version you care about is the one on the published CLI or in your running image, which is a separate thing to go and look up.

## Five agent config directories and a context map sit in the tree

The top level is crowded with tooling, and a slice of it is aimed at automated contributors rather than at the product. There are configuration directories for at least five different agent harnesses, an agent instructions file, a context map, a skills lock file, and a configuration for an automated code reviewer. Alongside those sit a dependency boundary checker, an unused-export configuration, a secret linter, a markdown linter, a formatter configuration, a lint-staged configuration and a Sonar project properties file, which tells you the review surface is broad and mostly automated. The consequence for a contributor is one of uncertainty rather than burden. The tree tells you these tools exist and are configured, but nothing in the visible material says which of them actually gate a merge and which are advisory, so before you rely on any single check passing you need to find out which ones a pull request is actually measured against.

## Conclusion

Adopt Ghost when you want a publishing platform where the newsletter, the membership and the paid tier are first-class rather than bolted on, and read the trademark policy before you plan to rebrand anything. Do not adopt it expecting a self-host story with the same support as the hosted one, because the README steers you to the managed service and 24 hour email support is a paid feature while self-hosters get a forum. Three things to check before you start. Decide which compose overlay matches your intended database and mail transport, because local development is eight of them and the wrong one changes what you are testing. Expect to stub payments and email locally. And pin by version number rather than by release date, because the two most recent tags are out of order by seven minutes.

## FAQ

### What is the Ghost publishing platform?

It is a publishing platform for websites, newsletters, memberships, subscriptions and paid content, written in JavaScript and released under the MIT licence. The project is hosted at ghost.org, is copyright from 2013 to 2026 by the Ghost Foundation, and is also offered as a managed hosting service.

### How do you install Ghost?

Through a global CLI, installed with npm install ghost-cli -g. From there, ghost install local gives a sub-minute local setup, while a plain ghost install does the full server install including automatic certificate setup. There is also a managed hosted option that the README presents as the fastest route to a production instance.

### Can I rebrand Ghost under my own name?

The code is MIT, so you may modify, self-host and redistribute it. The name Ghost and the Ghost logo are separate trademarks of Ghost Foundation Ltd, with acceptable usage set out in a trademark policy, so keeping the name or the logo in a fork is a question for that document rather than the licence.

### What database and email services does Ghost use?

Local development selects a compose overlay, and the tree includes separate ones for SQLite, Mailgun, storage, analytics, Orb and a Stripe tunnel, so the database and mail transport are a choice rather than a default. Mailgun needs a sending domain, an API key and separate base URLs, with European endpoints specified for EU domains.

## Sources

- [Official documentation](https://ghost.org)
- [Official README](https://github.com/TryGhost/Ghost#readme)
- [Project repository](https://github.com/TryGhost/Ghost)
- [Release notes](https://github.com/TryGhost/Ghost/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tryghost-ghost