Grok Bot + xCloud

Run Docker apps with Grok Bot on xCloud

Running Docker apps with Grok Bot means asking one of your Bots to have xCloud scan a Dockerfile or Compose repository, deploy it to a Docker server after your approval and keep it backed up, so the work carries on while your laptop is closed.

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

Set up Grok Bot All Grok Bot guides

You@xcloud Scan the compose file in github.com/example/api, then deploy it to the Docker server on a staging hostname.

git_compose-scanread-only

AgentTwo services: web and db. Only web publishes a port, 127.0.0.1:8080, so xCloud would proxy to 8080. Sending the dry run to the Docker server.

servers_sites_git_dockerdry run

AgentThe dry run resolved docker-compose.yml and port 8080 with no warnings. Create the app on the Docker server?

YouYes.

servers_sites_git_dockerneeds approval

sites_statusread-only

AgentI polled the status: queued, then deployed, with no failed steps and the certificate issued. https://api-test.example.xcloud.site answers 200.

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 Grok Bot to Run Docker apps on xCloud?

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

1
Ask a Bot to add xCloud as a Remote HTTPS MCP server
In the Grok Bot desktop app, open any Bot's chat and ask it to add a custom MCP server of the Remote HTTPS kind, named xcloud, with this URL. The Bot adds it as a personal plugin from your own chat; the Marketplace in the sidebar only lists catalog connectors. The owner of a Team Bot adds the same kind of server from the Plugins card in the Bot's Setup panel instead. When the browser opens, sign in with xCloud, tick the teams the Bot may act on and choose Read-only or Full access.
URL
```
https://app.xcloud.host/mcp
```
2
Attach it to a task and check it works
In a Bot chat, type @ and pick xcloud to attach the connector to the task, then ask. A plugin you added from your own chat is personal and account-wide, so every Bot on your account can use it; a plugin added from a Team Bot's Setup panel belongs to that Team Bot, so check it in that Bot's chat. Put a standing boundary in the description of each Bot that may touch hosting, for example: never change production without approval.
Prompt
```
@xcloud Who am I on xCloud, and which servers and sites do I have?
```
3
Team Bot without sign-ins? Use an API key
A Remote HTTPS server added from the Plugins card in a Team Bot's Setup panel can run on the Bot's own credential instead of each person's sign-in, which suits a Team Bot that answers hosting questions for everyone. 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, and give the plugin this header where its form asks for one. Everyone who talks to that Bot then acts with the token's access, so keep it read-only unless the team should change things.
Code
```
Authorization: Bearer YOUR_TOKEN
```

Check it worked

Then ask Grok Bot for the job itself, for example:

Prompt

@xcloud Scan the docker-compose.yml in github.com/example/api and tell me which services and host ports it publishes and which port xCloud would use. Create nothing.

In practice

How Does Docker apps Work from Grok Bot?

The Compose file is the center of this job, and a Grok Bot is a good place to review it because a Bot holds one conversation across a whole task. You attach the connector with @xcloud and ask the Bot to scan the Compose file in github.com/example/api before it creates anything. It calls git_detect and git_compose-scan and answers with the services, the host ports the file publishes and the primary port xCloud would proxy to. Read that answer closely. xCloud runs your Compose file as it is and never rewrites its ports mapping, so a file that publishes no port deploys and then answers 502. A Bot that scans first catches it before the site exists and can suggest the line to change, such as publishing 127.0.0.1:8080:8080, for you to commit.

Grok Bot lets one Bot hand work to another, which suits a split most teams already have. A Bot that works on your code finishes its change and hands the task to the hosting Bot, which holds the xcloud plugin and a description that says never change production without approval. You can put both in a group chat and follow the handoff. The deploy itself follows the usual rhythm: a dry run through servers_sites_git_docker, an explicit confirmation from you, then polling with sites_status until the state is terminal. Port refusals come back named, port_unavailable or port_not_published, and the Bot reads them to you instead of retrying with a guessed port.

Backups are the part to plan. A Docker backup holds the named volumes, eligible bind mounts, the Compose file and the app's .env, and the app is stopped while it captures. Ask the Bot for a backup before an upgrade, let it call sites_docker_backup, and have it tell you first that the app will stop for a moment. For recurring protection, the app's own automatic backup setting in xCloud suits a schedule better than a routine. Use a routine for the audit instead: read the backup settings and last backup of every Docker app each week and report the ones with no schedule. Restores replace data in place, so they stay in the dashboard under Site, Site Backup, Previous Backups, and the Bot gives you the path.

