GitHub Copilot + xCloud

Back up and stage sites with GitHub Copilot on xCloud

Backing up and staging sites with GitHub Copilot means asking agent mode in VS Code's chat panel to check your xCloud backups, take one before a merge and create a staging copy of the branch you are working on.

  • Skill: xcloud:sites
  • Toolsets: sites
  • Free with every xCloud account

YouBefore I merge this PR, check the production backup and take a new one.

sites_backupStatusread-only

AgentNative site. Daily schedule is on, last backup 22 hours ago, completed. Taking a fresh one before the merge.

sites_backup

AgentCompleted and stored locally. You can merge. To restore later, use Site > Site Backup > Previous Backups > Restore in the dashboard.

. Keep a human in the loop: xCloud stops and asks before anything that creates, deploys, updates, reboots, deletes or buys.

Setup

How Do You Set Up GitHub Copilot to Back up and stage sites on xCloud?

Connect GitHub Copilot once; every job on this account uses the same connection. Then ask in plain words.

  1. Add xCloud to .vscode/mcp.json

    Create or open .vscode/mcp.json in your workspace and paste this. VS Code uses a top-level servers key, not mcpServers, and a remote server needs type http. The URL carries profile=compact because VS Code allows at most 128 tools in one chat request and the full xCloud server advertises one tool per customer-facing operation, 188 today; the compact profile is five tools that still reach every operation. Start the server from MCP: List Servers. xCloud then asks you to sign in in the browser, where you tick the teams and choose Read-only or Full access.

    JSON
    {
      "servers": {
        "xcloud": {
          "type": "http",
          "url": "https://app.xcloud.host/mcp?profile=compact"
        }
      }
    }
  2. Or add it from the Command Palette

    Open the Command Palette and run this command, follow the prompts to add a remote HTTP server, paste https://app.xcloud.host/mcp?profile=compact and name it xcloud. VS Code asks where to save it; pick the workspace to share the entry with your team, or your user profile to keep it to yourself.

    Code
    MCP: Add Server
  3. Add the Agent Plugins package

    Optional. The xCloud Agent Plugins package bundles plugin.json, mcp.json and the nine skills for GitHub Copilot and VS Code. Download it from the xcloud-agent-skills GitHub Releases page (dist/agent-plugin/xcloud) and follow VS Code's agent plugin instructions to install it.

    URL
    https://github.com/xCloudDev/xcloud-agent-skills
  4. Check it worked

    Then ask GitHub Copilot for the job itself, for example:

    Prompt
    Is the production site for this repo backed up? Show the last backup time and its status.

In practice

How Does Backups and staging Work from GitHub Copilot?

In VS Code the natural moment for this job is a pull request that is about to merge. You have the branch checked out, the Source Control view shows the diff, and the Copilot chat panel is already in agent mode. Ask it whether the production site is backed up, and Copilot calls the xcloud tools that VS Code listed under MCP: List Servers. For a native site it reads sites_backupSettings, sites_backupStatus and sites_backups, and for a Docker app the sites_docker_backup read operations, then answers in the panel with the schedule, the time of the last backup, the result and where it is stored. You can read that answer next to the code it protects.

Taking the backup is one more line in the same chat. Ask Copilot to back up the site that this branch deploys to and to say when it has finished. xCloud treats a backup as routine and starts it without a confirmation, but VS Code normally shows a confirmation dialog the first time an agent tool runs, so you may see an Allow prompt from VS Code even though xCloud asks nothing. Copilot tells you first when a Docker app will be stopped briefly while its volumes are captured, and it reports completed or failed after reading the result rather than after queueing the job. Then you merge with a recovery point behind you. If something goes wrong later, the restore itself is a dashboard step, Site > Site Backup > Previous Backups > Restore, and Copilot gives you that path.

