App workflow WordPress

Create a WordPress site and verify its first page

Deploy a WordPress site and confirm access, domain/SSL state, and a representative page. 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 services firm has a new domain and a draft About page. Its owner wants a fresh WordPress site with a working administrator login and HTTPS before anyone adds forms or customer data.

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

Pin the site target

Where
xCloud Teams and Servers
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Team ID, target hostname, server stack, capacity
Action
Confirm the intended team and server in xCloud, record the stack and resource headroom, and check whether the domain is already attached to another site.
Expected result
An unambiguous eligible server and unused target hostname.
Verify
Reopen the server view and compare its ID with the change request.
If it fails
If the server is Docker-only or the hostname is in use, choose a different target before creation.

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

Step 2 of 5

Prepare first-run inputs

Where
DNS provider and xCloud Add Site
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
DNS owner, site title, admin email, initial credential handoff
Action
Read the existing A or AAAA record and draft the required change for the DNS owner; choose a site title and credential recipient. Keep the password in a secret manager.
Expected result
A reviewed create-site form and DNS change request with an accountable administrator.
Verify
Check current public DNS and confirm the mailbox can receive the invitation or credential message.
If it fails
If DNS or mail ownership is unresolved, use a safe demo route and postpone production-domain claims.

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

Step 3 of 5

Create WordPress

Where
xCloud Add Site → WordPress or documented MCP create operation
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Approved team, server, domain and WordPress create inputs
Action
Create exactly one WordPress site using the displayed dashboard form or discovered MCP operation. Wait for the installation job to reach its terminal state and note the site ID.
Expected result
A reachable WordPress installation tied to the chosen host.
Verify
Check the site in xCloud and open wp-admin in a fresh browser session.
If it fails
If the job fails, inspect the phase and logs; do not submit a duplicate create request blindly.

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

Step 4 of 5

Publish and read the first page

Where
WordPress Pages editor and public browser
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Draft text, page slug, limited editor account
Action
Create a harmless page with a unique title, preview it, publish it, and open its permalink while signed out. Test an editor account without administrator rights.
Expected result
The public page and its media render at the expected permalink.
Verify
Compare the editor preview and signed-out page, and confirm no draft-only content leaked.
If it fails
If the page is missing, check permalink, cache and publishing state before changing DNS.

Sources: WordPress roles and capabilities

Step 5 of 5

Check HTTPS and recovery

Where
External browser and xCloud Site Backup
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Canonical hostname, certificate state, backup destination
Action
Open the page and admin login through HTTPS, inspect certificate name and redirects, then confirm a completed file-and-database backup or configure the first native backup in the dashboard.
Expected result
A first-run acceptance record and recovery point for future edits.
Verify
Record the final URL, certificate result, admin login result and completed backup timestamp.
If it fails
If SSL is pending, treat the page as a pilot until DNS and certificate checks pass; never label a queued backup complete.

Sources: Site backups in xCloud · xCloud agent capability boundaries

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