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

# Native Ghost hosting overview

> How StackShift runs Ghost as a first-class native runtime with a pinned official image, managed MySQL 8, persistent content, plan-aware isolation, integrated mail, and durable lifecycle operations.

<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

Understand what StackShift creates for a Ghost site, which responsibilities StackShift owns, and how this differs from a template or source deployment.

## Prerequisites

* Native Ghost must be enabled in your StackShift environment
* Hosted sites require an Ignite, Pro, or Enterprise plan
* Connected-node sites require a healthy node reporting at least 1 GB of available memory

## Workflow

<Steps>
  <Step>
    Choose Ghost Site from the project creation screen.
  </Step>

  <Step>
    Select a tested Ghost release from StackShift’s curated runtime catalog.
  </Step>

  <Step>
    Choose StackShift Managed placement or a connected node with validated capacity.
  </Step>

  <Step>
    Let the Ghost lifecycle worker provision the project, managed database, private mail bridge, native stack, route, and health state.
  </Step>

  <Step>
    Open the generated admin URL and create the first Ghost owner directly in Ghost.
  </Step>
</Steps>

## Native runtime, not a template

Native Ghost is a dedicated StackShift resource type. Creating a site does not render a marketplace template, clone a repository, generate a Dockerfile, or run a customer source build.

StackShift selects an official Ghost image only from a curated runtime catalog. Every catalog entry contains an exact Ghost version, an exact SHA-256 image digest, MySQL compatibility, a minimum-memory requirement, and explicit supported upgrade predecessors. Arbitrary image tags are rejected.

## Resources StackShift creates

* One Ghost project and one native runtime stack.
* A digest-pinned Ghost web service on internal port 2368.
* A 10 GB persistent volume mounted at `/var/lib/ghost/content` for themes, images, and other content files.
* A separate StackShift-managed MySQL 8.0 database, initially provisioned with 5 GB of storage.
* A private, digest-pinned SMTP bridge sidecar for transactional delivery through StackShift Mail when mail is enabled.
* A generated StackShift domain, or a verified custom domain supplied during creation.
* A durable operation record that exposes provisioning progress, retries, and the last failure.

## Runtime resources and isolation

Ghost receives the CMS resource profile: 1 CPU and 1 GB of memory. The private mail bridge receives 0.1 CPU and 128 MB of memory.

* Ignite and other standard hosted tiers run the native services with containerd and runc in shared-container isolation.
* Pro and Enterprise run the same native specification with containerd and Kata VM-backed isolation.
* The isolation decision is made from the account plan; it is not a user-supplied runtime option.
* Connected-node placement is accepted only when the selected healthy or degraded node reports at least 1,024 MB available and is not draining.

## Ownership and security boundaries

* StackShift never asks for or stores the Ghost owner password. Owner setup happens on the official Ghost `/ghost/` screen.
* The database is managed outside the Ghost stack and is linked to the project for lifecycle and recovery operations.
* The mail bridge is not the exposed service. It receives a hashed, project-bound, mail-only credential.
* The control plane supplies an immutable digest-qualified image, and the agent rejects any resolved-digest mismatch.
* Only the project owner or a team member with the required project permission can read or mutate Ghost resources.

## Current tested catalog

The creation wizard and `GET /api/v1/ghost/runtime-options` are the source of truth. At the time of this documentation, Ghost 6.57.1 is the only selectable release. Ghost 5.130.5 and 6.56.0 are retained only as upgrade predecessors so existing installations have tested paths to 6.57.1; they cannot be selected for a new deployment. Catalog contents can change after StackShift qualification.

## What is outside the native Ghost scope

* Importing or migrating an existing Ghost publication.
* Installing arbitrary themes through StackShift’s control plane.
* External or customer-managed databases.
* Automatic unattended Ghost upgrades.
* ActivityPub and analytics sidecars such as Tinybird.

## Expected result

<Check>
  You have a native Ghost project with a public publication URL, a separate `/ghost/` admin URL, managed MySQL 8, persistent content, and no customer build or Dockerfile record.
</Check>

## Common failures

<Warning>
  * Native Ghost is disabled for the environment.
  * The hosted account is below Ignite.
  * The connected node has no current memory telemetry or less than 1 GB available.
  * The platform mail bridge image or exact digest is not configured.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Deploy a native Ghost site" href="/ghost/deploy-a-ghost-site">
    Create a fresh Ghost publication on StackShift Managed infrastructure or a connected node, follow provisioning, and complete owner setup securely in Ghost.
  </Card>

  <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="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>