OpenClaw + xCloud

Deploy from Git with OpenClaw on xCloud

Deploying from Git with OpenClaw means messaging your self-run agent runtime on WhatsApp, Telegram, Slack or Discord with a repository link, and letting its xCloud skill and MCP connection detect the app, preview the site, create it after your approval and confirm the live URL.

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

Set up OpenClaw All OpenClaw guides

YouDeploy github.com/acme/shop to Frankfurt on staging. Dry run first.

git_detectread-only

AgentNode.js app on main, build npm run build, start npm start. Staging address: shop-preview.acme.xcloud.site. Warning: no environment file in the repo. Create the site? Reply yes.

Youyes

servers_sites_git_autoneeds approval

AgentDeployed and answering 200 at https://shop-preview.acme.xcloud.site. Want push-to-deploy turned on?

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 OpenClaw to Deploy from Git on xCloud?

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

1
Install the xCloud skill from ClawHub
This installs the nine xCloud skills into the active workspace skills folder. Add --global to install them into ~/.openclaw/skills for every local agent. The clawhub CLI installs the same listing with clawhub install xcloud.
Terminal
```
openclaw skills install @asif2bd/xcloud
```
2
Add the xCloud MCP server and sign in
Run these on the installation that owns the connector. The --auth oauth flag matters: openclaw mcp login only runs for HTTP servers saved with OAuth, so without it the login is refused. The login prints an authorization URL, and OpenClaw normally captures the redirect on a loopback address and saves the credentials; Settings, MCP, Sign in in the Control UI does the same. On the xCloud approval screen tick the teams and choose Read-only or Full access.
Terminal
```
openclaw mcp add xcloud \
  --url https://app.xcloud.host/mcp \
  --transport streamable-http \
  --auth oauth
openclaw mcp login xcloud
```
3
Check the skill and the connection
The first command lists the skills that are eligible to run in this environment, and xcloud should be among them. The second opens a live connection and reports the tools the server offers. A saved server entry proves nothing until the probe passes. Then ask who am I on xCloud.
Terminal
```
openclaw skills list --eligible
openclaw mcp doctor xcloud --probe
```

Check it worked

Then ask OpenClaw for the job itself, for example:

Prompt

Deploy github.com/acme/shop to my Frankfurt server on a staging hostname. Send me the dry run here and wait for my yes.

In practice

How Does Deploy from Git Work from OpenClaw?

OpenClaw is the agent you leave running. It lives on a machine or server you own and answers in the chat app you already use, so a deploy usually begins as a message, not a command: a repository link, a server name, maybe a word about staging. Two things sit behind that message. The xCloud skill from ClawHub carries the deploy method, which is why the agent detects before it creates, shows a dry run and asks once. The MCP client carries the tools, git_detect, servers_sites_git_auto, sites_status and the rest. The pair matters for this job in particular, because the skill on its own falls back to a GET-only REST wrapper. That can look at a repository, but it cannot create the site.

In the chat you see short messages, not tool cards. OpenClaw reports what detection found, names the staging hostname it would use, posts the dry run summary and waits. You reply yes in the same conversation and it sends the confirmed create call, then reports step changes as the deploy runs and finishes with the URL it fetched. A private repository adds one hand-off. If the repository is not on a connected Git provider, the agent can have xCloud prepare an SSH deploy key on the server and post the public key into the chat, you add it to the repository as read-only, and you tell it to carry on. The private key never appears in the conversation.

Automations give you the unattended half. openclaw automations create runs a prompt on a cron expression in an isolated session and can announce the result in a channel, so a weekday-morning job can run detection and a dry run for the repositories you care about and post any new warning. It cannot create a site on its own, because xCloud refuses the create call without an explicit confirmation, which is the behaviour you want from a job nobody is watching. The same chat works afterwards for the failed-build loop: ask what went wrong, read the diagnosis it posts, and approve a corrected retry on the same site.

OpenClaw specific: Install and probe before you rely on a chat message. Run openclaw skills list --eligible to see xcloud, and openclaw mcp doctor xcloud --probe to see the tools, because a saved entry proves nothing until the probe passes and a Gateway on another host needs its own reload. Also pick the target server with care. If OpenClaw runs on an xCloud agentic server, that server hosts only the site created at provisioning and refuses a second one, so the app you are deploying needs a different server.

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 OpenClaw 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 OpenClaw 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 OpenClaw 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 github.com/acme/shop to my Frankfurt server on a staging hostname. Send me the dry run here and wait for my yes.

Prompt

github.com/acme/api is private. Check whether xCloud can reach it, and if not, set up a deploy key and send me the public key to add.

Prompt

Every weekday at 8am, run detection and a dry run for github.com/acme/shop and post any new warning in this chat. Create nothing.

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.

OpenClaw and Deploy from Git: Frequently Asked Questions

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

Why does OpenClaw need the MCP connection to deploy, not just the skill?

The skill teaches the method, but its REST fallback is GET-only, so it can detect and read but cannot create a site. The create call goes through the MCP connection, which is why you install both and check with openclaw mcp doctor xcloud --probe.

Can an OpenClaw automation deploy my repository every night?

It can run detection and a dry run every night and post the result to a channel. It cannot create or redeploy a site unattended, because xCloud refuses those calls without an explicit confirmation. Approve the deploy in a message when you have read the preview.

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