App workflow Ghost + Docker workloads

Deploy Ghost for independent publishing

Confirm current template and upstream requirements, then test initial publishing and email assumptions. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A small editorial team wants a publication separate from its corporate WordPress site. It needs Ghost publishing, staff permissions and an export route before launch.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Define publication scope

Where
Editorial plan and Ghost documentation
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Domain, authors, newsletter and membership needs
Action
Decide whether the site is public posts only or needs members/newsletters. Assign staff roles, mail provider and content ownership.
Expected result
A bounded first launch.
Verify
Confirm editor can describe a sample publishing path.
If it fails
If newsletters or paid access are required, scope and test those providers separately.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Ghost content and member exports

Step 2 of 5

Check template and hosting

Where
xCloud One-Click Apps catalog
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Ghost template, Docker server, storage, hostname
Action
Confirm current template availability, persistent database/media paths and server headroom. Choose a stable publishing domain.
Expected result
A viable deployment plan.
Verify
Compare template requirements with actual server and DNS.
If it fails
If storage or domain is unresolved, use a temporary pilot host.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Ghost content and member exports

Step 3 of 5

Install the Ghost host

Where
xCloud dashboard → One-Click Apps
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Approved xCloud site, hostname and protected first-run administrator handoff
Action
Deploy Ghost through the supported one-click dashboard path and record its first-run URL for the editorial administrator.
Expected result
A reachable Ghost host ready for protected application setup.
Verify
Confirm the xCloud site and hostname match the approved deployment, then verify that the expected protected first-run page is reachable.
If it fails
If the hostname, certificate or first-run page is wrong, stop application setup and resolve the hosting or access issue before entering credentials.

Sources: xCloud One Click Apps catalog · xCloud agent capability boundaries

Step 4 of 5

Publish a controlled item

Where
Ghost editor and public browser
Permissions
Authorized Ghost application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Draft post, image, scheduled test
Action
Complete first administrator setup, invite a limited editor, then preview and publish one harmless article. Check permalink and image; test scheduling after confirming the time zone.
Expected result
A public article with correct metadata and media.
Verify
Open the link signed out and inspect page title and image. Sign in separately as the limited editor and administrator and confirm their allowed settings match the assigned roles.
If it fails
If scheduling or email fails, separate Ghost job/mail issues from host reachability. If an invitation fails, inspect Ghost mail/provider configuration; if editor permissions exceed the intended role, correct them before adding staff.

Sources: Ghost content and member exports · Ghost staff roles and invites · Ghost publishing and scheduling

Step 5 of 5

Export and back up

Where
Ghost Admin export and xCloud Docker Backup
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Post/member/theme exports, backup destination
Action
Export sample content, member list if used and theme; inspect completed Docker backup for persistent data and record update owner.
Expected result
A recovery plan for publication and membership.
Verify
Verify export files open and backup row completed.
If it fails
If a restore would erase newer posts or members, preserve current exports before applying it.

Sources: Back up and restore Docker apps · Docker backup operations and storage constraints · Ghost content and member exports

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized Ghost administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases