GitHub Copilot + xCloud

Deploy from Git with GitHub Copilot on xCloud

Deploying from Git with GitHub Copilot means asking agent mode in the VS Code chat panel to ship the repository you have open, and letting xCloud detect the app, preview the site, create it after your approval and verify the live URL.

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

Set up GitHub Copilot All GitHub Copilot guides

YouDeploy the repository I have open to Frankfurt on a staging hostname. Dry run first.

git_detectread-only

AgentThis is a Node.js app on main, remote github.com/acme/shop. The commands in package.json match what xCloud suggests. Your branch is up to date with origin. Create the staging site on Frankfurt?

YouYes.

servers_sites_git_autoneeds approval

AgentDeployed. The certificate is issued and the staging URL 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 GitHub Copilot to Deploy from Git on xCloud?

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

1
Add xCloud to .vscode/mcp.json
Create or open .vscode/mcp.json in your workspace and paste this. VS Code uses a top-level servers key, not mcpServers, and a remote server needs type http. The URL carries profile=compact because VS Code allows at most 128 tools in one chat request and the full xCloud server advertises one tool per customer-facing operation, 188 today; the compact profile is five tools that still reach every operation. Start the server from MCP: List Servers. xCloud then asks you to sign in in the browser, where you tick the teams and choose Read-only or Full access.
JSON
```
{
  "servers": {
    "xcloud": {
      "type": "http",
      "url": "https://app.xcloud.host/mcp?profile=compact"
    }
  }
}
```
2
Or add it from the Command Palette
Open the Command Palette and run this command, follow the prompts to add a remote HTTP server, paste https://app.xcloud.host/mcp?profile=compact and name it xcloud. VS Code asks where to save it; pick the workspace to share the entry with your team, or your user profile to keep it to yourself.
Code
```
MCP: Add Server
```
3
Add the Agent Plugins package
Optional. The xCloud Agent Plugins package bundles plugin.json, mcp.json and the nine skills for GitHub Copilot and VS Code. Download it from the xcloud-agent-skills GitHub Releases page (dist/agent-plugin/xcloud) and follow VS Code's agent plugin instructions to install it.
URL
```
https://github.com/xCloudDev/xcloud-agent-skills
```

Check it worked

Then ask GitHub Copilot for the job itself, for example:

Prompt

Deploy the repository I have open to my Frankfurt server on a staging hostname. Show me the dry run before creating anything.

In practice

How Does Deploy from Git Work from GitHub Copilot?

Copilot agent mode lives in the chat panel beside your code, and the workspace you have open is its context: the folder, the Git remote, the branch and the build files. In the panel you type deploy this to my Frankfurt server, and agent mode calls xCloud's detection with the remote it found. It reports the app type, the suggested install, build and start commands and any warning, and it checks them against the scripts in your project. Because the repository is almost always on GitHub, detection often works straight away when your xCloud team has the GitHub provider connected, including for a private repository.

VS Code adds its own checkpoint to this flow. Agent mode lists the tools it wants to run, and VS Code may ask you to allow a tool call before it runs. Treat that as separate from xCloud's confirmation. You may approve the detection call in VS Code, read the dry run summary in the chat, and then answer the xCloud approval for the create call. After you say yes, the agent sends the confirmed request with an idempotency key, follows the site status until it is terminal, and fetches the address. xCloud deploys from the Git remote, so commit and push before you ask, or Copilot will deploy what is on the remote and not what is in the editor.

When a build fails, the loop stays inside VS Code. Copilot reads xCloud's deployment diagnosis, opens the file at fault, proposes an edit you can review in the diff view and, once you have committed and pushed it, retries on the same site. Because the key in .vscode/mcp.json is servers and not mcpServers, the connection is a workspace file you can commit for the team. Everyone who opens the project then gets the same xcloud entry, but each person signs in with their own xCloud account in the browser, so the approvals and the teams stay personal.

GitHub Copilot specific: VS Code reads .vscode/mcp.json with a servers key and type http, so a mcpServers block copied from another client will not load. If agent mode does not offer the deploy tools, open MCP: List Servers and check that xcloud is running. A long tool list can crowd the picker, and adding ?toolsets=sites,servers,integrations to the xCloud URL keeps just the toolsets this job uses.

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 GitHub Copilot 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 GitHub Copilot 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 GitHub Copilot 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 the repository I have open to my Frankfurt server on a staging hostname. Show me the dry run before creating anything.

Prompt

The xCloud deploy of this project failed. Read the diagnosis, open the file that caused it, suggest the edit and wait for me to commit it before you retry.

Prompt

Is my latest commit on origin? If so, deploy it to the staging site and tell me when the URL answers 200.

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.

GitHub Copilot and Deploy from Git: Frequently Asked Questions

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

Does Copilot agent mode deploy what is in my editor or what is on GitHub?

What is on the Git remote. xCloud clones the repository, so uncommitted edits and unpushed commits are not part of the deploy. Commit and push first, or ask Copilot to check that your branch matches origin before it deploys.

Why do I see two approval prompts when Copilot deploys?

VS Code may ask you to allow an agent mode tool call, and xCloud separately refuses a site create without an explicit confirmation. They are different checks. The VS Code prompt is about running the tool, and xCloud's is about creating a billable 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