Grok Bot specific: Do not treat the Bot's own cloud computer as a place to test your Compose file. Grok Bot has a terminal, but it belongs to a persistent computer in Cursor's cloud: one that your personal Bots share, or, for a Team Bot, the computer of the person talking to it or the shared one a Slack channel uses. It is not your xCloud Docker server, and xCloud does the pulling and building. Ask for the scan and the dry run through @xcloud, and treat anything the Bot says it ran in its own terminal as a separate experiment. The same applies to private registries: the deploy runs docker compose pull and never docker login, so an image from a private registry cannot be pulled whichever Bot asks. The fix is to build the image from source in the Compose file and commit that change.

What xCloud does for docker apps

xCloud reads the repository, scans the Compose file for services and ports before anything is created, previews the site with a dry run and deploys it behind its own nginx once you approve. Docker sites can be backed up on demand and on a schedule, and a failed deploy is diagnosed and retried on the same site.

Pick a Docker server. The agent uses the server you name, or lists your servers and asks. A Docker deploy needs a Docker server; any other stack answers with an incompatible_server refusal, and an agentic server never takes a second site. WordPress is not supported on Docker servers.
Detect the repository. git_detect reads the repository root for a Dockerfile or one of the four Compose file names, and checks access and server compatibility. It creates nothing, and an access problem is never worked around by naming an app type by hand.
Scan the Compose file. git_compose-scan runs before the dry run. It lists the services and the host ports the file publishes, resolves which Compose file name it found, and suggests a primary port. The agent never guesses the port.
Dry run, then one approval. The agent sends the Docker create request with dry_run set to true and shows the resolved configuration: compose file, port, address and warnings. 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 running. The agent polls the site status until it is terminal, reads failed_steps and the SSL block, and fetches the URL before it calls the app live. A 502 here usually means the Compose file publishes no port.
Back up and recover. The agent can take a Docker backup, read the backup list and settings, and add a note to a backup. If a deploy fails it reads the diagnosis, proposes a fix from the correctable fields and retries on the same site after your approval. Restoring a backup is a dashboard step.

Reference

Docker apps Settings and Limits on xCloud

The facts Grok Bot works within when it runs Docker apps. Where a row names the dashboard, that step stays yours to take there.

Setting or limit	What applies
Supported inputs	A Dockerfile for a single container, or a Compose file for one or more services, on a Docker server. Go, Python, Rust and Java apps all deploy this way
Server stack	Docker servers only. The Docker deploy on any other stack, including an agentic server, answers 422 with the code incompatible_server
Which Compose file runs	docker-compose.yml at the repository root. A file named compose.yaml, compose.yml or docker-compose.yaml, or one in a subdirectory, deploys through the pinned Docker create with docker.compose_file set to the path the scan resolved
Public port	xCloud's nginx owns ports 80 and 443 and proxies to one host port of 1024 or higher on 127.0.0.1. xCloud runs your Compose file as-is and never rewrites its ports mapping
Port refusals	A port another site already holds is refused as port_unavailable. A port the file does not publish is refused as port_not_published, with the published ports listed
No published port	A Compose file that publishes no port is accepted and then answers 502, so the scan is the step that catches it
Private registries	The deploy runs docker compose pull and never docker login, so an image from a private registry cannot be pulled. Build the image from source instead
Environment and redeploys	Send environment values through env_file_content. A redeploy runs git reset --hard and git clean -df in the site directory, so uncommitted server-side changes are lost
What a Docker backup holds	Named volumes, eligible bind mounts, the Compose file and the app's .env, in an encrypted snapshot. The app is stopped while the backup captures and restarted afterwards
Backup tools	Take a backup, list backups, read the count and the settings, change the settings, add a note and delete a backup. Remote copies go to a storage provider you add in the dashboard
Restores	A restore replaces the app's data in place, so it stays a dashboard step: Site, Site Backup, Previous Backups, Restore Backup
Dot-prefixed paths	A 403 on a path that starts with a dot is the dot-path allowlist. It is fixed with docker.allowed_dot_paths in the deploy settings, without a rebuild

