Deploy Cursor App to Production: 2 Routes (2026)

After checking each route against the vendor's own docs, I found 2 ways to deploy a Cursor (the AI code editor) app to production, either through GitHub and a host or through a host's MCP server.

How to deploy a Cursor app: 2 routes

You deploy a Cursor app by pushing the code to GitHub and connecting a host, or by letting a host's MCP server publish it from inside Cursor.

1. GitHub route: Commit the project, push it to GitHub, import the repo on a host, set the build command, add environment variables, and deploy.
2. MCP route: Add the host's MCP server to Cursor, log in, grant access to your team, and ask the agent to deploy (Cursor asks you to approve the tool call first).

Cursor's deployment support is recent and runs through partners. Since August 27, 2026, you can connect a Vercel account and publish a project to a live URL, and Origin, Cursor's code hosting beta from August 17, 2026, adds Vercel preview deployments for pull requests.

The app itself still runs on the host you pick, and Cursor's cloud agents work the same way. They run on isolated VMs, build and test your code, and push to a separate branch, which you then deploy through either route.

Cursor's own publish step works through Vercel, so the two routes below still cover how a Cursor app reaches a host.

The GitHub route works with any host that deploys from a Git repository, so I'd start there, and every later change is a git push. The MCP route skips the dashboard steps on hosts that provide an MCP server.

If you haven't picked a host, Superblocks compares 9 platforms in its AI app deployment guide.

What you need before you start

You need a project that already runs on your machine and a hosting account. Route 1 also needs a GitHub account, because the host deploys from your repo.

• A working Cursor project: Run it locally before you deploy. Once it works on your machine, a failed deploy usually points to host settings such as the build command or environment variables.
• A GitHub account and an empty repository (Route 1 only): Skip the README to avoid a conflict on your first push.
• A hosting account: Vercel's Hobby plan is $0 per month for personal, non-commercial use.
• A list of your secrets: Write down your API keys, database URLs, and tokens now. You'll copy them into the host's settings in Route 1, Step 5.

Time required: A custom domain is the slow part. SSL typically provisions within a few minutes of DNS verification, and DNS changes can take time to propagate.

How to deploy a Cursor app through GitHub (Route 1)

Getting from Cursor to production through GitHub takes 6 steps. GitHub connects your machine to the host because nearly every modern host deploys from a Git repository, as Superblocks' vibe coded deployment guide points out.

Step 1: Fix localhost URLs and hardcoded keys, then commit

Search the project for localhost and hardcoded keys before the first commit. The same Superblocks guide explains why: AI writes http://localhost:3000 into fetch calls, which works on your laptop and fails on a live server.

Add your env files to .gitignore before committing. A secret you commit to a public GitHub repository is visible to anyone the moment you push it.

echo ".env" >> .gitignore

echo ".env.local" >> .gitignore

git init

git add .

git commit -m "Prepare for production"

Tip: Ask Cursor's agent to "find every hardcoded URL, API key, and password and move them to environment variables." Then review the diff before you commit.

Step 2: Push to GitHub

Create the empty repository on GitHub, then connect it and push.

git branch -M main

git remote add origin https://github.com/YOUR-USER/YOUR-REPO.git

git push -u origin main

Your code is on GitHub now. After Steps 3 to 6, Vercel deploys every push to the connected branch, so updating the live site means running git push.

Step 3: Import the repo on your host

On Vercel, open the New Project page, connect your GitHub, GitLab, or Bitbucket account, and select the repo. Netlify follows the same pattern: once you link a Git repository, it runs your build command and deploys whenever you push.

Stop before you click Deploy, because Steps 4 and 5 check the build setup and add your variables first.

Step 4: Confirm the build and start commands

Compare the build command and output directory the host detected with the scripts in your package.json. Superblocks names a missing build command or the wrong output directory as the usual cause of a failed first deploy.

Start commands depend on the host. Vercel deploys an Express app as a Vercel Function without extra configuration, which means no start command.

A host that runs your app as a web service asks for one. Render, for example, has a Start Command field, with npm start as its Node.js example.

