Infrastructure guide
Self-Hosted Ghost: Choose the Supported Stack, Not the Cheapest VPS
Choose Ghost(Pro), the supported Ubuntu CLI stack, or Ghost 6 Compose services by ownership, recovery, mail, and publishing needs.
Published and reviewed by OpenAlt · October 1, 2026
Verdict: choose Ghost(Pro) when your scarce resource is publishing time, not server administration. Choose supported Ubuntu CLI when you want host-level control and can own updates, mail, TLS, backups, and recovery. Consider Ghost 6 Compose services when that direction fits your operating model; the cheapest VPS is only cheap until publishing turns you into the operator. Ghost’s hosting guidance recommends Ghost(Pro) for most publishers. Ghost hosting documentation
Table of Contents
- Choose Ghost(Pro) if publishing matters more than Linux operations
- Two current paths: supported CLI stack and newer Compose services
- Preflight domain, email, Ubuntu/MySQL, resources, TLS and maintenance
- Use the official path, not a stale random Compose file
- Canonical URL, transactional/bulk mail, members and payments
- One recovery set for content, DB, images, themes, routes, redirects and config
- Stage updates and verify publication, admin, newsletters and members
- Decision worksheet: control, features, on-call cost and exit plan
- FAQ
Choose Ghost(Pro) if publishing matters more than Linux operations
Choose Ghost(Pro) when publishing time matters more than Linux operations. Ghost recommends Ghost(Pro) for most publishers; self-hosting makes sense when you specifically need host-level control and accept responsibility for updates, mail, TLS, backups, and recovery.
If your desired work is “publish, edit, send, and grow,” managed hosting is usually the cleaner choice. If you also want to operate Linux, maintain a database, and plan restores, self-hosting may be justified. The real cost is interruption to editorial work, not the monthly VPS bill.
Two current paths: supported CLI stack and newer Compose services
Choose the documented Ubuntu CLI stack for a conventional production server; consider Ghost 6 Compose services when your team already operates containers, persistent storage, service boundaries, and coordinated updates. The supported stack specifies Ubuntu 24, Node 22, MySQL 8, NGINX, systemd, and 1 GB of RAM. Ghost hosting documentation
The CLI route fits teams comfortable with Ubuntu services, system packages, NGINX, and systemd. Compose may suit service-oriented operations, but volumes, networking, upgrades, and recovery remain your responsibility. Do not select either route solely because its first command is short.
Preflight domain, email, Ubuntu/MySQL, resources, TLS and maintenance
Before deployment, confirm the canonical domain, mail design, supported versions, resources, TLS ownership, and maintenance owner. Ghost identifies URL, database, and mail configuration as required areas. Ghost configuration documentation
- Domain: Decide the exact public URL before publication.
- Email: Assign transactional messages, bulk newsletters, sending ownership, and delivery monitoring.
- Ubuntu and MySQL: For the CLI route, align with Ubuntu 24, Node 22, and MySQL 8.
- Resources: Treat 1 GB of RAM as the documented baseline, leaving room for the OS, database, backups, and maintenance.
- TLS: Plan certificate issuance, renewal, monitoring, and recovery.
- Maintenance: Assign updates, logs, storage growth, mail settings, and restore decisions.
This exposes ownership gaps before the site is difficult to change.
Use the official path, not a stale random Compose file
Use Ghost’s current hosting guidance and repository documentation for installation and updates. A random Compose file may start containers while leaving versions, storage, mail, updates, or recovery unsuitable. Ghost’s GitHub repository documents production installation and update commands.
Keep the deployment definition reviewable and dated. Record Ghost and package versions, database settings, persistent storage, proxy configuration, and the update procedure. Before launch, answer five questions:
- Where does persistent data live?
- How is the public URL configured?
- How are mail settings supplied?
- How is the service updated?
- How is the publication restored?
Canonical URL, transactional/bulk mail, members and payments
Set the canonical URL and database deliberately, then test mail, members, and payments separately. Ghost’s documentation identifies URL, database, and mail settings as required areas. Ghost configuration documentation
Write down the public URL exactly as it should appear in links, feeds, and shared pages. Confirm the database is the intended persistent instance. Separate site-generated transactional messages from newsletter delivery, and verify sender identity, replies, ownership, and monitoring.
If members or payments matter, test sign-up, confirmation, login, subscription, cancellation, and receipt or failure handling. A running application does not prove that reader-facing workflows are complete.
One recovery set for content, DB, images, themes, routes, redirects and config
Build one coherent recovery set containing content, the database, images, themes, routes, redirects, and configuration. Ghost’s manual-backup guidance covers backup and export scope including routes, redirects, and content. Ghost manual backup guidance
- Content: Keep the documented export or backup.
- Database: Maintain a consistent backup matching the content state.
- Images: Preserve uploaded media separately.
- Themes: Store the active theme and version.
- Routes and redirects: Preserve both as part of URL continuity.
- Configuration: Record URL, database, mail, proxy behavior, and required secrets securely.
- Recovery notes: Document each location, restore method, and responsible person.
Use the OpenAlt backup storage calculator when estimating storage. A backup that cannot be located, matched, or restored is incomplete.
Stage updates and verify publication, admin, newsletters and members
Stage every update before production. Use a representative environment, follow the documented route, and verify public pages, administration, newsletters, and member journeys afterward. Ghost’s GitHub repository
- Record the current version and confirm a fresh recovery set.
- Apply the update in staging or a disposable environment.
- Check the homepage, a post, navigation, images, and admin login.
- Check newsletter composition or delivery.
- Check member sign-up, login, subscription, and payment paths.
- Apply the change during a defined production maintenance window.
- Repeat verification and record the result.
If the update cannot be reversed or restored clearly, improve the recovery plan first.
Decision worksheet: control, features, on-call cost and exit plan
Choose the ownership model you can sustain during a busy publishing period. Ghost(Pro) minimizes host operations; supported CLI maximizes alignment with the documented stack; Compose offers service-oriented control but demands stronger operational ownership.
| Option | Control | Feature posture | On-call cost | Exit plan |
|---|---|---|---|---|
| Ghost(Pro) | Lower host control | Use the managed offering | Lowest operational burden | Preserve exports and domain decisions |
| Supported CLI | High host control | Align with the supported stack | Own server, mail, TLS, backups, updates | Preserve recovery set and configuration |
| Compose direction | High deployment control | Evaluate against Ghost 6 direction | Own orchestration and persistence | Preserve service data, volumes, and config |
Review OpenAlt’s Ghost resources and broader blog CMS coverage. If deployment friction is the priority, compare the one-click self-hosting option. First choose the ownership model, then the route.
FAQ
The right answer depends less on whether a server can run Ghost than on whether your team can operate its dependencies.
Is Ghost(Pro) the safest choice for an independent publisher?
Usually, yes, when publishing matters more than Linux operations. Ghost recommends Ghost(Pro) for most publishers. Choose it when you lack a specific host-control requirement or a team prepared to own updates, mail, TLS, backups, and recovery.
Should I choose the supported CLI stack or Ghost docker compose?
Choose the supported CLI stack for the documented Ubuntu production route. Consider Ghost 6 Compose services when your team can operate services, persistent storage, and coordinated updates. Select the model you can restore and maintain.
What should a Ghost backup contain?
Ghost’s manual-backup guidance covers content, routes, and redirects. A practical recovery set should also preserve the database, images, themes, and configuration, with documented locations and restore instructions.
What should I verify after an update?
Verify the public publication, administration, images, mail or newsletter workflow, and relevant member paths. Stage first, confirm a fresh recovery set, follow the documented update route, and record production verification.