Claude Cowork + xCloud
Deploy from Git with Claude Cowork on xCloud
Deploying from Git with Claude Cowork means handing Anthropic's desktop agent a whole rollout, one repository or several, and letting it work through detection, a dry run, your approval and a live check on xCloud before it comes back with a report.
- Skill: xcloud:deploy
- Toolsets: sites, servers, integrations
- Free with every xCloud account
YouPut the shop and blog repositories on staging hostnames on Frankfurt. Show me both dry runs, then wait.
git_detectread-only
git_detectread-only
AgentShop is a Node.js app with one warning about a missing environment file. Blog is a WordPress site and needs no build step. Both fit the Frankfurt server. I am ready to create both. Approve?
YouApprove both.
servers_sites_git_autoneeds approval
AgentShop is deployed and answers 200. Blog is still running its last step, and I will report when it is terminal.
. 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 Claude Cowork to Deploy from Git on xCloud?
Connect Claude Cowork once; every job on this account uses the same connection. Then ask in plain words.
Add xCloud as a custom connector
In Cowork, open Customize, then Connectors, and choose Add custom connector. If you already added xCloud to your Claude account, look for it in that list first. Name it xcloud, use this URL and sign in when the xCloud approval page opens.
https://app.xcloud.host/mcpCheck the connection
Start a task and ask this first. Claude Cowork calls xCloud and names your account and the teams you approved, so you know the connector works before you delegate real work.
Who am I on xCloud?Match the access level to the job
Optional. On the xCloud approval screen, Full access lets a delegated job deploy, update plugins and renew certificates; Read-only is enough for audits and reports. To change the level later, reconnect the connector and approve again. A Team or Enterprise owner adds the same URL under Organization settings, then Connectors.
https://app.xcloud.host/mcpCheck it worked
Then ask Claude Cowork for the job itself, for example:
Deploy these three repositories to my Frankfurt server on staging hostnames: github.com/acme/shop, github.com/acme/blog and github.com/acme/api. Show me every dry run together before you create anything.
In practice
How Does Deploy from Git Work from Claude Cowork?
Cowork is built for jobs you describe as an outcome rather than a sequence of messages, and a Git deploy fits that shape when there is more than one of them. A typical request is to put three client repositories on staging and tell you the addresses when they answer. Cowork takes the whole list, runs xCloud's detection against each repository, and keeps the results side by side, so you get one summary of app types, branches, commands and warnings instead of three separate conversations. It asks which server each one belongs on when you have not said, and it never picks a server silently, because xCloud's own rules for this job require you to choose.
The pause points matter more here than in chat, because you may not be watching. Detection and the dry run create nothing, so Cowork can do them without you and present what it found. The create call is different: xCloud refuses it without an explicit confirmation, so the task stops and asks you, naming the server and the address, before any site exists. Approve Full access when you connect the xCloud connector, because creating a site is a write and Read-only access cannot do it. When you approve, Cowork sends the confirmed request with an idempotency key, so a retry cannot create a duplicate. It then watches each site until the state is terminal, reads the failed steps, fetches the address and reports which sites are live and which are not.
Cowork also suits the recovery work that follows a batch. If one of the three fails, it reads the deployment diagnosis for that site, explains the cause, proposes a correction from the fields xCloud lets it change and retries on the same site after you say yes. Two failed retries with the same cause stop the loop and hand you the dashboard link. Because it is a desktop agent working through a task, it can keep the finished sites in its report while it waits for your decision on the broken one.
Claude Cowork specific: A delegated task will stop at the create call and wait for you, which is correct but easy to miss if you walk away, so check the task for a pending approval. Reads are enough for detection, but the connector needs Full access to create a site, and the level is fixed when you connect, so reconnect and approve Full access if Cowork says the create was refused. Cowork reaches xCloud from Anthropic's cloud, so it can only deploy repositories that xCloud itself can read.
What xCloud does for deploy from git
xCloud detects the app in the repository, previews the site it would create with a dry run, creates it once you approve, polls the deployment to a terminal state and checks the live URL. A failed deploy gets a diagnosis and a corrected retry on the same site, never a delete and recreate.
- Pick the team and server. The agent uses the server you name. If you name none it lists provisioned servers and asks; it never picks one silently. Node.js, PHP and static builds need an Nginx or OpenLiteSpeed server; anything else needs a Docker server.
- Detect the repository. git_detect reads the default branch, the app type (WordPress, Laravel, custom PHP, Node.js or Lovable), the web root, suggested install, build and start commands, repository access and server compatibility. Detection creates nothing.
- Choose the address. With no domain the agent asks xCloud for a free staging hostname. With a live domain it checks whether the zone is on a connected Cloudflare account, in which case xCloud writes the DNS record and certificate itself.
- Dry run, then one approval. The agent sends the create request with dry_run set to true and shows you the resolved configuration: app type, URL, branch, commands, runtime version and every warning. Then it asks once, naming the server and the URL, before sending the same body with confirm set to true and an idempotency key.
- Poll and verify. A 202 means queued, not deployed. The agent polls the site status until it is terminal, reports each real step change, reads failed_steps and the SSL block, and fetches the URL before it calls the site live.
- Recover if it fails. On a failed deploy the agent reads the deployment diagnosis, proposes a fix from the correctable fields, and retries on the same site with your approval. Two failed retries with the same classification stop the loop and hand you the dashboard link.
Reference
Deploy from Git Settings and Limits on xCloud
The facts Claude Cowork works within when it deploys from Git. Where a row names the dashboard, that step stays yours to take there.
| Setting or limit | What applies |
|---|---|
| Supported app types | WordPress, Laravel, custom PHP, Node.js and Lovable on native servers; Dockerfile and Compose apps, including Python, Go and Rust, on Docker servers |
| Repository sources | Public HTTPS URLs, repositories on a connected GitHub, GitLab or Bitbucket provider, and private SSH repositories with a read-only deploy key |
| Private repositories | The agent prepares a deploy key on the server, you add the public key to the repository, xCloud verifies it. A private key or personal token never goes in the request |
| Preview | dry_run: true returns the would_create block and consumes no idempotency key |
| Idempotency | The create call carries an Idempotency-Key, so a retried request cannot create a duplicate site. A new deployment needs a new key |
| Deployment states | deployed, failed or cancelled once terminal is true; failed_steps can be non-empty on a deployed site and must be read |
| Node.js versions | The Node version is server-wide, not per site; changing it can affect other apps on the server |
| Redeploys | A redeploy runs git reset --hard and git clean -df in the site directory, so uncommitted server-side changes are lost. Supply environment values through env_file_content, not files in the checkout |
| Staging environments | Available for Git sites on paid plans through the API; WordPress staging stays a dashboard step |
| Agentic servers | An OpenClaw, Hermes, Paperclip or DeepSeek Harness server hosts only the site created at provisioning; a second site is refused |
Rules Claude Cowork has to follow
- Creating a site is billable and stops for your approval; detection and the dry run never create anything.
- The agent explains every detection warning before asking, and a repository access problem is never worked around by naming an app type by hand.
- A deployed state is not proof the application works: the agent fetches the URL and reads failed_steps first.
- A failed site is retried in place with corrections; it is never deleted and recreated to retry.
- Changing a live site's domain after creation, databases and server resizing are dashboard steps; the agent gives you the path and the dashboard link xCloud returned.
Example prompts
What Can You Ask Claude Cowork to Do for Deploy from Git?
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.
Deploy these three repositories to my Frankfurt server on staging hostnames: github.com/acme/shop, github.com/acme/blog and github.com/acme/api. Show me every dry run together before you create anything.Detect these two repositories and tell me which need a Docker server and which can go on my Nginx server. Do not create anything yet.Last night's deploys of the shop and api sites failed. Diagnose each, list the fix you would make, and wait for my approval before retrying.Deploy https://github.com/acme/shop to my Frankfurt server and show me the dry run before creating anything.Deploy the private GitLab repository connected to my team on a staging hostname.Scan the docker-compose.yml in github.com/acme/api and tell me which services and ports xCloud would use.Create a staging environment from the feature/checkout branch of the API site.Deploy the latest commit of the shop site after showing me what will change.The last deploy of the API site failed. Diagnose it, fix the build command and retry on the same site.Claude Cowork and Deploy from Git: Frequently Asked Questions
What people ask before they let Claude Cowork deploy from Git through xCloud.
Can Claude Cowork deploy several repositories in one task?
Yes. It detects each repository, shows the dry runs together and waits for your approval before it creates any site. After you approve, it watches each deploy to a terminal state and reports which sites are live and which failed.
Why did Claude Cowork stop before creating my site?
Creating a site is billable, so xCloud refuses the call without an explicit confirmation and the task pauses for your approval. If it reports the call was refused for access, reconnect the xCloud connector and approve Full access, because Read-only cannot create a site.
Does the agent create the site as soon as I give it a repository URL?
No. It detects the repository and runs a dry run first, shows you the resolved configuration, and asks once. Only after you approve does it send the create call with an explicit confirmation and an idempotency key.
Can an agent deploy a private repository through xCloud?
Yes. Either the repository is on a Git provider connected to your xCloud team, or the agent prepares an SSH deploy key on the server for you to add to the repository. A private key or a personal access token is never sent in the request.
What does a 202 response mean during a deploy?
That xCloud queued the deployment. The agent polls the site status until it is terminal and reports deployed, failed or cancelled, then checks failed_steps and fetches the URL before calling the site live.
What happens when a deploy fails?
The agent reads the deployment diagnosis, which classifies the failing step and quotes the relevant log lines, proposes a fix from the fields xCloud lets it correct, and retries on the same site after your approval. It never deletes and recreates the site to retry.
Which servers can take a Git deploy?
Node.js, PHP and static builds deploy to Nginx or OpenLiteSpeed servers. Dockerfile and Compose apps, and other language stacks, need a Docker server. Agentic servers running OpenClaw, Hermes, Paperclip or DeepSeek Harness take no additional sites.
Other agents
Deploy from Git with Other Agents
The same job, the same xCloud tools, a guide for each client.
- Deploy from Git with Claude CodeAnthropic's terminal coding agent. One claude mcp add command, plus the xCloud skills plugin with nine skills on top.
- Deploy from Git with ClaudeAnthropic's chat assistant on the web and desktop. Add xCloud as a custom connector, no terminal needed.
- Deploy from Git with CursorThe AI code editor. One mcp.json entry with the compact URL, because Cursor stops at 40 tools.
- Deploy from Git with CodexOpenAI's coding agent for the terminal. A codex mcp add command or a config.toml entry, then codex mcp login.
- Deploy from Git with OpenCodeThe open-source terminal coding agent. One remote MCP entry, then opencode mcp auth xcloud.
- Deploy from Git with Hermes AgentNous Research's agent with memory and a built-in scheduler. An mcp_servers entry in config.yaml and one login.
- Deploy from Git with OpenClawThe open-source agent runtime with chat apps and automations. ClawHub skill plus the MCP client.
- Deploy from Git with WindsurfThe Cognition editor, now Devin Desktop. devin mcp add for the Devin Local agent, a serverUrl entry for legacy Cascade.
- Deploy from Git with GitHub CopilotCopilot agent mode in VS Code. One .vscode/mcp.json entry, or the Agent Plugins package.
- Deploy from Git with Gemini CLIGoogle's terminal agent. One gemini mcp add command, OAuth found automatically.
- Deploy from Git with ChatGPTOpenAI's chat assistant. A developer-mode app with the xCloud MCP URL and OAuth.
- Deploy from Git with ChatGPT dotsOpenAI's always-on agent in ChatGPT. Uses the xCloud MCP plugin you add in ChatGPT, with custom rules and scheduled tasks.
- Deploy from Git with GrokxAI's terminal agent, Grok Build. One grok mcp add command or a config.toml entry.
- Deploy from Git with Grok BotxAI's always-on Bots on a cloud computer. One Remote HTTPS MCP plugin, OAuth sign-in, routines on a schedule.
- Deploy from Git with KiroAWS's agentic IDE. One url entry in .kiro/settings/mcp.json, plus the portable xCloud Agent Plugins package.
- Deploy from Git with AntigravityGoogle's agentic IDE. One serverUrl entry in mcp_config.json and a browser sign-in.
- Deploy from Git with ZedThe Zed editor's Agent Panel. One context_servers entry in settings.json and a browser sign-in.
More Claude Cowork guides
- Claude Cowork and xCloud overview
- Run Docker apps with Claude Cowork
- Install one-click apps with Claude Cowork
- Manage WordPress with Claude Cowork
- Back up and stage sites with Claude Cowork
- Manage SSL and domains with Claude Cowork
- Manage servers with Claude Cowork
- Troubleshoot a broken site with Claude Cowork
- Speed up a slow site with Claude Cowork
- Secure sites and servers with Claude Cowork
Run Your Hosting from Claude Cowork
xCloud MCP, the Agent Skills and the Public API are free with every account. Connect once and ask.