Staging suits the pull request workflow too. Copilot can read the branch name from the workspace and propose a staging environment for a Laravel, Node.js, custom PHP or Lovable site, stating the site and branch and waiting for your approval before it calls sites_stagingSites_create. It needs a paid plan, and Copilot says so if xCloud refuses. Because the entry lives in .vscode/mcp.json, a teammate who opens the same workspace gets the same xcloud server and can ask the same questions after signing in with their own xCloud account. WordPress staging is a dashboard step, and Copilot says so with the path.

GitHub Copilot specific: VS Code reads .vscode/mcp.json with a servers key and needs type http for a remote entry. If Copilot cannot find backup tools, open MCP: List Servers and check that xcloud is running, then check the agent's tool picker. In an organization that manages Copilot through GitHub policies, an administrator may restrict MCP servers, and then the backup request will not run at all.

What xCloud does for backups and staging

xCloud lets the agent read every site's backup state, start a backup on demand for native and Docker sites, and create a staging environment for Git sites. Restores, storage providers and WordPress staging stay in the dashboard, and the agent tells you the exact path when you ask for one.

  1. Find the site. The agent resolves the site by name or domain, restates which one it is about to act on, and reads whether it is a native site or a Docker app, because the two use different backup operations.
  2. Read the protection state. It reads the backup settings, status, count and recent backups. That answers whether the site has a schedule, when the last backup ran, whether it succeeded and where it is stored, before anything is changed.
  3. Back up now. A backup starts without an approval prompt. A native site takes a local backup by default or a remote one when a storage provider is connected. A Docker app is stopped briefly while its volumes are captured, so the agent says so before it backs up a production app.
  4. Wait for the result. xCloud queues the backup and returns straight away. The agent follows the backup task or row until it is terminal, then reports completed or failed instead of treating the queued response as done.
  5. Stage the change. For a Git site such as Laravel, Node.js, custom PHP or Lovable, the agent creates a staging environment from the branch you name, after you approve, and gives you its URL. A WordPress staging site is a dashboard step, and the agent gives you the path.
  6. Hand off restores and settings. If you ask to restore a backup, change a native site's schedule or add a storage provider, the agent explains that these are dashboard-only and gives the path and the site's dashboard link. It never improvises a workaround.

Reference

Backups and staging Settings and Limits on xCloud

The facts GitHub Copilot works within when it backs up and stage sites. Where a row names the dashboard, that step stays yours to take there.

Setting or limitWhat applies
Native site backupOn demand through the API; the type is local (the default) or remote. A remote backup needs a storage provider with a working connection, otherwise xCloud refuses it with a 422 before anything is queued
Docker app backupOn demand through the API for Compose deploys and most one-click apps. The app is cold-stopped for a moment while volumes are captured. A remote copy goes to an S3-compatible or SFTP provider; Google Drive and pCloud are not supported for Docker apps
Reading backupsBackup list, count, status and settings are readable for every site. Docker apps also expose one backup's detail
Docker backup housekeepingThe agent can label a Docker backup with a note and delete one. Deleting is irreversible, so it names the exact backup by date and note first
Native schedule and retentionRead-only through the API. Change them in the dashboard under Site > Site Backup > Backup Settings
Docker backup settingsWritable through the API: automatic backup on or off, daily, weekly or monthly frequency, and the number of days to keep backups
RestoresDashboard-only for every site type: Site > Site Backup > Previous Backups > Restore. A backup can also be restored to another site from the same page
Storage providersDashboard-only, under Integrations > Storage Provider. Backup settings return a provider's identifier and status, never its credentials
Team-wide backup policyApplying one backup policy to many sites is dashboard-only, under Global Settings > Site Backup
Git stagingCreated through the API for Git sites on paid plans. On the free plan xCloud answers 403 because it is a plan limit, not a permission
WordPress stagingDashboard-only: xCloud answers 422 when the API is asked for it. Push and pull between staging and production also happen in the dashboard
SnapshotsSnapshots are listed per site. The server-wide snapshot list holds site snapshots, not a server image. Taking or restoring a snapshot, and a whole-server provider backup, stay in the dashboard

