# How to Deploy Apps Built With Windsurf (Now Devin Desktop) > Windsurf is now Devin Desktop. See how to prepare your application, connect its GitHub repository to Kuberns, configure services, and verify production. - **Author**: vamsi-mullapudi - **Published**: 2025-12-07 - **Modified**: 2026-10-13 - **Category**: Deployment Guides - **URL**: https://kuberns.com/blogs/how-to-deploy-from-windsurf/ --- Windsurf is now **Devin Desktop**, but applications created in the former Windsurf editor are still standard web applications. To deploy one to production, prepare its production settings, push the code to GitHub, connect the repository to a hosting platform, and verify the live application. With [Kuberns](https://kuberns.com/), you can connect the repository, review the detected framework and commands, add required environment variables or services, and deploy the application without manually setting up a server. The same process works for a new project created in Devin Desktop and an existing project created before the Windsurf rebrand. This guide explains what changed from Windsurf to Devin Desktop, how to prepare your project, and how to move it into a production environment with Kuberns. > **TL;DR** > > - Windsurf became Devin Desktop on June 2, 2026, but existing Windsurf projects remain compatible. > - Test the production build and push the deployment-ready project to GitHub. > - Connect the repository to [Kuberns](https://kuberns.com/) and review the detected framework, build command, start command, and port. > - Add the required environment variables and services before deploying. > - Verify HTTPS, logs, authentication, API requests, database operations, and the complete production flow. ## Windsurf Is Now Devin Desktop: What Changed? Cognition [renamed Windsurf to Devin Desktop on June 2, 2026](https://devin.ai/blog/windsurf-is-now-devin-desktop). It remains a full code editor, but the product now puts its Agent Command Center at the center of the experience. Developers can manage local and cloud agents, review their work, and continue editing the same codebase from one interface. The change does not make existing Windsurf projects obsolete. According to the [official transition documentation](https://docs.devin.ai/desktop/devin-desktop-faq), existing editor settings, extensions, keybindings, workflows, and project files remain available. Devin Local has replaced Cascade as the main local agent, while legacy Windsurf configuration continues to work. For new project-level configuration, use the current `.devin/` directories. Devin Desktop still reads older `.windsurfrules` and `.windsurf/` configuration as a backward-compatible fallback. These naming changes do not alter how an application must be prepared for its production runtime. ## What to Check Before Deploying a Devin Desktop Project A project that runs in an editor preview is not automatically ready for production. Check these items before connecting it to a deployment platform: - **Production build:** Run the framework's production build and fix dependency, import, or type errors. - **Dependency files:** Commit the correct package manifest and lock file so the deployment uses repeatable versions. - **Start command:** Use a production server command rather than a development server with hot reload. - **Dynamic port:** Server applications should read the assigned port and normally listen on `0.0.0.0`. - **Environment variables:** List every model key, API credential, database URL, callback URL, and application secret the live service needs. - **External URLs:** Replace hard-coded localhost URLs with environment-based production URLs. - **Data services:** Identify whether the application needs PostgreSQL, another datastore, background workers, or persistent storage. - **Secret handling:** Keep `.env` files and credentials out of Git. Add production values through the deployment platform. If the project was generated quickly with an agent, also review its authentication, error handling, database migrations, and health endpoint. The [vibe-coded app deployment guide](https://kuberns.com/blogs/after-vibe-coding-deploy-your-app/) explains why these checks matter after the initial build is complete. ## How to Deploy a Windsurf or Devin Desktop App on Kuberns The deployment handoff is Devin Desktop to GitHub to Kuberns. GitHub keeps the application versioned, while Kuberns builds and runs the selected repository branch. ### Step 1: Prepare and test the application Open the project in Devin Desktop and run its production build. Ask Devin Local to investigate errors if necessary, but review every configuration change before committing it. Confirm that the application starts with its production command, does not depend on files that exist only on your computer, and reads runtime values from environment variables. A frontend-only website may need only a build command and output directory. A backend or full-stack application may also need a start command, port, health route, database, and migrations. ### Step 2: Commit the project and push it to GitHub Commit the files required to reproduce the application, including its dependency manifest and lock file. Do not commit secrets, local environment files, build caches, or generated folders that the framework normally recreates. Push the production-ready branch to GitHub. Git provides a clear deployment source and makes later releases traceable. To release subsequent pushes automatically, follow the guide to [set up GitHub auto-deploy](https://kuberns.com/blogs/how-to-auto-deploy-your-apps-from-github-in-one-click/). ### Step 3: Connect the repository to Kuberns Sign in to Kuberns, connect your GitHub account, and select the repository and branch you want to deploy. Confirm that Kuberns can access the correct repository, especially when it is private or belongs to an organization. ![Connect the Devin Desktop project repository from GitHub to Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/connect-github.png) ### Step 4: Review the detected application settings Kuberns can inspect the repository to identify supported application settings. Review the result rather than assuming every generated project follows its framework defaults. Confirm the: - framework or runtime - root directory, especially in a monorepo - dependency installation command - production build command - production start command - application port or generated output directory Correct any value that does not match the project. For framework-specific requirements, use the [Node.js production deployment guide](https://kuberns.com/blogs/how-to-deploy-nodejs-app/) or [FastAPI deployment guide](https://kuberns.com/blogs/fastapi-deployment-guide/). ### Step 5: Add environment variables and services Add production secrets through Kuberns. Use the variable names expected by the application, but supply production values rather than copying local endpoints unchanged. If the application needs a database or another supported service, attach it and update the application configuration to use the provided connection value. Check whether database migrations must run during the release. Applications that store uploaded files also need storage designed to persist beyond one application instance. ### Step 6: Deploy and inspect the logs Start the deployment and follow its build logs. A failed build usually points to a missing dependency, incorrect root directory, incompatible runtime version, or wrong command. After the build succeeds, inspect the runtime logs. If the service exits, confirm the start command, port binding, required variables, database connectivity, and health endpoint. Make the fix in Devin Desktop, commit it, and push the updated branch so the repository remains the source of truth. ### Step 7: Verify the production application Do not stop after the homepage loads. Test the complete path that real users will follow: - HTTPS and the custom domain - sign-up, sign-in, and password recovery - frontend requests to the production API - database reads, writes, and migrations - direct navigation to application routes - file uploads and persistent assets - outbound webhooks and callbacks - background jobs or scheduled work Review the logs while completing these tests. This catches configuration failures that a successful build cannot reveal. ## Devin Desktop Deployment vs Kuberns Deployment Devin Desktop and Kuberns serve different parts of the delivery workflow. Devin Desktop is where you create, test, review, and coordinate work. Kuberns is where the repository is configured and run as a hosted application. | Area | Devin Desktop | Kuberns | |---|---|---| | Primary role | Develop, review, and coordinate coding agents | Build, deploy, and operate the application | | Deployment workflow | Works with agents, MCP tools, and provider integrations | Connects a repository to a managed production workflow | | Application configuration | Helps create and correct configuration in the codebase | Applies reviewed build, runtime, variable, and service settings | | Production operations | Depend on the connected deployment provider | Provides the hosting workflow, deployment logs, and HTTPS configuration | | Best fit | Preparing and maintaining the application | Running the completed application in production | Devin Desktop can participate in deployment through integrations. It is therefore inaccurate to say that direct deployment is impossible. Kuberns is useful when you want the deployed application, its services, and its repository-based release workflow managed in one platform. ## Common Windsurf and Devin Desktop Deployment Problems | Problem | Likely cause | What to check | |---|---|---| | The build works locally but fails during deployment | A dependency or lock file is missing | Commit the required dependency files and reproduce the production build locally | | The application never becomes healthy | It uses a fixed port or binds only to localhost | Read the assigned port and bind the server to `0.0.0.0` | | Browser API requests fail | The frontend still calls a localhost address | Use an environment-based production API URL | | Secrets are unavailable | Local values were not added to production | Add the variables through Kuberns | | Database tables are missing | Production migrations did not run | Confirm the migration command and database connection | | A route returns 404 after a browser refresh | The production server lacks the expected SPA fallback | Check the framework's routing and output configuration | | Browser requests are blocked | CORS excludes the live origin | Add the exact production origin to the backend configuration | | Recent changes are missing | Files were not committed or the wrong branch is connected | Check the Git commit, branch, and deployment source | These errors are easier to resolve when configuration changes remain in the repository and environment-specific secrets remain in the deployment platform. ## Why Use Kuberns for an App Built With Devin Desktop? Devin Desktop helps you develop and review the application. Kuberns provides the next part of the workflow by turning the selected GitHub repository into a production deployment. ![Kuberns platform for deploying applications built with Windsurf or Devin Desktop](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png) You can review the detected runtime and commands, provide environment variables, connect supported data services, inspect build and runtime logs, and configure HTTPS and a custom domain from the deployment workflow. When the application changes, new repository commits provide a traceable basis for later releases. This separation keeps the code and deployment configuration reviewable. Devin Desktop can help correct a failed build or runtime issue, while Kuberns shows what happened during the production build and after the service started. For applications with a frontend, backend, and database, the [full-stack deployment guide](https://kuberns.com/blogs/deploy-full-stack-app-with-ai/) covers checks across those components. ## Conclusion Windsurf projects do not need to be rebuilt or converted into a different code format after the move to Devin Desktop. The editor, project files, extensions, and Git workflow remain compatible. Prepare and test the application in Devin Desktop, push the production-ready code to GitHub, and connect the repository to Kuberns. Review the detected settings, add the required variables and services, deploy, and then test the complete production flow rather than only the homepage. [Connect your repository and deploy the application on Kuberns.](https://dashboard.kuberns.com) Deploy an application built with Devin Desktop on Kuberns ## FAQs ### Is Windsurf now called Devin Desktop? Yes. Cognition renamed Windsurf to Devin Desktop on June 2, 2026. The editor, extensions, keybindings, settings, and existing workflows remain available in the renamed product. ### Can I still deploy a project created with Windsurf? Yes. A project created with Windsurf remains a standard application codebase. You can open it in Devin Desktop, test its production build, push it to GitHub, and deploy it through Kuberns or another compatible hosting provider. ### How do I deploy an application built with Devin Desktop? Prepare and test the production build, push the project to GitHub, connect the repository to Kuberns, review its detected settings, add required variables and services, and verify the deployed application. ### Can Devin Desktop deploy applications directly? Devin Desktop can work with deployment agents, MCP tools, and provider integrations. The exact workflow depends on the connected provider. For a Git-based production workflow, you can push the project to GitHub and connect it to Kuberns. ### Do existing Windsurf rules still work in Devin Desktop? Yes. Devin Desktop continues to read legacy Windsurf rules. For new configuration, the official documentation recommends the `.devin/` directory while retaining `.windsurf/` paths as a backward-compatible fallback. ### Do I need Docker to deploy a Devin Desktop project? Not always. Whether you need a Dockerfile depends on the application and deployment method. Kuberns can detect supported runtimes and build settings from the repository, but you should review the detected configuration before deploying. --- - [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/) - [All articles](https://kuberns.com/blogs/)