How to deploy a Windsurf-built website to production

Windsurf is a code editor with an AI agent, Cascade, built in. Your project is a folder on your computer: what you see at localhost is only visible to you. Putting it in production means three things: get the code onto GitHub or into a ZIP, change the few things that work differently on a server, and deploy it to a host. It can be any kind of project, from one HTML page to a Next.js, Python or PHP app.

Windsurf can also publish some web apps for you through Netlify, from inside the editor. That's handy for a quick preview; for your own domain and ongoing hosting, check Windsurf's and Netlify's current documentation.

Open the project in Windsurf, start Cascade and paste a prompt like this one:

Prepare this project for production hosting. The host builds from the
repository root, runs one container, sets the PORT environment variable
and provides secrets as environment variables. Please:
- make the app listen on PORT
- move every secret and API key into environment variables, and list
  their names (without values) in .env.example
- make sure .env is in .gitignore
- read the database URL from an environment variable instead of
  pointing at localhost
- make sure there is a production build and a start command
- make the home page / return a normal page without a login
Don't deploy anything. Change the code and list what you changed.

Review the changes Cascade proposes before accepting them, and run the project once more on your computer.

Keep it that way with a rule

Windsurf lets you save rules that Cascade follows, including workspace rules stored with the project in the .windsurf/rules folder. Add one with these lines and set it to apply always, so later changes don't undo the work:

- Production builds from the repository root and runs as one container.
- The app must listen on the PORT environment variable.
- Secrets and URLs come from environment variables; never commit .env.
- Add every new variable name to .env.example.
- The home page / must answer without a login.

• Separate front-end and back-end folders (such as frontend/ and backend/). ProHostiva builds the top level of a repository or ZIP, so put each part in its own repository and deploy them as two websites, or ask Cascade to make the backend serve the built front end so it's one app.
• A Docker Compose file with a database next to the app (docker-compose.yml). Multi-container setups aren't supported: deploy the app on its own and use a hosted database such as Supabase or Neon.
• A Dockerfile at the top level is always used when it's there. If it was written for development, ask Cascade to make it production-ready or remove it, and we'll build the project ourselves.

1. Put the code on GitHub (or make a ZIP)

Windsurf is built on VS Code, so its Source Control panel can publish your folder to a new GitHub repository: sign in to GitHub when asked and choose a private repository. You can also ask Cascade to commit and push. For a site you finish once, a ZIP is fine: see Deploying from a ZIP.

2. Check it (free)

Paste the repository's address into Check my project, or upload the ZIP. Anything the report flags can usually be pasted straight into Cascade as a task.

3. Create the website and publish

1. Start a new website

   In your dashboard, click Host a website, then choose GitHub repository and connect GitHub, or upload the ZIP. See Deploying from GitHub.

2. Check what we detected

   We show the framework, the runtime version and the build and start commands. Change a command only if you know it's different.

3. Add environment variables

   Everything in your .env.example goes under Developer settings → Environment variables, with production values. Tick Secret for anything private.

4. Publish

   Name the website, choose its address and click Publish website. We build it in an isolated container, check that the home page answers, and put it online at yourname.prohostiva.com.

5. Connect your domain

   Under Domains, add your domain, create the two DNS records we show and click Verify DNS. HTTPS is set up for you. See Connecting your own domain.

4. Updating the site later

Keep working in Windsurf. Commit and push your changes, then click Publish latest version on the website's page. Nothing goes live until you click, and if a new version fails to build or start, the current one stays online.

• Rotate any key that was ever committed. Deleting it from the code isn't enough if it's in the Git history; create a new one at the service and set it as an environment variable.
• Allow your domain where your code or its services expect known addresses: Django's ALLOWED_HOSTS, an API's CORS origins, and sign-in redirect URLs at Google, GitHub, Supabase or Auth0.
• Switch services to production: Stripe live keys and a webhook pointing at your domain, a production database rather than a test one, real email settings.
• Run your database migrations. They're never run automatically on deploy.

• It works in Windsurf but the build fails: often a file on your disk that was never committed, or a missing lockfile. Check the Source Control panel for uncommitted files, commit them, and push again.
• Health check failed: the app listens on a fixed port instead of PORT, or the home page redirects to a login. See Troubleshooting.
• "We couldn't find a website or app here": the project is in a subfolder. See the layouts above.
• Database connection errors: the database URL still points at localhost. Use your hosted database's URL in an environment variable.
• A blank page (React, Vue, Svelte): a missing VITE_ variable. Add it and deploy again.