Claude + xCloud

Deploy from Git with Claude on xCloud

Deploying from Git with Claude means pasting a repository link into a chat on claude.ai or in Claude Desktop and letting the xCloud connector detect the app, preview the site, create it once you approve and check that the live URL answers.

Skill: xcloud:deploy
Toolsets: sites, servers, integrations
Free with every xCloud account

Set up Claude All Claude guides

YouDeploy github.com/acme/shop to my Frankfurt server on a staging hostname. Dry run first.

git_detectread-only

AgentIt is a Node.js app on the main branch. xCloud would run npm run build and npm start, serve from dist, and use a free staging hostname. One warning: there is no environment file in the repository. Shall I create the site?

YouYes, go ahead.

servers_sites_git_autoneeds approval

AgentQueued, then deployed. The staging address answers 200 and the certificate is issued. Here is the dashboard link for the site.

Last updated: October 2026. 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 to Deploy from Git on xCloud?

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

1
Add xCloud as a custom connector
In Claude, open Customize, then Connectors, and choose Add custom connector. Name it xcloud, paste this URL as the remote MCP server URL and finish the setup. Claude shows the xCloud sign-in page; choose the teams and Read-only or Full access.
URL
```
https://app.xcloud.host/mcp
```
2
Check the connection
Start a new chat, check that the xcloud connector is enabled for it, and ask this. Claude calls xCloud and names your account and the teams you approved.
Prompt
```
Who am I on xCloud?
```
3
On Team or Enterprise, add it as an owner
Members cannot add custom connectors on a Team plan. An Owner or Primary Owner adds it under Organization settings, then Connectors, with the same URL. On Enterprise, a custom role with Manage access to Libraries can add it too.
URL
```
https://app.xcloud.host/mcp
```

Check it worked

Then ask Claude for the job itself, for example:

Prompt

Deploy https://github.com/acme/shop to my Frankfurt server on a staging hostname. Show me the dry run and wait for my yes before creating anything.

In practice

How Does Deploy from Git Work from Claude?

Claude in a chat window has no checkout of your code. It does not see your working folder, your current branch or the scripts in package.json, so the repository has to come from you. Paste a GitHub, GitLab or Bitbucket URL, or write acme/shop, and name the server you want. Claude passes that to xCloud, which reads the repository itself, so a public repository needs nothing else. This is the chat to use when you are the person who owns the hosting but not the person who has the code open, such as an agency owner shipping a client's repository or a founder launching a project a developer pushed yesterday.

What you see is a conversation with tool cards in it. Claude calls git_detect and tells you in plain sentences what xCloud found: the app type, the branch, the commands it would run and any warning, such as a missing environment file. If you have not named an address, it asks xCloud for a free staging hostname and shows it. It then sends the create request as a dry run and describes the site it would make. You reply yes once, in the chat. Claude sends the confirmed create call through the connector with an idempotency key, then keeps checking the site status and tells you when the state is terminal. It reads the failed steps and the certificate before it says the site is live, and it hands you the dashboard link xCloud returned instead of a link it made up.

Private repositories work through the chat too, with one hand-off. If the repository is on a Git provider connected to your xCloud team, detection simply works. If it is not, Claude can ask xCloud to prepare an SSH deploy key on the server and show you the public key, which you add to the repository as read-only in your Git provider, then you tell Claude to carry on. When a build fails, Claude reads the deployment diagnosis and explains it in plain words. It can propose a changed build command or web root and retry on the same site, but it cannot change your code. A fix inside the repository goes back to whoever holds the code, or to a coding agent.

Claude specific: Claude reaches xCloud from Anthropic's cloud, and it only knows the repository you name. It cannot see local folders, unpushed commits or files on your machine, so push first and paste the link. The Free Claude plan allows a single custom connector in total, so if xCloud is not in the connector list for a chat, check that it is enabled there and that another connector has not taken the one slot.

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 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 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 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.

Prompt

Deploy https://github.com/acme/shop to my Frankfurt server on a staging hostname. Show me the dry run and wait for my yes before creating anything.

Prompt

My last deploy of the shop site failed. Read the deployment diagnosis, tell me in plain words what went wrong and what you would change before retrying.

Prompt

Here is a private GitLab repository my team connected to xCloud: gitlab.com/acme/api. Check it can be reached, then tell me which server it should go on.

Prompt

Deploy https://github.com/acme/shop to my Frankfurt server and show me the dry run before creating anything.

Prompt

Deploy the private GitLab repository connected to my team on a staging hostname.

Prompt

Scan the docker-compose.yml in github.com/acme/api and tell me which services and ports xCloud would use.

Prompt

Create a staging environment from the feature/checkout branch of the API site.

Prompt

Deploy the latest commit of the shop site after showing me what will change.

Prompt

The last deploy of the API site failed. Diagnose it, fix the build command and retry on the same site.

Claude and Deploy from Git: Frequently Asked Questions

What people ask before they let Claude deploy from Git through xCloud.

Can Claude deploy a repository that only exists on my computer?

No. Claude in a chat connects to xCloud from Anthropic's cloud and never sees your local folders. Push the code to GitHub, GitLab or Bitbucket first, then paste the repository link into the chat so xCloud can read it.

Does Claude ask before it creates the site?

Yes. It detects the repository and runs a dry run first, describes the site it would create, and asks you once. Only after your yes does it send the create call with an explicit confirmation, and xCloud refuses a create without one.

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