When self-hosted Ghost fits better than Ghost(Pro)
Ghost(Pro) suits a publisher or media team that wants Ghost running without owning servers, patching the operating system or managing a database. Self-hosted Ghost suits a team that needs control over where the platform and member data sit and is ready to run the stack itself. Ghost(Pro) plans are priced by staff users and members: the Starter plan lists $18 per month for 1 staff user and 1,000 members, Publisher lists $29 per month for 3 staff users, and Business lists $199 per month for 15 staff users, billed yearly, with custom plans beyond that. A team whose audience is growing should model member counts against those tiers before deciding.
Choose Ghost(Pro) when the publication's main needs are memberships, paid subscriptions and newsletters, which Ghost lists as built in, and when the editorial team has no one to own uptime, backups and upgrades. Ghost(Pro) also fits a team that wants the vendor's migration team to help with a large WordPress move, though the migration docs note that custom post types, most uncommon shortcodes and content-restriction plugins do not migrate, so confirm that scope before signing.
Choose self-hosted Ghost when hosting location, data residency or network placement is a requirement, or when you already run Ubuntu, MySQL and NGINX as a standard service. The Ubuntu install through Ghost-CLI needs Ubuntu 22.04, 24.04 or 26.04, a supported Node.js version, MySQL 8.0 or 8.4, NGINX 1.9.5 or later, systemd and at least 1 GB of RAM. Web analytics is the decisive check: Ghost's Ubuntu guide says Ghost-CLI installs do not support web analytics, so a team that needs analytics must plan for the separate Docker Compose install, which Ghost documents for web analytics and the ActivityPub service. Confirm that choice with your own traffic and reporting requirements before you commit to an install path.
How Ghost(Pro) and self-hosted Ghost compare on each factor
This table compares Ghost(Pro) and self-hosted Ghost across licensing, pricing, built-in publishing features, fees, analytics, database, proxy, email and upgrades. Rows that depend on the Ghost-CLI or Docker Compose install are marked, so you can see which self-hosted choices change the result. Confirm current Ghost(Pro) feature availability on the pricing page before you decide.
| Factor | Ghost(Pro) | Self-hosted Ghost |
|---|---|---|
| License | Ghost(Pro) is a hosted service. The Ghost code is MIT-licensed and you do not install or operate it yourself. | The Ghost code is MIT-licensed, so you can run, modify and host it in your own infrastructure. |
| Pricing model | Starter at $18 per month (1 staff user, 1,000 members), Publisher at $29 per month (3 staff users) and Business at $199 per month (15 staff users), billed yearly, plus custom plans. | No Ghost(Pro) subscription. You pay for the server, database, email delivery and any services you choose, and for staff time to run them. |
| Memberships, paid subscriptions and newsletters | Built in without extra plugins. Confirm the included features for your plan on the pricing page. | Built in to the Ghost codebase. Confirm that your installed version and any email configuration support your newsletter volume. |
| Transaction fees | Ghost takes no transaction fee on paid subscriptions. Stripe processing fees still apply. | Ghost takes no transaction fee on paid subscriptions. Stripe processing fees still apply. |
| Web analytics | Confirm current availability on the pricing page for your plan. | Ghost-CLI installs do not support web analytics. Use the separate Docker Compose install if you need it. |
| Database | Managed by Ghost(Pro). You do not choose or operate the database. | MySQL 8.0 or 8.4 on Ubuntu installs through Ghost-CLI. You back up, patch and tune it yourself. |
| Reverse proxy and TLS | Managed by Ghost(Pro). You do not configure NGINX or certificates. | Ubuntu installs need NGINX 1.9.5 or later with systemd. Docker Compose installs change how the proxy is set up, so confirm the setup for your chosen method. |
| Email delivery | Included in the hosted service. Confirm sending limits and deliverability terms in your plan. | You configure an SMTP or transactional email provider and manage sender reputation, DNS records and bounce handling. |
| Upgrade handling | Ghost(Pro) applies platform updates for you. Confirm the change process and any downtime with Ghost. | You run Ghost-CLI updates and check Node.js support, database and proxy changes before each upgrade. Plan rollback and backups first. |
What your team runs in each hosting model
This table lists the recurring tasks that keep Ghost running and shows who performs each one under Ghost(Pro) and under self-hosted Ghost. Read it as a responsibility map: every row you own in the self-hosted column is work your team must staff, schedule and skill up for.
| Recurring task | Ghost(Pro) | Self-hosted Ghost |
|---|---|---|
| Operating system on Ubuntu 22.04, 24.04 or 26.04 | Ghost(Pro) operates the hosting environment under the plan | Your team patches, upgrades and hardens the Ubuntu host, and uses systemd to manage services |
| Node.js version support | Handled by Ghost(Pro) as part of platform upkeep | Your team tracks supported Node.js versions and plans runtime changes, since Ghost's install guide uses Node 22 as its example |
| MySQL 8.0 or 8.4 database | Hosted and maintained by Ghost(Pro) | Your team installs, tunes, backs up and patches MySQL, and restores it when needed |
| NGINX, TLS certificates and renewals | Provided by Ghost(Pro) under the plan | Your team configures NGINX (1.9.5 or later per the install guide), manages certificate issuance and renewal, and checks TLS settings |
| Backups and restore testing | Ghost(Pro) handles platform-level backup under the plan; confirm scope and restore process in writing | Your team designs, schedules and tests backups of the database, content and configuration, and proves restores work |
| Monitoring and alerting | Confirm with Ghost(Pro) which signals are monitored and how incidents are reported | Your team selects, runs and responds to monitoring of the host, Ghost process, database and certificates |
| Email deliverability for newsletters | Ghost(Pro) runs the sending setup under the plan; confirm sender domain and deliverability responsibilities | Your team configures mail delivery, DNS records and sender reputation, and watches bounces and complaints |
| Security patching | Handled by Ghost(Pro) under the plan | Your team applies OS, database, NGINX and Node.js security updates on a schedule you set |
| Ghost upgrades | Ghost(Pro) applies platform updates under the plan | Your team reviews release notes, tests and applies upgrades; Ghost ships frequent minor releases, with 6.71.0 published on October 15, 2026 |
| Web analytics and ActivityPub service | Confirm availability on your plan with Ghost(Pro) | Ghost-CLI installs do not support web analytics, so a Docker Compose install is needed for analytics or ActivityPub |
What control and data location change for compliance reviews
Self-hosting moves hosting, access, backups and logs inside your own boundary, which changes what an assessor will ask you to show. Ghost(Pro) moves much of that work to Ghost, so your review turns on what the vendor documents and what you still configure. The cards below separate those two sides.
Data location
With self-hosted Ghost, the database, uploaded media and member records sit in the cloud account, data center or network you choose. Ghost(Pro) hosts the site for you, so the storage region and any replicas are set by Ghost. Document where each data store lives, including MySQL and the media directory, and confirm the Ghost(Pro) data location details directly with Ghost before a review.
Administrator access
Self-hosting means your team holds root on the Ubuntu host, database credentials and the Ghost Admin login, so you must define who can reach each layer. On Ghost(Pro), platform administration sits with Ghost and your staff only manage site users. Record the named administrators, how SSH and database access are granted and revoked, and how staff accounts in Ghost Admin are removed when people leave.
Backup ownership
A self-hosted install makes you the owner of backups for the database, content and configuration, along with their encryption, retention and restore testing. Ghost(Pro) backups are run by Ghost, so your review should ask what Ghost retains, how restores are requested and whether you can export your own copy. Document the schedule, storage location and a tested restore procedure for your install.
Logging and evidence
Self-hosted Ghost leaves you responsible for NGINX access logs, systemd journal output, Ghost application logs and any retention policy applied to them. Those logs are your audit trail for admin actions and access attempts. Ghost(Pro) logs are held by Ghost, so ask which events are recorded, for how long and whether you can obtain them during an assessment.
Sub-processors and email
Each self-hosted deployment still relies on third parties: a mail provider for newsletters, Stripe for paid subscriptions and possibly a CDN or DNS host. You must list these yourself and sign the terms that cover them. On Ghost(Pro), Ghost maintains its own sub-processor list, which you should obtain and compare with the services you already approve.
Control responsibility
The key question is which party operates each control. Under self-hosting, patching Ghost, Node.js, MySQL, NGINX and the operating system falls to your team, and DeployOpen can plan, implement and document that work but does not issue audit reports or certifications. Independent auditors assess the result. Build a responsibility matrix that assigns every control to Ghost, to your staff or to a named partner before the review begins.
Why web analytics pushes teams to the Docker Compose install
If you want Ghost's web analytics running inside your own infrastructure, the Ghost-CLI install is not an option. Ghost's Ubuntu install guide states that Ghost-CLI installs do not support web analytics. The same guide documents a separate Docker Compose install for self-hosting web analytics or the ActivityPub service. That single fact often decides the install path before any other comparison point does, so it belongs in the first check you run with your team.
The Docker path changes more than the install command. Instead of a host where Ghost-CLI manages Node.js, MySQL and NGINX directly under systemd, you run containers defined in a Compose file, so the host needs a container runtime and your team must manage image versions, volumes and networking. Upgrades follow the Compose workflow rather than the Ghost-CLI routine described in the Ubuntu guide, which means your change process, rollback steps and backup scope should be rewritten for the Docker setup. Monitoring also shifts: you need visibility into each container and the analytics service, not only the Ghost process and the database. Ask the vendor or your platform team which containers, ports and persistent volumes the Compose file creates, and who owns each one.
Before committing, confirm the current analytics setup in the Ghost documentation, because the supported install methods for analytics and ActivityPub can change between releases. Then check whether the Ghost(Pro) plans you are considering include the analytics features you need. If they do, the Docker work disappears from your scope, but you give up control over where analytics data lives. If they do not, the Docker Compose install becomes a self-hosting project with its own operating cost, and it should be written into your implementation scope and quote as a separate item.
What each model costs and who gets paid for what
Ghost(Pro) charges a fixed monthly rate per plan, and the published rates depend on how many staff users you need and how many members you hold. The Ghost pricing page lists plans billed yearly, with custom plans for larger operations. Ghost's comparison page says Ghost takes no transaction fee on paid subscriptions, but Stripe processing fees still apply, so payment costs continue whichever hosting model you pick.
- Starter: $18 per month, with 1 staff user and 1,000 members.
- Publisher: $29 per month, with 3 staff users.
- Business: $199 per month, with 15 staff users.
- Custom plans: Quoted by Ghost for operations beyond the published tiers, so confirm member and staff limits in writing.
- Stripe fees: Charged by Stripe on each paid transaction, whichever hosting model you choose.
Check which member and staff limits apply to each tier before you commit, and confirm the yearly billing terms on the pricing page at signing.
Self-hosting moves the bill from a subscription to the infrastructure and people behind it. Ghost is MIT-licensed, so there is no license fee, but every recurring line below is paid to someone: a cloud or data center provider, a database host, an email sending service, a backup store, and the staff or partner hours that keep the stack running.
- Server: Compute for Ghost on Ubuntu 22.04, 24.04 or 26.04, with at least 1 GB of RAM as the documented minimum. Paid to your cloud or data center provider and sized by traffic.
- Database: MySQL 8.0 or 8.4. Run it on the same host or on a managed service, which adds a recurring charge.
- Reverse proxy and TLS: NGINX 1.9.5 or later, plus certificate handling. The host cost is usually small, but patching is recurring labor.
- Email sending: A transactional or bulk email service for newsletters and member mail. Ghost's pricing does not cover it, so confirm the provider and volume terms directly with the vendor.
- Backups and people: Off-host backup storage, plus staff or partner time for upgrades, monitoring and security patches. For many teams this is the line most easily underestimated.
Ask your hosting and email vendors for their own price sheets, and list every environment, including staging and analytics, so no recurring line is missing from your model.
Setup is the one-off work of building the stack correctly before launch. It covers installing Ghost, configuring MySQL and NGINX, wiring email, migrating content and hardening access. The Ghost Ubuntu install guide documents installation through Ghost-CLI, and Ghost's WordPress migration documentation notes that custom post types, most uncommon shortcodes and content-restriction plugins do not migrate.
- Installation and configuration: Ghost-CLI setup on Ubuntu with systemd and NGINX, following the documented steps.
- Analytics or ActivityPub: Ghost-CLI installs do not support web analytics. If you need analytics or the ActivityPub service, you add a separate Docker Compose install, which is extra build and operating work.
- Content migration: WordPress XML import handles up to 2,500 posts from files up to 100 MB. Larger or custom migrations need extra scoping, through the open-source TryGhost/migrate toolkit or Ghost(Pro)'s migrations team.
- Email and domain setup: Sender authentication, DNS records and deliverability testing before members receive anything.
- Hardening and documentation: Access control, tested backup and restore, and a runbook for upgrades.
Ask for each of these items to be listed separately in any quote, since a migration that skips content types can leave gaps you only find after launch.
The two models scale differently. Ghost(Pro) rises in steps as staff users and members grow, and it moves to custom plans beyond the published tiers. Self-hosted costs rise with traffic, the number of environments and how much you automate. Neither model is free to run, so the drivers below show where each bill is likely to go up or down.
- Member count: On Ghost(Pro), the member limit can move you into the next tier. Self-hosted, more members mean more database load and more email volume.
- Staff users: Each published tier includes a set number of staff users, so adding editors or contributors can change your plan.
- Traffic: Self-hosted server size follows page views and API calls. The Content API is read-only JSON delivery, but headless front ends still add read load to plan for.
- Environments: Staging and analytics stacks each need their own compute, database, email settings and monitoring.
- Automation depth: Backup, monitoring and patch automation reduce labor but add tooling charges.
Model your next two tier boundaries on Ghost(Pro) and your expected traffic and environment count on self-hosting before comparing totals.
DeployOpen does not publish a price list. Most engagements are fixed-scope, so a quote follows from the scope, deliverables and timeline agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and offers ongoing support and upgrades as retainers. Ask for the items below in writing.
- Scope: Named environments, the Ghost version target, any analytics or ActivityPub needs, and migration volume and content types.
- Deliverables: The installed and hardened stack, backup and restore test evidence, a runbook and handover documentation.
- Timeline: Milestones and acceptance criteria agreed in writing before work starts.
- Recurring support: Whether upgrades, monitoring and continuous testing sit under a retainer, and what the retainer excludes.
- Third-party costs: Your own hosting, email and Stripe charges, listed separately so they are not mistaken for DeployOpen fees.
Compare the quote's one-time and recurring lines against the Ghost(Pro) tiers and the self-hosted line items above, and confirm who pays each vendor directly.
How to move between Ghost(Pro) and self-hosted Ghost
This sequence takes a publication from one Ghost installation to the other, moving content and members with the checks that show each stage is complete before DNS changes and the old site is retired.
Inventory content, members and integrations
Before moving anything, list what the publication depends on: posts and pages, tags, staff users, members and their subscription status, themes, custom integrations, and any third-party tools that read content. The publisher owns this inventory, with help from whoever administers the current site. Confirm which features run on the current installation, especially web analytics and the ActivityPub service, because Ghost's Ubuntu install guide says Ghost-CLI installs do not support web analytics and that a separate Docker Compose install is documented for web analytics or ActivityPub. The output is a written checklist that the target installation must match before cutover.
Export content and members from the source
Use Ghost Admin's export tools to produce a copy of posts, pages, tags, and members from the source installation, and keep the exported files in a controlled location. If the source is a WordPress site instead of Ghost, the import path is different: Ghost imports WordPress's own XML export through Settings, Advanced, Import/Export, handling up to 2,500 posts from XML files up to 100 MB, with WordPress categories becoming Ghost tags. Custom post types, most uncommon shortcodes and content-restriction plugins do not migrate. For larger moves, the TryGhost/migrate toolkit or Ghost(Pro)'s migrations team are the documented routes. Done means the export files open and their post and member counts match the source.
Prepare the target MySQL and NGINX setup
For a self-hosted target, the infrastructure team or DeployOpen-style implementation partner prepares an Ubuntu host on a supported release (22.04, 24.04 or 26.04), a supported Node.js version, MySQL 8.0 or 8.4, NGINX 1.9.5 or later, systemd and at least 1 GB of RAM, then installs Ghost through Ghost-CLI or Docker Compose depending on which features the publication needs. For Ghost(Pro), this step is skipped because the hosting is managed. Confirm backup scheduling, TLS certificate handling and access control for the database before importing. Done means Ghost starts on a staging hostname and the admin login works.
Configure email and Stripe on the target
Set up outgoing email for member and staff messages and connect Stripe for paid subscriptions on the target installation. Ghost states it takes no transaction fee on paid subscriptions, but Stripe processing fees still apply, so the business owner should confirm the Stripe account, payout settings and tax handling directly with Stripe. Decide whether existing paid members will be re-linked or invited again, and confirm this with the current provider before cutover. Done means a test member can sign up, receive email and complete a test subscription on staging.
Import content and test with the Content API
Import the exported content into the target and check posts, tags, images, internal links and member records against the inventory from the first step. Ghost's Content API is read-only, returns JSON and can feed other sites, apps or media channels during the transition. Create a read key through a Custom Integration in Ghost Admin, then point a test consumer at the staging site to confirm it receives the same content. Done means spot checks of a sample of posts match the source and every downstream consumer reads from the new installation.
Test, then switch DNS
Run a scripted test pass covering publishing, member login, newsletter sending, paid checkout and every integration on the inventory. Lower DNS record TTLs ahead of time if your DNS provider supports it, then point the production hostname at the new installation. Keep the source running and read-only until the new site has served traffic cleanly. Ask the hosting provider or DNS administrator to confirm the record change and propagation schedule, since no fixed timeline is supplied here. Done means production traffic reaches the target and publishing and member flows work end to end.
Retire the old site after verification
After the new installation has run without incident, take a final backup of the source, record where the backup is stored and how long it is retained, and then shut the old installation down. Remove the old DNS records and any leftover API keys or integrations pointing at the retired site. Confirm with your compliance or records owner how long the final backup must be kept. Done means the old site no longer serves traffic, the final backup is recorded and every integration key from the old installation is revoked.
Who carries the upgrade work in each model
Ghost ships on two rhythms. Major releases arrive occasionally, with Ghost 6.0.0 published on August 4, 2025, and minor releases arrive often, with 6.71.0 published on October 15, 2026. Each release is a change you must absorb, but the amount of work behind it depends on who operates the site. Under Ghost(Pro), Ghost runs the hosted platform, so the upgrade cycle is part of the service and your team mainly validates the content and member experience. Under self-hosting, every upgrade is a project your team or your implementation partner owns from start to finish.
On a self-hosted install, each upgrade starts with a backup of both the MySQL database and the content directory, because a failed upgrade is only recoverable if you can restore both together. Next, test the release against your theme, custom integrations and any Content API consumers in a staging copy. Then check that the Node.js version and the MySQL version (8.0 or 8.4 in the Ubuntu install guide) are still supported by the release you are moving to, and that NGINX and systemd settings still match your setup. Finally, schedule a maintenance window and agree on a rollback plan with the people who own the site's uptime.
Under Ghost(Pro), Ghost's team performs the platform steps, while you still own the content review, theme changes and any integrations you built. Under self-hosting, you own every step, including the database, the reverse proxy, the Node.js runtime and the server patching that surrounds them. Confirm the exact upgrade procedure for your install type, Ghost-CLI on Ubuntu or the Docker Compose install, in Ghost's Ubuntu install guide and Ghost's current documentation, and ask your partner to write the upgrade runbook and staging test plan into the fixed scope before work starts.
Questions buyers ask before choosing Ghost(Pro) or self-hosted Ghost
What does self-hosting Ghost actually cost compared with Ghost(Pro)?
Self-hosting removes the Ghost(Pro) subscription but adds costs you pay yourself: the server or cloud instance, backups, monitoring, the MySQL and NGINX operating effort, email delivery, and staff time for upgrades. Ghost(Pro) is priced by staff users and members, with Starter at $18 per month (1 staff user, 1,000 members), Publisher at $29 per month (3 staff users) and Business at $199 per month (15 staff users), billed yearly, according to Ghost's pricing page. Ghost takes no transaction fee on paid subscriptions, but Stripe processing fees still apply under either option. The main cost drivers are member count, the number of staff logins, and how much of the upkeep your own team absorbs. Ask any implementation partner for a written quote that separates one-time setup from recurring hosting and support.
How long does a self-hosted Ghost setup take, and what does the team need?
The duration depends on your environment, your existing email and DNS setup, and how much hardening and backup design you need, so confirm the timeline in a written scope rather than relying on a general estimate. The documented Ubuntu path is short in steps but assumes skills across several layers: Ubuntu 22.04, 24.04 or 26.04, a supported Node.js version (the example uses Node 22), MySQL 8.0 or 8.4, NGINX 1.9.5 or later, systemd, at least 1 GB of RAM, and installation through Ghost-CLI, according to Ghost's Ubuntu install guide. Your team needs someone comfortable with Linux administration, TLS certificates, database backups, transactional email configuration and Ghost upgrades.
Can a small team run self-hosted Ghost without outside help?
A team with solid Linux and web operations experience can run Ghost itself, provided someone owns the recurring work. Ghost ships frequent minor releases, with 6.71.0 published on October 15, 2026, according to the TryGhost/Ghost GitHub releases page, so upgrades are a standing task rather than a one-off. Plan for database backups and restore tests, OS patching, certificate renewal, NGINX configuration, uptime monitoring and incident response. If no one on the team can take those on, a managed option such as Ghost(Pro) or a retained support agreement may fit better. For a team that wants outside help, DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure, typically under a fixed-scope agreement with retainers for ongoing support.
Does web analytics work on the Ghost-CLI install?
No. Ghost's Ubuntu install guide states that Ghost-CLI installs do not support Ghost's web analytics. The documented route for self-hosting web analytics, or the ActivityPub service, is a separate Docker Compose install. This matters for the choice itself: if analytics is a requirement, plan on Docker Compose from the start rather than migrating later, and confirm with Ghost that the current Docker Compose setup covers every feature you need. Ask your implementation partner how they would run that stack, how they would back it up, and what changes when you upgrade.
Can DeployOpen implement, harden and support self-hosted Ghost?
Yes, within the platforms and work described in the written scope. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the agreed scope. Ask for the specific deliverables covering the MySQL, NGINX, email and analytics components, and for the support hours and response commitments in writing.
What should we confirm with Ghost about data location and compliance?
Confirm these points directly with Ghost before you commit, because the answers depend on your deployment and contract. Ask where Ghost(Pro) stores member and subscriber data, which regions and subprocessors are involved, how data is exported, and what contractual terms apply to personal data. For self-hosting, the data location is your own infrastructure, so the questions shift to your backup location, encryption, access controls and retention. Ghost is licensed under the MIT license, and it describes itself as an independent non-profit organisation that reinvests its revenue into the product, according to Ghost's comparison page, but that does not answer questions about your data. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
How DeployOpen scopes, delivers and supports self-hosted Ghost
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Ghost, that means working out whether Ghost-CLI on Ubuntu or a Docker Compose install fits your feature needs, then delivering the MySQL, NGINX, email and backup setup you would otherwise own yourself.
How we scope
- Confirm whether you need web analytics or the ActivityPub service, which determines between the Ghost-CLI and Docker Compose installs.
- Record the hosting target, including Ubuntu release, RAM, and whether you run your own cloud account, data center or air-gapped network.
- Agree the MySQL, NGINX, email provider and backup responsibilities in writing before any work starts, so ownership is clear.
- Set the scope, deliverables and timeline in a fixed-scope written agreement, with ongoing support offered separately as a retainer.
How we build
- Install Ghost with the chosen method and configure MySQL, NGINX, systemd and TLS to match the agreed design.
- Connect transactional email and Stripe-linked membership settings, then test signup, paid subscription and newsletter delivery end to end.
- Harden the server, restrict database and admin access, and check that the Content API keys are scoped to the integrations that need them.
How we hand over
- Document the install, configuration, upgrade steps and the reasons behind each design choice for your operations team.
- Provide a tested backup and restore procedure for the database, content and uploaded media, with a recorded restore check.
- Walk your team through routine tasks such as applying Ghost minor releases and rotating credentials, so the handover is usable without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you do not want to run Ghost upgrades in-house.
- Review each new Ghost release against your configuration, including Node.js and MySQL version compatibility, before you apply it.
- Confirm with your team which support boundaries apply, so responsibility for hosting, email and Stripe settings is clear during incidents.
