Publishing is the organizing idea
Ghost is built around the work of an independent publication. Writers create posts in its editor, staff manage a site in Ghost Admin, readers can become members, paid tiers connect through Stripe, and posts can be sent as newsletters. Themes render the hosted site, while the Content API lets a team build a separate frontend. The Admin API covers programmatic publishing and management.
This focus makes Ghost easier to reason about than a general CMS assembled from plug-ins. Membership records, newsletter preferences, subscription state, post delivery, and engagement data belong to the same application. The current database guide shows how much machinery sits underneath that simple interface: a newsletter send has separate email, batch, recipient, and failure records, while Stripe data is cached alongside Ghost's own subscription model.
The opinionated shape is also a limit. Ghost is good at sites whose main unit is published content and whose business model involves readers. A corporate portal with many custom record types, approval trees, and application screens may fit a headless content platform better. A marketing site built mostly from visual landing pages may benefit more from a page builder.
The product covers more than posts
Membership is native rather than an add-on. A publication can offer free, complimentary, and paid access, organize readers with labels and custom fields, and send to selected segments. Stripe handles paid subscriptions. Ghost charges no added payment-processing percentage, although Stripe's own fees still apply. Portal supplies the reader-facing account and checkout interface.
Newsletter delivery is tightly integrated with publishing, but provider choice is narrow. Transactional mail can use standard SMTP. Bulk newsletters use a provider API, and Ghost currently supports only Mailgun for that built-in path. The official FAQ says other newsletter services can still be used through integrations or member synchronization, but that means leaving Ghost's native delivery workflow. Teams with an existing SendGrid or Amazon SES contract should decide whether that split is acceptable before migrating readers.
Themes use Handlebars and a documented helper layer. Developers can also treat Ghost as a headless CMS and fetch published content through the Content API. This flexibility is useful when the editorial team wants Ghost Admin but the public site needs a custom framework. It also creates two systems to deploy and debug, so headless mode should solve a real design or integration need.
Self-hosting follows a narrow path
The supported Ghost-CLI production stack is specific: Ubuntu 22.04, 24.04, or 26.04 LTS, Node.js 22, MySQL 8.0 or 8.4, Nginx, systemd, at least 1 GB of memory, a domain, and a non-root user. DNS must point at the server before the installer can configure a Let's Encrypt certificate. The CLI then creates database access, Nginx configuration, SSL, and a systemd service through an interactive install.
That is a good installer for people who understand the parts it configures. It is not an escape from server administration. Someone still owns operating-system patches, Ghost updates, MySQL backups, certificate checks, mail reputation, storage, monitoring, and recovery drills. The hosting guide says clustering and sharding are unsupported. Scale should come from a CDN and cache in front of one Ghost application, which is a clear architecture but unsuitable for teams that require active-active application nodes.
Ghost 6 adds another split. The established CLI installation can use Ghost's hosted ActivityPub service within stated limits, but it does not support the new web analytics feature. Fully self-hosting ActivityPub or using self-hosted analytics requires the Docker Compose installation, which Ghost labels preview. That stack runs Ghost with Caddy and MySQL, and optional profiles add more services. Analytics also requires a Tinybird account and tokens, so it is not entirely contained on your server.
What happened when we ran it
We cloned commit 81292b0 into a fresh unprivileged node:22-bookworm container with three CPUs, 8 GB of RAM, and no secrets. The checkout contained 8,695 files, about 958,395 lines of source, and occupied 75.2 MB. It is a pnpm workspace monorepo with 21 CI workflow files, no root Dockerfile, and no top-level tests directory.
Installation succeeded in 131 seconds. It installed 4,162 packages and expanded to 1,712 MB on disk. The build then completed successfully in 68 seconds. The test command ran for 97 seconds and exited with status 1, even though Vitest's parsed result said all 276 tests passed and none failed.
The log tail did not name a failing assertion. It printed Nx task statistics, including cached tasks and a 54.2-second ghost:test critical path, then ended with [ELIFECYCLE] Test failed. See above for more details. We can say the overall command failed while the reported Vitest cases passed. We cannot infer the missing failure from those last lines, and we did not turn the contradiction into a guessed cause.
Current maintenance and product risk
The repository's last push was August 25, 2026. Release 6.59.0 shipped on August 19 with fixes for older MySQL migrations, theme navigation markup, newsletter filters, donation checkout translations, and header-card assets. GitHub listed 138 open issues and pull requests together; an issue-only search returned 31. Recent reports cover SQLite email analytics, mobile editor links, accessible labels in Portal, and a newsletter left pending after a crash before job scheduling.
That pace is healthy for a large application, while the open reports matter because Ghost spans money, email, content, and reader identity. Test upgrades against a copy of production data, retain exports and database backups, and check the changelog for migrations. The project documentation says public server releases include Admin and the server on a weekly schedule, so self-hosters need a regular update window.
Ghost is a strong publication system precisely because it says no to many general-CMS choices. Accept its supported stack and provider decisions, or use Ghost(Pro) to hand off most operations. If those constraints fight existing infrastructure, choose a system designed around your preferred database, mail provider, or scaling model.