Windsurf + xCloud

Deploy from Git with Windsurf on xCloud

Deploying from Git with Windsurf means asking the Devin Local agent in your editor to ship the project you have open, and letting xCloud detect the app, preview the site, create it after your confirmation and verify the live URL.

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

Set up Windsurf All Windsurf guides

YouDeploy this project to Frankfurt on a staging hostname. Dry run first.

git_detectread-only

AgentNode.js app on main. xCloud would run npm run build and serve dist. Your package.json also defines a start script, which matches. Staging address: web-staging.acme.xcloud.site. Create it?

YouCreate it.

servers_sites_git_autoneeds approval

AgentDeployed. https://web-staging.acme.xcloud.site answers 200 and SSL is issued.

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

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

1
Add xCloud to the Devin Local agent
New tabs in Devin Desktop use the Devin Local agent, which reads MCP servers from the Devin CLI config files. Run this in a terminal: the URL is treated as Streamable HTTP, and the second command opens the browser for the xCloud sign-in (the agent also prompts on first use). By default the entry lands in .devin/mcp_config.local.json for the current project; add -s user to the first command to share it across projects in ~/.config/devin/mcp_config.json, where the entry reads url plus transport http.
Shell
```
devin mcp add xcloud https://app.xcloud.host/mcp
devin mcp login xcloud
```
2
Or edit the legacy Cascade config
If your tab runs the legacy Cascade agent, click the three-dot menu in the Cascade panel, then the Open MCP config file icon in the MCPs section, and add this under mcpServers. Cascade allows 100 tools in total and the full xCloud server offers 188 operations plus two search tools, so point serverUrl at the compact profile, five tools that reach every operation through search and call; a single toolset such as ?toolsets=sites (60 tools) also fits, but sites and servers together are 121 tools. Windsurf's file has been at ~/.codeium/windsurf/mcp_config.json, and the current documentation lists ~/.config/devin/mcp_config.json on macOS and Linux and %APPDATA%\devin\mcp_config.json on Windows; the icon opens the one your version reads.
JSON
```
{
  "mcpServers": {
    "xcloud": {
      "serverUrl": "https://app.xcloud.host/mcp?profile=compact"
    }
  }
}
```
3
No browser sign-in? Use an API key
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, export it as XCLOUD_TOKEN and add a headers field to the xcloud entry. Both agents fill in the ${env:XCLOUD_TOKEN} reference from your environment, so the token itself stays out of the file. The Devin Local entry is shown; for Cascade the same headers field sits beside serverUrl.
JSON
```
"xcloud": {
  "url": "https://app.xcloud.host/mcp",
  "transport": "http",
  "headers": {
    "Authorization": "Bearer ${env:XCLOUD_TOKEN}"
  }
}
```

Check it worked

Then ask Windsurf for the job itself, for example:

Prompt

Deploy this project to my Frankfurt server on a staging hostname. Show me the dry run in the panel before you create anything.

In practice

How Does Deploy from Git Work from Windsurf?

In Windsurf you are inside the code. The folder is open, the terminal panel is a click away and the agent chat sits beside the editor, so a deploy request can be as short as deploy this to my Frankfurt server on a staging hostname. The Devin Local agent works on the project you have open, so it can read the remote and the branch and compare the install, build and start commands xCloud suggests with the scripts the repository declares. When detection returns, the app type, the web root and any warning appear in the chat, and a mismatch, such as a build script xCloud did not pick up, is something to settle before a site exists, not after.

Connecting takes two commands: devin mcp add xcloud https://app.xcloud.host/mcp, then devin mcp login xcloud for the browser sign-in. No tool cap is documented for Devin Local, so the full URL is fine, with its 188 operations plus two search tools. The tool budget matters only if your tab runs the legacy Cascade agent, which allows 100 tools in total, so this job points its serverUrl at https://app.xcloud.host/mcp?profile=compact, whose five tools reach every operation, because the sites and servers toolsets together are 121 tools and do not fit. Either way the flow is the same. The agent calls git_detect, asks for a staging hostname, sends the dry run and shows the would_create summary. Creating a site is previewed first and waits for your explicit confirmation, and Devin Local asks before the tool call as well, so you approve twice in practice. The agent then sends the confirmed create call, polls sites_status and reports each real change, then fetches the URL and reads failed_steps before it calls the site live.

When the build fails you are already where the fix goes. The agent reads the deployment diagnosis, which classifies the failing step and quotes the log lines, and because the editor has the repository open it can change a script or a config file for you to review. You commit and push, and the retry goes to the same site after you confirm it.

Windsurf specific: Check which agent your Windsurf tab is using before you debug a missing tool. New tabs use Devin Local, which reads MCP servers from the Devin CLI config files: ~/.config/devin/mcp_config.json for your user, .devin/mcp_config.json for a project shared through git, or .devin/mcp_config.local.json for a local, gitignored entry. Before Devin Local 3.6 the servers sat inside the main config.json and migrate on their own. A legacy Cascade tab opens its file from Open MCP config file in the Cascade panel menu and uses serverUrl. In a team, an admin allowlist for Cascade blocks every server that is not listed, and the server ID must be xcloud exactly, or a deploy request will find no tools at all; Devin Local can instead be limited to a team MCP registry.

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 Windsurf 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 Windsurf 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 Windsurf 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 this project to my Frankfurt server on a staging hostname. Show me the dry run in the panel before you create anything.

Prompt

Compare the build and start commands xCloud detects for this repo with the scripts in package.json and tell me if they disagree.

Prompt

The last xCloud deploy of this project failed. Read the diagnosis, fix the file it points at and wait for me before retrying.

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.

Windsurf and Deploy from Git: Frequently Asked Questions

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

Will the full xCloud server work in Windsurf for a deploy?

Yes in Devin Local, which has no documented tool cap, so the full URL works. In the legacy Cascade agent it does not fit: Cascade allows 100 tools in total and the full server offers 188 operations plus two search tools. Connect Cascade with ?profile=compact, whose five tools reach every operation a Git deploy uses, because the sites and servers toolsets together are 121 tools.

Can Windsurf's agent fix the repository when an xCloud deploy fails?

Yes. It reads xCloud's deployment diagnosis, then can edit the build script or config file the diagnosis points at in the open project. You review and commit the change, and the retry runs on the same site after you confirm it.

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