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

# Ghost Admin and custom domains

> Complete owner setup in Ghost, understand the generated URLs, attach a custom domain, and keep Ghost’s canonical URL aligned with StackShift routing.

<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

Operate the publication on its intended hostname without splitting ingress routing from Ghost’s internal canonical URL.

## Prerequisites

* A running native Ghost project
* Control of the DNS zone for a custom domain

## Workflow

<Steps>
  <Step>
    Open Ghost Admin from the project overview and create the first owner in Ghost.
  </Step>

  <Step>
    Point the desired hostname to the StackShift ingress target.
  </Step>

  <Step>
    In the Ghost overview, enter the hostname under Publication domain.
  </Step>

  <Step>
    Choose Verify and attach.
  </Step>

  <Step>
    Confirm the public site and `/ghost/` both load on the new hostname.
  </Step>
</Steps>

## Generated site and admin URLs

Every site receives an HTTPS publication URL. The admin URL is the publication URL plus `/ghost/`. StackShift stores both URLs as Ghost installation metadata but does not proxy or replace Ghost’s own authentication.

## Attach a domain safely

* Enter a hostname such as `publication.example.com`; StackShift normalizes schemes and trailing dots.
* DNS readiness is validated before the routing change is accepted.
* StackShift updates the native stack route and Ghost’s `url` environment value together, then redeploys the stack.
* The project custom-domain field and Ghost installation URLs are updated only after the runtime update succeeds.

## Why the canonical URL matters

Ghost uses `url` when generating absolute links, member emails, redirects, canonical metadata, and admin URLs. Changing DNS without attaching the domain in StackShift can leave Ghost generating links for the old generated hostname.

## Domain-change precautions

* Create a recovery point before a high-traffic production hostname change.
* Keep the old DNS record available until the new route is verified.
* After attachment, check the home page, a post, an image, member signup, and `/ghost/`.
* Update external integrations that allowlist the previous callback or origin URL.

## Expected result

<Check>
  StackShift routing, the project custom domain, Ghost’s `url` setting, the public site URL, and the admin URL all use the same HTTPS hostname.
</Check>

## Common failures

<Warning>
  * DNS does not yet resolve to the expected StackShift ingress.
  * A full URL with a path is pasted; only the hostname is used.
  * The runtime is still provisioning or another lifecycle operation is active.
  * Cached DNS or browser redirects make the old hostname appear active temporarily.
</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="DNS records and project connection" href="/domains-and-email/dns-records-and-project-connection">
    Manage DNS records and connect domains to projects or other runtime surfaces.
  </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>
</CardGroup>