App Deploys, inherited from Cascade, does a tempting thing: it turns code into a live public URL in one step. After a long struggle with pipelines this looks like relief - the agent built the app, hit deploy, the link is ready. And the first impulse is understandable: if this is a "deploy", why keep the old CI/CD at all.
The naive move is exactly that - to take a preview deploy for a full-fledged release. Since it yields a working address, it seems logical to run demos, staging and, why not, production through it: one action instead of a chain of approvals. Saving steps now looks like pure gain, and it is exactly this visible simplicity that masks how differently preview and production price a mistake.
It breaks on what App Deploys actually is per the documentation. It is a beta feature intended primarily for preview, with Netlify as the provider and public addresses of the form <subdomain>.windsurf.build. Common frameworks are supported - Next.js, React, Vue, Svelte - and static HTML/CSS/JS sites. Support for additional frameworks and more robust builds, per the documentation, is only on the way, which is itself a sign that the path is immature for a production load. The key word here is preview: it is a surface for a quick show, not a release path to production.
The main boundary is about data, and the documentation states it directly: the code is uploaded to Windsurf's servers for deployment, so you should only put up what you are comfortable sharing publicly. The public URL, telemetry and retention are evaluated separately from your repository. Sensitive code and production secrets do not belong here without separate approval - this is moving data outside your policy boundary, not just another build.
The mechanics, meanwhile, are simple and hint at how to use them correctly. A windsurf_deployment.yaml appears at the project root, storing deployment information and easing redeployment. That is convenient for iterative preview, but for that very reason the file must be kept under control: no secrets should land in it, and it does not replace a description of the production environment.
Why preview is fundamentally not production. Production carries what a one-step preview deliberately omits for speed: approvals, environment protection, audit and, above all, rollback. A fast public address is good precisely because it lacks that harness - and unfit for a live release for exactly the same reason. The absence of governance is not a bug of preview but its definition.
Hence a practical division of roles. For production keep your existing CI/CD, approvals, environment protection and rollback - everything already vetted by your process. The agent stays useful in this: it can prepare the change, assemble the configuration, open a pull request. But it must not bypass release governance - preparing a release and shipping it are different powers, and the second is handed neither to a preview button nor to an agent. This division is not bureaucracy for its own sake: it is exactly governance that makes it possible to roll back after a bad release and to prove who approved what, while a fast preview carries none of these guarantees by design.
The cost of mixing the roles is concrete and two-sided. Sending sensitive code to a preview surface means exposing it on a public URL and on someone else's servers outside your retention policy. Using preview as production means being left without rollback, without environment protection and with secrets no one checked for leaks. In both cases you pay not with convenience but with data and with control over the release.
You should verify before the click, not after. Before deploying, make sure the repository holds nothing that cannot be shown publicly, and that windsurf_deployment.yaml carries no secrets. Treat the resulting link as public by default - because it is. And route everything meant for production through your own pipeline, where approval and rollback exist, and check the result there with the gates your team is used to. And make a habit of looking at what exactly goes out: the build's file list is more honest than the assumption that nothing extra is in it.
The typical failures are recognizable. A preview URL is taken for production, and people are surprised there is neither rollback nor protection behind it. A private repository is put up on a public address without reading the warning about uploading to someone else's servers. The agent is allowed to bypass approvals because "it already built it". People forget that a public link is also retained and telemetered. The sign of all of them is the same: the word "deploy" was heard while the word preview was not. Read the second one first, and separating preview from production stops being a question.