If the build still fails: Check the build log for a package you never installed, then install it or ask Cursor to rewrite that import.

Step 5: Add environment variables

Open the Environment Variables section and paste each secret from your list. Vercel asks you to choose Config or Secret for every variable. Secret values stay hidden after saving, so use Secret for API keys.

Pick the environment too. A Production variable applies to your next production deployment, and pushing to the production branch (usually main) creates one.

Step 6: Deploy and attach a domain

Click Deploy. If anything fails, paste the exact error from the build log into Cursor and let the agent fix the file.

For a custom domain, add it under Settings > Domains on the project. Vercel then recommends an A record for an apex domain like example.com, or a CNAME for a subdomain like www.example.com. Use the values Vercel shows for your project.

Vercel provisions SSL after it verifies your DNS records, so a new domain can take a while to go live.

Open the live URL and click through a page that uses an environment variable. If it loads, the deploy worked.

How to deploy from Cursor with a host's MCP server (Route 2)

A host's MCP server lets Cursor's agent publish your app without leaving the editor. Vercel's MCP server can now deploy code directly, per its July 23, 2026 changelog, with no Git repo or CLI needed.

Step 1: Add the Vercel MCP server

Use the one-click button in Vercel's MCP docs, or add the server by hand. Cursor reads .cursor/mcp.json in your project and ~/.cursor/mcp.json for every project.

{

  "mcpServers": {

    "vercel": {

      "url": "https://mcp.vercel.com"

    }

  }

}

Step 2: Log in and grant team access

Cursor shows a Needs login prompt after the server connects. Click it and authorize Cursor with your Vercel account.

Authorization has two parts, your Vercel login and team access. The assistant needs access to the team that owns the project, so ask the agent to list your teamsand projects to confirm.

Step 3: Approve the tool call and deploy

Check the tool list first, since availability depends on your connection. If deploy_to_vercel is there, ask the agent: "Deploy this project to Vercel and give me the URL."

Cursor asks for your approval before running an MCP tool by default, and you can expand the prompt to read the arguments before approving.

According to the changelog, that tool creates the project, detects the framework, installs dependencies, and runs the build.

Vercel isn't the only host with this route. Netlify has an MCP server too, with a one-click Cursor install in its agent setup docs. Agents can create, build, deploy, and manage Netlify projects through it, according to the GitHub repo.

Security note: Vercel warns that connecting an AI client grants it the same access as your Vercel user account. Keep the approval prompt on so you review each action.

How to prompt Cursor to write your CI/CD pipeline

A GitHub Actions workflow can test your app on every pull request. GitHub defines a workflow as a YAML file in .github/workflows, which means the agent has one file to create. This section assumes your code is on GitHub, as in Route 1.

Hosts that deploy on every push, like Vercel, handle the release themselves, so the workflow only needs to run tests. For Vercel and similar hosts, give Cursor a prompt like this:

Create .github/workflows/test.yml. On every pull request, run npm ci, npm test, and npm run build. Leave deploys to the host, which deploys on every push. Read all secrets from GitHub Actions secrets.

A host that doesn't deploy from Git needs the workflow to deploy too. For that setup, use this prompt instead, and swap in your host's CLI command:

Create .github/workflows/deploy.yml. On every pull request, run npm ci, npm test, and npm run build. When code merges to main, deploy to production with my host's CLI command. 

Once the pipeline runs, you can also put Cursor's agent inside it. The Cursor CLI docs require a CURSOR_API_KEY secret and recommend permission-based restrictions for production.

In that setup, the agent edits files, and separate CI steps handle git and PR comments. The docs' permissions example denies Shell(git) and Shell(gh) and blocks writes to .env* and package.json, so the agent can't run git or touch your env files.

Common deploy errors and how to fix them

I collected these 5 errors from vendor docs, Superblocks' deploy guide, and reviewer feedback on Cursor.

‍

