Requirements and responsibilities
WordPress staging is created from the site overview in the dashboard on an eligible paid plan. Push and pull happen in the staging site’s management view; the API staging-create operation serves Git sites, not WordPress.
Create a staging environment in xCloud · xCloud agent capability boundaries
Inventory records created on production since staging was copied: orders, bookings, form entries, users, comments and media. A staging database push can overwrite production content, even when application testing passed.
Create a staging environment in xCloud · xCloud agent capability boundaries
Have a completed production backup and a person authorized to approve scope, interruption and acceptable loss. xCloud creates backup copies at push start, but that does not replace a verified recovery decision.
Create a staging environment in xCloud · Site backups in xCloud
Illustrative situation
Illustrative scenario: an agency has tested a theme and plugin change on staging while the live WooCommerce site has continued taking orders. The release must move the code change while preserving orders and customer accounts created since the staging copy.
Choose the approach
Prefer a files-only transfer when the change lives in theme/plugin files. Choose selected database tables only after confirming their dependencies and that they contain no newer production records; otherwise reproduce settings directly in production under change control.
Use incremental file options only with a reviewed file inventory. Incremental means a particular file selection behavior, not a guarantee that the release is safe for data or business integrations.
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Compare production and staging state
- Where
- Production and staging site views; staging → Manage Staging
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Site IDs, deployment history, changed files/tables, plugin versions and live records since last pull.
- Action
- Record the intended release items and identify dynamic production records that must survive. Compare plugin/theme versions and data changes; exclude test transactions, mail and webhook side effects.
- Expected result
- A bounded release manifest that states exactly what moves and what stays live.
- Verify
- Have a second owner confirm production/staging identities and reconcile recent order or booking counts.
- If it fails
- If change scope or record ownership is unclear, stop the push and narrow the release.
Sources: Create a staging environment in xCloud · xCloud agent capability boundaries
Step 2 of 5
Confirm backup and rollback window
- Where
- Production Site → Site Backup
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Completed backup ID/time, storage, restore owner, live-data cutoff and maintenance window.
- Action
- Verify a fresh completed production backup and record how records added after it will be preserved or reconstructed. Agree on launch and rollback thresholds.
- Expected result
- A usable recovery point and an explicit newer-data decision.
- Verify
- Check completion, storage access and last restore rehearsal; document the order/booking reconciliation method.
- If it fails
- If backup or ownership fails verification, postpone the release.
Sources: Site backups in xCloud · xCloud agent capability boundaries
Step 3 of 5
Run isolated staging acceptance
- Where
- Staging WordPress and relevant application
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Test users, sandbox payment or mail destinations, form/booking/cart scenarios.
- Action
- Test the changed pages plus login, revenue and messaging flows. Confirm staging does not send real customer messages or charges. Capture observed results.
- Expected result
- A signed acceptance record for the exact release manifest.
- Verify
- Compare actual result and expected outcome for each case; inspect plugin errors and dynamic pages in separate sessions.
- If it fails
- Any failed critical journey blocks production transfer.
Sources: Create a staging environment in xCloud · WooCommerce testing orders
Step 4 of 5
Push only the approved scope
- Where
- Staging site → Manage Staging → Push Data
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Approved source/target, files and database selection, maintenance window and approver.
- Action
- Review the dashboard transfer choices again. Select only approved files and, if justified, selected database tables. Avoid a full staging database overwrite while production holds newer records. Start the push manually and observe deployment logs.
- Expected result
- The intended release moves to production and records its scope and outcome.
- Verify
- Check deployment status and compare target versions/files and newer production record counts to the pre-push baseline.
- If it fails
- On a failed or surprising transfer, stop further pushes, preserve current data and use the recovery decision rather than repeating blindly.
Sources: Create a staging environment in xCloud · xCloud agent capability boundaries
Step 5 of 5
Check live business behavior and close the release
- Where
- Production site, application and deployment logs
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Release manifest, baseline counts, test accounts and incident owner.
- Action
- Repeat critical production checks using safe methods, including a purchase or booking path when relevant. Confirm HTTPS, login, messages and recent records; record the final deployment result and owner.
- Expected result
- A production release accepted on business evidence, not only a successful transfer status.
- Verify
- Reconcile newest order/booking IDs, test receipts and site error observations; mark each acceptance case pass or fail.
- If it fails
- If critical tests fail, use the approved forward fix or restore plan, accounting for records created since the backup.
Sources: Create a staging environment in xCloud · WooCommerce testing orders
Maintenance
Keep a release log with source and target, transferred scope, backup reference, data reconciliation and acceptance result. Refresh staging from production before the next change only after reviewing how that pull affects staging work.
Review integration side effects and cache behavior after plugin or theme changes; repeat relevant business tests whenever these change.
Create a staging environment in xCloud · WooCommerce testing orders
Recovery decisions
A dashboard restore replaces the selected target state. Before restoring, export or reconcile newer production orders, bookings and user changes; confirm scope and acceptable loss with the business owner.
If a single file or setting caused the issue, prefer a reviewed forward fix or narrow rollback when the vendor supports it; a database restore is not automatically necessary.
AI handoff
Connect xCloud MCP in an agent client and select the intended team. Discover the current tools, schemas and scopes. Use reads for inventory; present exact site, server, domain, cost, interruption and data impact before each approved write. Use returned dashboard_url values for manual work. The packaged REST fallback accepts GET requests only; never use it for 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
- Create and synchronize WordPress staging dashboard · manual
WordPress staging requires an eligible paid plan. The API staging-create operation is for Git sites.
Checkpoint: Use Site overview → Add Staging and staging Site → Manage Staging. Inspect push/pull scope before overwriting data.
- Configure native WordPress backup and restore dashboard · manual
Native schedule, retention and destination changes and all restores are dashboard-only.
Checkpoint: Use Site → Site Backup. Before restoring, confirm backup, target, scope and treatment of newer records.
- Configure and test application behavior app · manual
xCloud hosting operations do not configure WooCommerce checkout, n8n workflows, Nextcloud sharing policy or application users.
Checkpoint: An application administrator verifies each real business journey and records observed outcomes.
WooCommerce testing orders · n8n Webhook node and test/production URLs · Nextcloud file sharing administration · xCloud agent capability boundaries
- Restore a backup dashboard · manual
Native and Docker restore operations are dashboard-only. An in-place Docker restore replaces current data.
Checkpoint: Use Site → Site Backup → Previous Backups → Restore Backup (or Restore to Another Site where offered). Confirm exact target and recovery point before proceeding.
xCloud agent capability boundaries · Back up and restore Docker apps
Copyable agent brief
Manual checkpoints
- Create and push WordPress staging in the dashboard.
- Isolate payment, email and webhooks for staging acceptance.
- Approve any database transfer or restore after reconciling newer records.
Feature coverage
- scope (covered): Compares exact source, target and changed data. Compare production and staging state
- recovery-point (covered): Checks completed backup and newer data. Confirm backup and rollback window
- staging-acceptance (covered): Tests application outcomes before release. Run isolated staging acceptance
- transfer (covered): Uses dashboard with reviewed scope. Push only the approved scope
- production-verification (covered): Reconciles live records and business checks. Check live business behavior and close the release