Requirements and responsibilities
Name the team, server, hostname, owner and affected users for the WordPress site. Record the current version and the actual business flow that must survive the change. Confirm the current dashboard form, plan eligibility, and server capacity before committing a resource change. A one-click catalog listing is discovery, not permission or proof that the connected MCP profile can install it.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Prepare a non-sensitive test input and an acceptance record. Keep access to the app administrator and an independent observer where possible; omit secrets from AI prompts and client reports.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
For WordPress, verify the file and database backup scope and a safe target for recovery. Native scheduling, destination settings, staging synchronization and restore remain dashboard actions. Agree a maintenance window and owner before any action that interrupts the service or overwrites data.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Illustrative situation
A WooCommerce shop has a tested theme edit on staging, while production received new paid orders during testing. The release owner must decide which data can move safely.
Choose the approach
Prefer a narrow files or code release when production orders, accounts or stock changed after staging was copied.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Treat push and pull as directional data movement with explicit scope; a production database overwrite is a separate destructive decision.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Record both baselines
- Where
- xCloud production and staging site views
- Permissions
- Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
- Inputs
- Two site IDs, clone time, versions, last order ID
- Action
- Open both sites, record hostnames, plugin/theme versions and the timestamp of the staging copy. Confirm neither URL is confused with the other.
- Expected result
- A comparison anchored to two known environments.
- Verify
- Check signed-out URLs and dashboard IDs with the shop owner.
- If it fails
- If environment identity is unclear, stop before using Manage Staging.
Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Create a staging environment in xCloud
Step 2 of 5
Inventory changes by data class
- Where
- WordPress files, database and WooCommerce Orders
- Permissions
- Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
- Inputs
- Theme files, media, settings, orders, accounts
- Action
- List changes made in staging and changes made in production since the clone. Separate theme files from database-backed design settings and live transaction tables.
- Expected result
- A change matrix showing which side owns each newer record.
- Verify
- Sample recent order IDs and compare theme/settings versions across both sites.
- If it fails
- If the desired edit lives in database settings, a files-only push may not carry it; plan a targeted alternative.
Sources: Manage WordPress plugins · Create a staging environment in xCloud
Step 3 of 5
Inspect synchronization scope
- Where
- xCloud staging Site → Manage Staging
- Permissions
- Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
- Inputs
- Push or pull direction and selected file/database options
- Action
- Read the current push and pull options without submitting them. Write down source, target and every selected scope, including whether database records are replaced.
- Expected result
- An exact proposed synchronization action.
- Verify
- Have a second reviewer read the target and data scope aloud from the dashboard.
- If it fails
- If database scope would overwrite orders, cancel the action and choose a narrower release.
Sources: Create a staging environment in xCloud · xCloud agent capability boundaries
Step 4 of 5
Protect production state
- Where
- xCloud Site Backup and WooCommerce reports
- Permissions
- Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
- Inputs
- Completed backup, recent orders, payment ledger
- Action
- Inspect the latest completed production backup, record orders created since clone time, and propose only the necessary edit window for a separate release.
- Expected result
- A recovery point plus a reconciliation list for live transactions.
- Verify
- Check backup completion and match recent order/payment IDs before proceeding.
- If it fails
- If backup is running or an order cannot be reconciled, defer promotion.
Sources: Site backups in xCloud · xCloud agent capability boundaries · Create a staging environment in xCloud
Step 5 of 5
Hand off a narrow release plan
- Where
- Change ticket and release owner
- Permissions
- Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
- Inputs
- Approved scope proposal, test order and site checklist
- Action
- Document the files/settings change to release separately, the backup checkpoint, newer-order reconciliation and tests required after production change. Do not push or alter either site during this comparison.
- Expected result
- A decision-ready plan without changing production.
- Verify
- Have the release owner confirm source, target and database exclusion in the proposed action.
- If it fails
- If the change cannot avoid overwriting newer orders, design a manual targeted migration before a separate release.
Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Site backups in xCloud
Maintenance
Review this task after app or template updates and at the cadence agreed with the owner. Record failures as dated observations rather than assuming host health proves service health.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Watch access changes, backup completion, free storage and external providers. Recheck integrations after credential, DNS, mail or source-data changes.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Recovery decisions
If the inventory, finding, report or plan is wrong, preserve its dated source evidence and issue a corrected version to the approved owner. Keep the prior record visible as superseded.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Recheck the exact site, timestamp and task-specific test before approving any separate change. A bad review does not by itself justify replacing live site data.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Create a staging environment in xCloud · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
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
- staging decision, evidence and task action (covered): The procedure identifies the authorized task boundary and observable result. Record both baselines Inventory changes by data class Inspect synchronization scope Protect production state
- backup, ongoing operation and recovery (covered): Recovery and maintenance are checked in the task procedure. Protect production state Hand off a narrow release plan