• Wrong build setup: The build fails when the host can't find your build command or output directory. Match both to the scripts in package.json.
• Variables added after the last deploy: Vercel applies environment variable changes only to new deployments. Redeploy after you add or edit one.
• Hardcoded localhost and CORS: Replace localhost URLs with environment variables, and add your live frontend domain to the backend's CORS settings.
• Lost SQLite data: Vercel says SQLite isn't supported because serverless storage is ephemeral and function instances don't share storage. Move to a hosted database, or to a host with persistent storage.
• Invented dependencies: One G2 reviewer of Cursor said it sometimes "hallucinates or suggests made-up or deprecated libraries." Read the build log and verify every import.

Work through these in order before you dig deeper, and start with the build log.

Deploy a Cursor app for internal use with Superblocks

Everything above assumes you pick your own host. For internal apps, IT usually has a say. Superblocks' Cursor alternatives article frames the split as Cursor for the engineer's editor and Superblocks for governed internal apps.

Shadow AI is shadow IT's faster, riskier successor. Apps that business teams build with AI and host outside IT's controls leave security teams without a view of the company data inside them, according to Superblocks' shadow AI article.

Superblocks answers that problem by hosting those apps and letting IT review them.

Here's what Superblocks adds after Cursor:

• Import: Zip the project and upload it to Clark, the Superblocks AI agent. The release notes (May 5, 2026) document zip uploads that Clark extracts and analyzes before helping you migrate, and Superblocks accepts custom code as an import source.
• Checks before production: Policy Agents run on import and catch exposed API keys and vulnerable packages. They also flag supply chain risks before those apps reach production.
• Git: Source control became generally available on May 20, 2026 for GitHub, GitLab, Bitbucket, and Azure Repos, and the pricing table puts it under Enterprise.
• CI checks: Git-connected apps skip the pre-publish Policy Agent checks, so the release notes tell you to run security and code checks in your CI pipeline instead.
• Enterprise controls: Enterprise adds SSO/SAML/OIDC and audit logs. It also covers VPC deployment. In Hybrid mode, production data stays in your VPC, and Cloud-Prem runs the full platform, including inference, in your own cloud (AWS, GCP, or Azure).

Superblocks is SOC 2 Type II certified and HIPAA compliant, per its pricing page. It also has code export, and its Cursor vs. Claude Code comparison says you can edit an app's React code in Cursor.

Teams starts at $125 per month billed monthly, or $100 per month billed annually. It includes 100 Governed Agent Units per month and 1 hosted app, with up to 15 builders. Each extra hosted app costs $10 per app per month.

Above Teams, Enterprise uses custom pricing, and there is no free plan, only a 14-day trial. To see a Cursor project operate under IT controls, book a demo or start with the Superblocks introduction.

Frequently asked questions

Can I make an app with Cursor?

Yes, you can make an app with Cursor. The Cursor docs describe it as a coding agent. The output is code in your project, and a host such as Vercel still has to run it.

Can I make mobile apps with Cursor?

Yes, with a cross-platform framework, since Expo's docs say you can use Cursor to build, upgrade, debug, and deploy Expo and React Native projects.

Cursor for iOS is a phone app for controlling coding agents. Publishing a mobile app requires a developer account on each store. Apple's developer program costs $99 per year, and Google Play charges a one-time $25 registration fee.

Can I deploy my Cursor app for free?

Yes, for personal projects. Vercel's Hobby plan costs $0 per month for personal, non-commercial use, and Netlify's Free plan is $0 with a 300-credit monthly limit. Commercial projects on Vercel need Pro at $20 per month billed monthly, with $20 of included usage credit.

Can Superblocks deploy a Cursor app?

Yes, for internal apps. Superblocks accepts custom code as an import source, and Teams starts at $125 per month billed monthly. Its AI app deployment comparison lists public consumer deployment as out of scope for Superblocks.

What if my Cursor app works locally but breaks after deploy?

Start with the build log, which usually names the problem. Common causes are a wrong build command, a missing output directory, or a variable you added after the last deploy. Fix it and redeploy. New variables reach only new deployments, so a redeploy is the only way to pick up a late one.