How to deploy a Cursor-built website to production

Cursor is a code editor with AI built in. Your project is a folder on your computer, and Cursor doesn't host it: 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 can be any kind of project, from one HTML page to a Next.js, Python or PHP app.

Open the project in Cursor, start the agent 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 Cursor proposes before accepting them, and run the project once more on your computer.

Keep it that way with a project rule

Cursor's Project Rules are .mdc files in the .cursor/rules folder, and alwaysApply: true includes a rule every time the agent works. A rule like this one (for example .cursor/rules/deployment.mdc) stops later changes from undoing the work:

---
description: Production deployment constraints
alwaysApply: true
---
- 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 Cursor 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 Cursor 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)

Cursor 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 the agent 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 Cursor's agent 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 (and that the project was made with Cursor, if it has a .cursor folder or a .cursorrules file). 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 Cursor. Commit and push your changes (if you use Cursor's Background Agents, which work on your repository asynchronously in a remote environment, merge their changes first), 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 Cursor 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.