Rules Grok Bot has to follow

The Compose file is scanned before the dry run, and the port always comes from the scan, never from a guess.
A file that binds ports 80 or 443, publishes no port or pulls from a private registry is not deployed as-is. The agent shows the rewrite, such as publishing 127.0.0.1:<high port>:<app port> and building the image from source, and the change goes into your repository.
Creating a site, deploying, redeploying and deleting a backup stop for your approval. A backup runs without a separate prompt but stops the app while it captures, so ask for one at a quiet time.
A failed Docker site is retried in place with corrections. It is never deleted and recreated, because it keeps its domain and port.
Restoring a backup, adding a backup storage provider and changing a live site's domain are dashboard steps; the agent gives you the path and the dashboard link xCloud returned.

Example prompts

What Can You Ask Grok Bot to Do for Docker apps?

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

@xcloud Scan the docker-compose.yml in github.com/example/api and tell me which services and host ports it publishes and which port xCloud would use. Create nothing.

Prompt

@xcloud Deploy github.com/example/api to my Docker server as a Compose app on a staging hostname. Show me the dry run and wait for my approval.

Prompt

@xcloud Back up the Docker app on notes.example.com now, before I upgrade it. Tell me first that the app will stop briefly, then report when the backup is done.

Prompt

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

Prompt

Deploy github.com/acme/shop to the Frankfurt Docker server as a Compose app. Scan the compose file first, show me the services and ports, then wait for my approval before creating anything.

Prompt

Deploy the main branch of github.com/acme/api to my Docker server as a Compose app on a staging hostname.

Prompt

My Compose app on notes.example.com answers 502. Check which port its compose file publishes and which port xCloud is using.

Prompt

Take a backup of the Docker app on notes.example.com now, before I upgrade it, and tell me when it is done.

Prompt

Show the backup settings and the last backup of every Docker app on this team, and list the ones with no schedule.

Prompt

The last deploy of the API site failed. Diagnose it, show me the settings I can correct, fix the build command and retry on the same site.

Grok Bot and Docker apps: Frequently Asked Questions

What people ask before they let Grok Bot run Docker apps through xCloud.

Can two Grok Bots split a Docker deploy between them?

Yes. Bots can message each other and hand off tasks, so one Bot can change the repository while the Bot that holds the xcloud plugin scans, previews and deploys it. The approval still comes from you, because xCloud asks for an explicit confirmation before it creates the app.

Should I use a Grok Bot routine to back up my Docker app every night?

Use the app's own automatic backup setting in xCloud for the schedule, because each Docker backup stops the app briefly while its volumes are captured. A routine works better as an audit: ask the Bot to read the backup settings and last backup of every Docker app and report the ones with no schedule.

Which servers can run a Docker app on xCloud?

Docker servers. Node.js, PHP and static builds use Nginx or OpenLiteSpeed servers, and the Docker deploy on any other stack is refused with an incompatible_server code. An OpenClaw, Hermes, Paperclip or DeepSeek Harness server hosts only the site created at provisioning, so it takes no Docker app.

Why does the agent scan the Compose file before deploying?

xCloud proxies to the host port your file publishes and never rewrites it. The scan lists the services and ports, so the agent picks a port that is free on the server and published by the file instead of guessing.

Why does my Compose app answer 502 after it deployed?

The most common cause is a Compose file that publishes no port: xCloud accepts it, then its nginx has nothing to proxy to. Publish the app on 127.0.0.1 with a high port, such as 127.0.0.1:8080:8080, and redeploy.

Can an agent deploy an image from a private registry?

Not as-is. The deploy runs docker compose pull and never docker login, so a private image cannot be pulled. Build the image from source in the Compose file, or deploy a repository that does.

Can an agent back up and restore a Docker app?

It can take a backup, read the backup list and settings, change the settings, add a note and delete a backup. Restoring replaces the app's data in place, so you do that in the dashboard under Site, Site Backup, Previous Backups.

Can I run WordPress as a Docker app on xCloud?

No. Creating a WordPress site on a Docker server is refused because WordPress is not supported on Docker servers. Use an Nginx or OpenLiteSpeed server for WordPress.

Other agents