Grok + xCloud
Back up and stage sites with Grok on xCloud
Backing up and staging sites with Grok Build means telling xAI's terminal agent to read your xCloud backup state, take a backup before a risky change and open a staging copy of a Git site, one terse line at a time from your shell.
- Skill: xcloud:sites
- Toolsets: sites
- Free with every xCloud account
YouBack up the n8n app, then switch it to a daily backup and keep 14 days.
sites_docker_backupSettingsread-only
Agentn8n is a Docker app with automatic backup off. A backup stops it for a moment. Backing up now.
sites_docker_backup
AgentBackup completed. Proposed change: automatic backup on, daily, keep 14 days. Apply it?
. 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 Grok to Back up and stage sites on xCloud?
Connect Grok once; every job on this account uses the same connection. Then ask in plain words.
Add the xCloud MCP server
Run this in your terminal, then start grok. The first time it calls xCloud, a browser opens on the xCloud approval screen, where you tick the teams and choose Read-only or Full access. Add --scope project to save the entry in .grok/config.toml for one repository instead.
grok mcp add --transport http xcloud https://app.xcloud.host/mcpOr edit ~/.grok/config.toml
Add this table to ~/.grok/config.toml, then run grok mcp doctor xcloud to check the connection. The url key is the one for HTTP servers.
[mcp_servers.xcloud] url = "https://app.xcloud.host/mcp"No browser? Use an API key
For a headless machine, create a token with the mcp:invoke scope plus the read abilities for the areas it will use (read:servers and read:sites, with read:billing and read:addons for billing and add-on tools) and the matching write: abilities if it should change things in Settings, Developers, API Tokens. Put it in an environment variable the machine starts Grok with, such as XCLOUD_TOKEN in a systemd EnvironmentFile or your shell profile, and pass a reference to it with --header. Keep the single quotes so the shell leaves ${XCLOUD_TOKEN} alone: Grok expands ${VAR} in headers when it loads the config, so the token itself never lands in your shell history or in config.toml. Run grok mcp doctor xcloud to confirm it works.
grok mcp add --transport http --header 'Authorization: Bearer ${XCLOUD_TOKEN}' xcloud https://app.xcloud.host/mcpCheck it worked
Then ask Grok for the job itself, for example:
back up api.example.com and show me when the last backup ran
In practice
How Does Backups and staging Work from Grok?
Grok Build lives in the shell, and the prompts that work there are short. In a repository you can type back up shop.example.com now and the agent calls xCloud to find the site, reads the backup list and status, then starts the backup. xCloud puts no approval prompt in front of a backup, so the output is a few lines: which site it matched, whether it is a native site or a Docker app, backup started, backup completed. It does not report completed on the strength of the queued response. It follows the backup until it is terminal, then prints the result, including where the backup was stored.
The same terse style works for an audit. Ask Grok Build to check the backup settings on every site and list the ones with no schedule, and you get a short list you can read in the terminal and act on in the dashboard. Ask it to take a backup of the n8n Docker app before an upgrade and it tells you the app will stop for a moment while the volumes are captured, which is worth knowing before you run it against a production app. Switching a Docker app to a daily backup with 14 days of retention is something it can do, and it shows you the change before it applies it. A native site's schedule is read-only here and belongs to the dashboard.
Staging is one more line: create a staging environment for the api site from feature/checkout. Grok Build asks you to confirm in the terminal, calls xCloud to create it and prints the URL. That needs a paid plan, and on the free plan xCloud says no, which the agent reports as a plan limit. For a WordPress site, or for a restore, it prints the dashboard path instead. Grok at grok.com is a different surface with its own connector settings, and this page is about the terminal agent.
Grok specific: A backup keeps running on xCloud if you close the terminal, but Grok Build's report does not. If you interrupt the session while it is waiting, start a new one and ask for the backup status of the site instead of asking for another backup, because a second backup of a Docker app would stop it a second time. If the xCloud tools do not appear at all, run grok mcp doctor xcloud before anything else.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 Grok works within when it backs up and stage sites. Where a row names the dashboard, that step stays yours to take there.
| Setting or limit | What applies |
|---|---|
| Native site backup | On 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 backup | On 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 backups | Backup list, count, status and settings are readable for every site. Docker apps also expose one backup's detail |
| Docker backup housekeeping | The 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 retention | Read-only through the API. Change them in the dashboard under Site > Site Backup > Backup Settings |
| Docker backup settings | Writable through the API: automatic backup on or off, daily, weekly or monthly frequency, and the number of days to keep backups |
| Restores | Dashboard-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 providers | Dashboard-only, under Integrations > Storage Provider. Backup settings return a provider's identifier and status, never its credentials |
| Team-wide backup policy | Applying one backup policy to many sites is dashboard-only, under Global Settings > Site Backup |
| Git staging | Created 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 staging | Dashboard-only: xCloud answers 422 when the API is asked for it. Push and pull between staging and production also happen in the dashboard |
| Snapshots | Snapshots 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 Grok 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 Grok 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.
back up api.example.com and show me when the last backup rantake a backup of the n8n docker app, then switch it to daily and keep 14 days, show me the change firstcreate staging for the api site from feature/checkout, print the urlWhen was the last backup of the shop site, did it succeed, and where is it stored?Check the backup settings on every site and list the ones with no schedule.Take a backup of the n8n Docker app now, before I upgrade it, and tell me when it is done.Switch the n8n Docker app to a daily backup and keep backups for 14 days. Show me the change before you apply it.Create a staging environment for the API site from the feature/checkout branch and give me its URL.List the snapshots of the shop site and tell me which is newest.I need to restore the shop site to last night's backup. Tell me where to click.Grok and Backups and staging: Frequently Asked Questions
What people ask before they let Grok back up and stage sites through xCloud.
What does Grok Build print when it takes a backup?
A few lines: the site it matched, whether it is a native site or a Docker app, that the backup started and that it completed or failed. It waits for the backup to reach a terminal state before it says so, and it names where the backup is stored.
Does Grok at grok.com work for backups the same way as Grok Build?
Not through this page. This setup is for Grok Build, the terminal agent. The Grok chat at grok.com has its own connector settings, where you can add the same server URL, https://app.xcloud.host/mcp, and check there how it handles tool calls.
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.
- Back up and stage sites with Claude CodeAnthropic's terminal coding agent. One claude mcp add command, plus the xCloud skills plugin with nine skills on top.
- Back up and stage sites with ClaudeAnthropic's chat assistant on the web and desktop. Add xCloud as a custom connector, no terminal needed.
- Back up and stage sites with Claude CoworkAnthropic's desktop agent for delegated work. Add the xCloud connector, then hand off hosting jobs.
- Back up and stage sites with CursorThe AI code editor. One mcp.json entry with the compact URL, because Cursor stops at 40 tools.
- Back up and stage sites with CodexOpenAI's coding agent for the terminal. A codex mcp add command or a config.toml entry, then codex mcp login.
- Back up and stage sites with OpenCodeThe open-source terminal coding agent. One remote MCP entry, then opencode mcp auth xcloud.
- Back up and stage sites with Hermes AgentNous Research's agent with memory and a built-in scheduler. An mcp_servers entry in config.yaml and one login.
- Back up and stage sites with OpenClawThe open-source agent runtime with chat apps and automations. ClawHub skill plus the MCP client.
- Back up and stage sites with WindsurfThe Cognition editor, now Devin Desktop. devin mcp add for the Devin Local agent, a serverUrl entry for legacy Cascade.
- Back up and stage sites with GitHub CopilotCopilot agent mode in VS Code. One .vscode/mcp.json entry, or the Agent Plugins package.
- Back up and stage sites with Gemini CLIGoogle's terminal agent. One gemini mcp add command, OAuth found automatically.
- Back up and stage sites with ChatGPTOpenAI's chat assistant. A developer-mode app with the xCloud MCP URL and OAuth.
- Back up and stage sites with ChatGPT dotsOpenAI's always-on agent in ChatGPT. Uses the xCloud MCP plugin you add in ChatGPT, with custom rules and scheduled tasks.
- Back up and stage sites with Grok BotxAI's always-on Bots on a cloud computer. One Remote HTTPS MCP plugin, OAuth sign-in, routines on a schedule.
- Back up and stage sites with KiroAWS's agentic IDE. One url entry in .kiro/settings/mcp.json, plus the portable xCloud Agent Plugins package.
- Back up and stage sites with AntigravityGoogle's agentic IDE. One serverUrl entry in mcp_config.json and a browser sign-in.
- Back up and stage sites with ZedThe Zed editor's Agent Panel. One context_servers entry in settings.json and a browser sign-in.
More Grok guides
Run Your Hosting from Grok
xCloud MCP, the Agent Skills and the Public API are free with every account. Connect once and ask.