Goal
Test content, settings, and qualified Ghost upgrades against production-like data without exposing the clone publicly or sending mail.Prerequisites
- A running production Ghost site
- Working stack and database backup infrastructure
- Capacity for a second Ghost project and managed MySQL database
Workflow
1
Open the production Ghost overview.
2
Choose Create staging clone.
3
Wait while StackShift captures a coordinated production recovery point.
4
Wait for the separate staging project and database to be provisioned and restored.
5
Choose Open authenticated staging and complete StackShift authentication if prompted.
6
Perform testing without enabling outbound mail.
Staging is a separate environment
- A new Ghost project is created; production is not converted into a multi-environment stack.
- A new managed MySQL database is provisioned for staging.
- A new content volume and native runtime stack are created.
- The target uses the exact Ghost version recorded in the staging recovery point.
- The source project’s placement mode, connected node, team, and selector tags are carried into target provisioning where applicable.
Clone sequence
Durable staging operation
Authenticated ingress
Staging uses thestackshift_authenticated route mode. If the browser has no valid project-scoped staging cookie, ingress redirects to the StackShift API login handoff. StackShift verifies project access, issues a secure HttpOnly cookie valid for eight hours on the managed base domain, and redirects back to the staging URL.
- The cookie is scoped to the staging project ID.
- The staging URL must be HTTPS on the configured StackShift base domain.
- Ghost authentication still protects
/ghost/; StackShift authentication is an additional ingress gate.
Mail-silent by design
Staging creation setsmail_enabled to false and does not create the private SMTP bridge service. Production mail credentials are never copied. This prevents restored members, staff, or automations from receiving accidental transactional messages from the clone.
- Do not treat staging as a newsletter-delivery test environment.
- Mailgun configuration is not copied as an infrastructure credential.
- If email must be tested, use a controlled non-production project and test recipients instead of changing the clone’s runtime spec.
Data-handling precautions
- The clone contains production database and content data; apply the same privacy and access controls as production.
- Delete staging when testing finishes to remove its project, database, volume, route, and recovery metadata.
- Changes in staging do not synchronize back to production.
- Creating another staging clone creates another independent project; it does not refresh an existing clone.
Expected result
A separate Ghost project runs cloned data on a generated StackShift domain behind authenticated ingress, with a distinct database and no outbound mail service.
Common failures
Related guides
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.
Upgrade Ghost safely
Use StackShift’s curated upgrade graph, mandatory pre-upgrade recovery point, digest-pinned runtime update, and automatic rollback path.
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.