Publish from Windsurf, now Devin Desktop, to a link you can share

Yes. Cognition renamed Windsurf to Devin Desktop on June 2, 2026. The editor stayed, but the agent changed: Cascade was removed in September 2026 and Devin Local took its place.

So a tutorial that says Windsurf mostly still applies, and one that says Cascade is out of date. Some paths never changed: worktrees still live in ~/.windsurf/worktrees, and the Linux package repositories keep the old name.

It's gone from Devin Desktop. Two September 2026 releases removed Cascade and then its Deploy entry point, and the old docs address now lands on the legacy Cascade page, which doesn't describe that feature.

The feature arrived in April 2025: one prompt put your app on Netlify under a windsurf.build address, and you could claim it on Netlify to keep it. We found nothing in Cognition's docs about what happens to sites already on that domain, so check any you still rely on. What you can do now:

• Use the host0 skill from Devin Local. You get a private link, with invites, shared data and versions.
• Keep your own Netlify or Vercel account, and have the agent run that platform's tooling with your credentials. That's the better fit if the site already lives there.
• Ask a Devin Cloud session to deploy it. That's the next question.

A deploy workflow you kept in .windsurf/workflows won't help here. Workflows aren't imported as skills, and Cognition's advice is to migrate them.

When a Devin Cloud session builds a small app from scratch, a public URL is fine, and above all when it needs a Python backend. Devin Cloud hosts static sites on devinapps.com and FastAPI backends on Fly.io, and host0 doesn't run server code yet.

That deploy tool belongs to Devin Cloud: its page sits in the Cloud docs and doesn't mention Devin Local, and on devin.ai/pricing cloud agents first appear on Pro. Devin's docs describe it as being for prototypes, demos and throwaway internal tools. Reach for host0 when the work shouldn't be public, when you're publishing a project or a file that already exists, or when your organization is on Enterprise, where those deployments are off.

Not to show them the app. A Preview runs on your own machine and a shared conversation is a transcript, so neither gives another person a working page.

• Previews: the agent proxies your local dev server into a pane or your browser, so you can pick an element or an error and send it back to the agent. It's a tool for you while you build.
• Share conversation: uploads a sanitized transcript and returns a link. It needs a Devin account rather than a Windsurf-only one, and an organization that allows sharing. Old shared Cascade links no longer work.

The usual order is to iterate in a Preview until the page looks right, then ask Devin Local to publish it.

In ~/.agents/skills/host0 for all your projects, or .agents/skills/host0 inside one repo. Going by Devin's docs this should work, but nobody at host0 has run it in Devin Desktop yet.

The plain curl installer chooses a folder from what's in your home directory, and it may pick ~/.claude/skills. Devin's import list only covers the project-level .claude/skills, so aim the installer at the shared folder:

curl -fsSL https://host0.ai/install.sh | bash -s -- --agent codex

To confirm it loaded, click Customize in the agent sidebar and open the Skills tab. On macOS and Linux the agent runs commands in a dedicated terminal, zsh or bash, that loads your shell config. A node or HOST0_API_KEY set up in .zshrc or .bashrc is available to it.

Because a deploy is a shell command. Code mode, the default, approves edits inside the workspace by itself but prompts for shell commands unless an allow rule covers them.

• The command card lets you run it once, allow it for the session, or allow it for good, which writes the rule for you. You can also edit the command first.
• Smart mode has a fast model approve what it judges safe. It's still rolling out, and anything it isn't sure about still prompts.
• Bypass Permissions approves every tool call. You don't need it for this, and rules your admin enforces still win.
• A sandboxed session runs in Autonomous mode and asks for capabilities rather than commands. A deploy needs network access, so grant it. OS-level sandboxing isn't supported on Windows.
• If you've set a domain allowlist for the sandbox, add host0.ai and host0.app. Devin's docs currently call that network filtering unstable.

Expect one more stop on the very first deploy. With no API key saved, the command prints a link and a short code, and you approve them in your browser, so nothing about you gets typed into the session.

~/.config/devin/mcp_config.json on macOS and Linux, and you only need it to manage apps. The server can't deploy: publishing is the skill's job or the CLI's.

{
  "mcpServers": {
    "host0": {
      "url": "https://mcp.host0.ai/mcp"
    }
  }
}

• On Windows the file is %APPDATA%\devin\mcp_config.json. For a team, commit .devin/mcp_config.json, and keep personal overrides in .devin/mcp_config.local.json, which stays out of git.
• An entry in the old ~/.codeium/windsurf/mcp_config.json is still imported by default, so there's no rush to move it.
• Customize, then MCPs, shows what loaded under This computer. When a sign-in expires the server shows Needs authentication, and Authenticate reopens the browser flow.
• Each MCP client keeps its own OAuth session, so signing in from another agent doesn't carry over.
• Devin Local asks before each MCP tool call. You can allow one tool or the whole server, for the session or for good, so a visibility change can stay behind a prompt while listing apps doesn't.

An Enterprise admin can limit which MCP servers connect. If host0 won't appear, ask them to allow it.

In a session on the same folder, just ask again: the deploy finds the app in .host0/state.json and uploads only what changed. A new worktree doesn't have that file, so name the app or you'll get a second one.

The agent location picker offers Local, Worktree and Cloud when a session starts. A worktree gets your repository files, not untracked ones, and .host0/state.json shouldn't be committed. So in a worktree, say "redeploy to team-todos" using your app's own slug. Worktrees sit in a different directory too, so a build that reaches for ../shared-lib may break before the deploy runs.

It should work, but we haven't run it. A cloud session has its own machine, without the skill or the key from yours, so you have to provide both.

• The skill: commit it to .agents/skills/host0 in the repo, the path Devin Cloud recommends.
• The key: save HOST0_API_KEY as a personal secret, and tell Devin that's the variable the deploy reads. Secrets are bound to commands that need them rather than exported to every shell.
• The network: a security profile or network policy may block the deploy. If it does, host0.ai and host0.app are the domains to allow.
• The app: name the slug in your prompt, since the session has no .host0/state.json.