Skip to main content
Live with caveats. This area is real and usable, but the docs intentionally call out operational or UX limits that still matter.

​
Goal

Move a publication to a tested Ghost release without accepting arbitrary tags or performing an unattended upgrade.

​
Prerequisites

  • A running native Ghost installation
  • A target release whose upgrade_predecessors includes the current version
  • Working database and stack backup/restore infrastructure

​
Workflow

1
Review the current version and the upgrade offered in the Ghost overview.
2
Read the target Ghost release notes and check integrations or themes outside StackShift.
3
Choose Upgrade and confirm the recovery-point warning.
4
Wait for the pre-upgrade backup and digest-pinned deployment to complete.
5
Validate the site, admin, theme, members, integrations, and mail after upgrade.

​
Only tested paths are accepted

StackShift does not accept an arbitrary Ghost tag or a target version that merely looks newer. The target catalog entry must explicitly list the installed version as a supported predecessor. The dashboard displays an upgrade action only when such a target exists.

​
Upgrade sequence

The operation is always explicit and user-approved. StackShift does not schedule unattended Ghost upgrades.
Safe upgrade operation

​
Automatic rollback

If updating or deploying the new runtime fails, StackShift restores the pre-upgrade MySQL backup and the prior stack backup. The failure remains visible and reports that the prior release was restored.
  • Rollback requires both backup artifact IDs.
  • Database restore runs before runtime/content restore.
  • A rollback failure is reported separately because it requires operator attention.
  • After any rollback, manually validate the publication before resuming writes.

​
Before approving an upgrade

  • Review Ghost’s upstream breaking changes.
  • Check whether a custom theme declares compatibility with the target major.
  • Confirm backup storage and recent recovery operations are healthy.
  • Create a private staging clone and test the same upgrade there first for important sites.
  • Schedule a maintenance window because coordinated backup pauses Ghost writes briefly.

​
Expected result

Ghost runs the exact catalog image and digest for the target version, with a completed pre-upgrade recovery point retained for recovery.

​
Common failures

  • The target release is not in the StackShift catalog.
  • The current version is not an approved predecessor.
  • The pre-upgrade recovery point cannot complete.
  • The new image cannot be pulled or fails digest validation.
  • The runtime update fails and rollback also encounters unavailable backup infrastructure.

Create a private Ghost staging clone

Clone production Ghost data into a separate native project with a new database, new runtime credentials, generated domain, authenticated ingress, and outbound mail disabled.

Ghost recovery points and restore

Capture Ghost’s MySQL data, persistent content, and exact runtime release as one coordinated recovery point, then restore the complete set through a durable operation.

Ghost troubleshooting and limitations

Diagnose native Ghost provisioning, database, image, routing, mail, recovery, staging, and upgrade failures using persisted operation state and clear resource boundaries.