> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Warning>
  **Live with caveats.** This area is real and usable, but the docs intentionally call out operational or UX limits that still matter.
</Warning>

## 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

<Steps>
  <Step>
    Open the production Ghost overview.
  </Step>

  <Step>
    Choose Create staging clone.
  </Step>

  <Step>
    Wait while StackShift captures a coordinated production recovery point.
  </Step>

  <Step>
    Wait for the separate staging project and database to be provisioned and restored.
  </Step>

  <Step>
    Choose Open authenticated staging and complete StackShift authentication if prompted.
  </Step>

  <Step>
    Perform testing without enabling outbound mail.
  </Step>
</Steps>

## 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

```text Durable staging operation theme={null}
production recovery point
  -> new staging project
  -> new MySQL database and content volume
  -> native Ghost runtime with authenticated routing
  -> restore cloned database
  -> restore cloned content into the new volume
  -> deploy and return staging_project_id + staging_site_url
```

## Authenticated ingress

Staging uses the `stackshift_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 sets `mail_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

<Check>
  A separate Ghost project runs cloned data on a generated StackShift domain behind authenticated ingress, with a distinct database and no outbound mail service.
</Check>

## Common failures

<Warning>
  * The production site is not running and cannot produce a recovery point.
  * The target placement has insufficient capacity.
  * Authenticated access is attempted on a custom domain rather than the managed StackShift staging domain.
  * A backup or restore dependency is unavailable.
  * The staging operation is still running even though the initial recovery point is completed.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Ghost recovery points and restore" href="/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.
  </Card>

  <Card title="Upgrade Ghost safely" href="/ghost/safe-ghost-upgrades">
    Use StackShift’s curated upgrade graph, mandatory pre-upgrade recovery point, digest-pinned runtime update, and automatic rollback path.
  </Card>

  <Card title="Ghost troubleshooting and limitations" href="/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.
  </Card>
</CardGroup>