Rules GitHub Copilot has to follow

  • A backup runs without an approval prompt, but the agent says when it briefly stops a Docker app and does not trigger one on a busy production app without telling you.
  • A queued backup is not a finished backup: the agent reports completed or failed only after it has read the result.
  • Restoring a backup, changing a native site's schedule, adding a storage provider and creating WordPress staging are dashboard steps; the agent gives you the path instead of guessing an operation.
  • Creating a staging environment stops for your approval, and deleting a backup names the exact backup first.
  • Before you push staging data to production in the dashboard, take a backup of the production site so you can recover if the push goes wrong.

Example prompts

What Can You Ask GitHub Copilot to Do for Backups and staging?

Type these as written and swap in your own repository, site and server names. Reads and routine actions such as backups, cache purges, PageSpeed scans and vulnerability scans run straight away; creating, deploying, updating, rebooting, deleting, buying or starting a broken-link scan stops and asks first.

Prompt
Is the production site for this repo backed up? Show the last backup time and its status.
Prompt
Back up the site this branch deploys to and tell me when it is completed, so I can merge the pull request.
Prompt
Create a staging environment for the API site from my current branch and show me the staging URL.
Prompt
When was the last backup of the shop site, did it succeed, and where is it stored?
Prompt
Check the backup settings on every site and list the ones with no schedule.
Prompt
Take a backup of the n8n Docker app now, before I upgrade it, and tell me when it is done.
Prompt
Switch the n8n Docker app to a daily backup and keep backups for 14 days. Show me the change before you apply it.
Prompt
Create a staging environment for the API site from the feature/checkout branch and give me its URL.
Prompt
List the snapshots of the shop site and tell me which is newest.
Prompt
I need to restore the shop site to last night's backup. Tell me where to click.

GitHub Copilot and Backups and staging: Frequently Asked Questions

What people ask before they let GitHub Copilot back up and stage sites through xCloud.

Why did VS Code ask me to allow a backup if xCloud does not?

xCloud runs a backup without a confirmation, but VS Code has its own prompt before an agent tool runs. That prompt comes from VS Code, not from xCloud. Creating a staging environment always stops for an explicit confirmation as well.

Can my teammates use the same Copilot setup for backups?

Yes. If .vscode/mcp.json is committed, anyone who opens the workspace gets the xcloud server and signs in with their own xCloud account. What they can do depends on the teams and access level they approve, so a Read-only sign-in can check backups but cannot start one.

Can an AI agent restore a backup for me?

No. Restoring a native or Docker backup is a dashboard step, under Site > Site Backup > Previous Backups > Restore. The agent can list the backups, tell you which one is newest and completed, and give you the site's dashboard link so you can start the restore yourself.

Does the agent ask before it takes a backup?

No. A backup is a routine action, so xCloud runs it without a confirmation prompt. For a Docker app the agent tells you first that the app stops briefly while its data is captured, and it reports the result only after the backup has finished.

Can the agent change my backup schedule?

For Docker apps, yes: it can turn automatic backups on or off, set daily, weekly or monthly, and set how many days backups are kept. For native sites the schedule, retention and destination are read-only through the API, so you change them in the dashboard under Site > Site Backup > Backup Settings.

Can the agent connect my S3 bucket or other storage?

No. Storage providers are added in the dashboard, under Integrations > Storage Provider, so credentials never pass through a chat. Once a provider exists, the agent can read which one a site's backup settings point at and use it for a remote backup.

Can the agent create a staging site for WordPress?

Not through the API. xCloud answers 422 for WordPress staging, so you create it in the dashboard from the site overview. For Laravel, Node.js, custom PHP and Lovable sites the agent can create a staging environment, which needs a paid plan.

Other agents

Backups and staging with Other Agents

The same job, the same xCloud tools, a guide for each client.

Run Your Hosting from GitHub Copilot

xCloud MCP, the Agent Skills and the Public API are free with every account. Connect once and ask.