App workflow Docker workloads + WordPress

Add an app subdomain beside a WordPress site

Plan DNS, SSL, routing, app ownership, and separate application setup. 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 company keeps WordPress at its main domain and wants a separate internal app at app.example.com. It needs independent deployment and recovery while preserving the website.

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

Map the two services

Where
xCloud Sites and DNS provider
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
WordPress domain, app hostname, team/server IDs
Action
Record where WordPress runs and select an app hostname that does not overlap its canonical domain or redirects.
Expected result
Two distinct site identities.
Verify
Check DNS and xCloud domain list for collision.
If it fails
If a wildcard or redirect captures app traffic, resolve routing before deployment.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 2 of 5

Check app template and server

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
Selected app, stack, resource requirements
Action
Confirm the current app template and compatible Docker + NGINX server. Read its first-run and storage requirements rather than assuming the WordPress server can host it.
Expected result
A viable app deployment target.
Verify
Match template requirements to server capacity and current create form.
If it fails
If no suitable server exists, plan a separate resource with cost approval.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 3 of 5

Create the app host

Where
xCloud Add site → One-Click Apps; DNS provider
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Approved app, server, site title and subdomain
Action
Install through the supported dashboard path and attach the app hostname. Have the separate DNS owner change only its web record after reviewing current values.
Expected result
A reachable app URL beside the unchanged WordPress URL.
Verify
Open both hosts over HTTPS and inspect certificates and redirects.
If it fails
If WordPress redirects to the app or vice versa, correct host routing before user setup.

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

Step 4 of 5

Configure independent access

Where
Selected application's administrator interface
Permissions
Authorized Docker application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Admin account, limited user, integration policy
Action
Set the app's own users and permissions. Test whether links from WordPress simply navigate or require a separately designed authentication integration.
Expected result
A limited user can perform the intended app task without WordPress admin rights.
Verify
Sign out of both sites and retest each login separately.
If it fails
If a shared login is required, scope and test an actual SSO integration rather than claiming it exists.

Sources: xCloud One Click Apps catalog

Step 5 of 5

Document dual recovery

Where
WordPress Site Backup and Docker Backup views
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Both site IDs, backup rows, owners
Action
Check completed backups and recovery targets separately for WordPress and the app. Record which owner handles DNS, app data and credentials.
Expected result
A two-service runbook.
Verify
Show a teammate how to locate both backup histories.
If it fails
If the app uses external storage, add its own recovery method before production use.

Sources: Back up and restore Docker apps · Docker backup operations and storage constraints

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