MMakerToLaunch

Launch

How to Launch an App Built With Cursor

Cursor is one of the most popular AI coding editors for makers — but it builds apps on your computer, not on the internet. Launching a Cursor project means taking the folder on your laptop and putting it on GitHub, configuring environment variables, and deploying to a host that matches your stack. This guide covers the full path, including what to ask Cursor before you deploy and how to fix the failures that trip up first-time launchers.

Updated July 2026 · 11 min read

Written for AI makers using tools like Cursor, Bolt, Lovable, Replit, Claude, and ChatGPT.

Quick answer

Cursor gives you a local project folder — it does not host your app. To launch: find your project on disk, identify the stack (Next.js, Django, etc.), push to GitHub without secrets, set environment variables on your host, and deploy. Run a readiness scan before deploy to catch debug mode, missing .env.example, and other AI-generated gaps.

Best for

Apps built or edited in Cursor on your laptop

What the tool gives you

A local project folder + AI help writing and fixing code

What still needs launching

GitHub upload, host choice, env vars, deploy, live testing

Main risk

Assuming 'runs in Cursor' means the app is live on the internet

Who this is for

  • You built or edited an app in Cursor and want to put it online for real users
  • Your app runs when you click Run in Cursor but you are not sure what happens next
  • You hit errors after deploy and suspect the AI-generated config is incomplete

What you'll need

  • Cursor installed with your project open (or the folder path remembered)
  • A GitHub account
  • A hosting account (Vercel, Railway, Render, etc.) matched to your stack

Key concept

What Cursor does — and what it does not

Cursor is an AI-powered code editor. It helps you write, refactor, and debug code faster by chatting with AI inside your project. It can generate entire features, fix errors, run terminal commands, and even publish to GitHub from the Source Control panel.

What Cursor does not do is host your app on the public internet. There is no 'Deploy' button that makes your app available at a permanent URL for the world. When you close Cursor, your app still exists as files on your computer — not as a live website.

Think of Cursor as the workshop. GitHub is the warehouse. Vercel, Railway, or Render is the storefront. You need all three roles filled to launch.

Some Cursor workflows integrate with deployment tools, but the fundamentals stay the same: code lives in a repo, secrets live in environment variables, and a hosting platform runs your app 24/7.

Deploy settings

Find your project folder

Before anything else, know where your project lives on disk. In Cursor, check the top of the Explorer sidebar or go to File → Open Recent. The folder name is usually what you chose when you started the project.

Common locations on Mac: ~/Projects/your-app-name or ~/Documents/your-app-name. On Windows: C:\Users\YourName\Projects\your-app-name.

Inside that folder you should see source files and config files — package.json for JavaScript projects, manage.py for Django, requirements.txt for Python, and so on. If you are unsure whether you have the right folder, look for the file you have been editing most.

Back up the folder before major changes. Copy it to an external drive or cloud storage. Launching involves Git operations and config edits — a backup saves you if something goes wrong.

  • File → Open Recent or check Explorer sidebar for the path
  • Look for package.json, manage.py, or requirements.txt
  • Back up the folder before launch changes

Key concept

Identify your stack

Your stack determines which hosting platform to use and which environment variables you will need. Cursor can build almost anything, so look at the files in your project root rather than assuming.

  • package.json with next → Next.js app (usually Vercel)
  • package.json with vite and react → React + Vite frontend (Vercel, Netlify, or static host)
  • manage.py and a settings.py → Django (Railway, Render, Fly.io)
  • pyproject.toml or FastAPI imports → FastAPI (Railway, Render)
  • Dockerfile present → container-based deploy (Railway, Render, Fly.io)
  • supabase or firebase in dependencies → you likely need their env vars on your host

Deploy settings

Publish to GitHub from Cursor

GitHub stores your code in the cloud and connects to hosting platforms. Cursor's Source Control panel (the branch icon in the left sidebar) can initialize a repo, commit, and push — or you can use GitHub Desktop if you prefer a visual tool without the terminal.

Before your first push, run a safe-upload check. AI-generated projects often create .env files with real API keys. Make sure .env is in .gitignore and never staged for commit. Commit .env.example instead.

To publish from Cursor: open Source Control → Initialize Repository (if needed) → stage files → write a commit message → Publish Branch. Cursor will prompt you to log into GitHub and create a repository.

After pushing, open github.com and verify your repo. Scan the file list — if you see .env, credentials.json, or node_modules, fix .gitignore before deploying.

  • Source Control → Initialize → stage → Publish Branch
  • .env in .gitignore — commit .env.example instead
  • Verify on github.com before connecting a host

Key concept

What to ask Cursor before you deploy

Cursor shines when you give it specific context. Before deploying, paste prompts that force a production review. Do not ask vague questions like 'make it deployable' — ask for concrete deliverables.

  • 'List every environment variable this app needs and create .env.example with placeholders'
  • 'Is DEBUG or development mode enabled anywhere? Show me every file that sets it'
  • 'What build command and start command should I use on [Vercel/Railway]?'
  • 'Are there any hardcoded localhost URLs that need to change for production?'
  • 'What database does this app use locally and what do I need in production?'
  • 'Review my .gitignore — are .env, .DS_Store, and node_modules excluded?'

Watch out

Set environment variables and scan

Your local .env file does not upload to GitHub. After connecting your repo to a host, open the host's environment variables page and add every name from .env.example with production values.

Run a launch readiness scan on your GitHub repo before clicking Deploy. Cursor projects frequently ship with debug mode on, no README, missing start scripts, and incomplete .env.example files. A scan surfaces these in minutes with fix prompts you can paste back into Cursor.

Fix critical issues first: leaked secrets, debug mode, missing env vars. Then address warnings like README gaps or unspecified Node version.

  • Copy .env.example names to the host dashboard with production values
  • Run a readiness scan before first deploy
  • Fix critical security issues before sharing a public URL

Deploy settings

Deploy and verify

Connect your GitHub repository to your chosen host. The host will detect your framework in many cases and suggest build settings. Confirm they match what Cursor told you or what is in package.json scripts.

Add environment variables before the first deploy if possible — apps that crash on startup because of missing DATABASE_URL waste debugging time. Deploy, wait for the build to finish, and open the provided URL.

Test in an incognito browser window. Walk through signup, login, data creation, and any payment or AI features. Check the host's deploy logs if anything fails — the error message at the bottom of the log is usually the clue.

  • Connect GitHub repo → set env vars → deploy
  • Test in incognito — not just the homepage
  • Check host deploy logs if anything fails

Watch out

Common Cursor-to-deploy failures

These patterns show up constantly in AI-assisted projects. Knowing them saves hours.

  • Works locally, 500 error in production → missing environment variables on the host
  • Build fails on host → wrong Node/Python version or missing build command
  • Blank page after deploy → wrong output directory or client-side env vars not prefixed (NEXT_PUBLIC_, VITE_)
  • Database errors → SQLite used locally but no production database configured
  • CORS errors → backend ALLOWED_HOSTS or CORS settings still point to localhost
  • Auth works locally, fails live → callback URLs still set to http://localhost:3000
  • App slow or times out → free tier cold starts, or missing production-grade server (gunicorn vs runserver)

After your first launch

Your first deploy is a milestone, not the finish line. Watch your host logs for the first 24 hours. Share the URL with one or two trusted testers before posting publicly.

When you fix bugs in Cursor, commit and push to GitHub. Most hosts auto-redeploy on push. Keep environment variables updated when you add new features that need new keys.

Consider a custom domain once the app is stable. Update ALLOWED_HOSTS, OAuth callback URLs, and any hardcoded URLs when you switch domains.

Cursor local project vs GitHub repo vs live app

CriteriaCursor (local)GitHub repoLive app
Where it runsYour laptopGitHub cloudHosting provider (24/7)
Who can accessOnly you on that machineYou (+ collaborators)Anyone with the URL
Secrets.env on your disk.env.example only — no real keysEnv vars in host dashboard
UpdatesEdit in CursorPush commits to GitHubHost rebuilds on push
Best useBuild and test locallyBackup + deploy bridgeReal users and sharing

Step-by-step

  1. 1

    Step 1

    Locate and back up your project folder

    Confirm the folder path in Cursor. Copy the folder to a backup location before making launch changes.

  2. 2

    Step 2

    Identify stack and pick a host

    Check for package.json, manage.py, or Dockerfile. Match to Vercel (Next.js/React), Railway (Django/full-stack), or Render.

  3. 3

    Step 3

    Safe GitHub upload

    Verify .gitignore excludes .env. Push via Cursor Source Control or GitHub Desktop. Confirm no secrets on github.com.

  4. 4

    Step 4

    Readiness scan and fixes

    Scan your repo for launch blockers. Paste fix prompts into Cursor. Address critical security and config issues.

  5. 5

    Step 5

    Deploy and test live

    Connect repo to host, set environment variables, deploy, and test core flows on the live URL in incognito mode.

Common mistakes

  • Assuming Cursor deployed your app because it runs in the editor

    What happens: You share localhost or nothing — users cannot reach your app from the internet.

    How to fix it: Running locally and being live on the internet are different. You still need GitHub + a hosting platform.

  • Pushing .env to GitHub from Cursor's Source Control panel

    What happens: API keys and passwords become visible in your repo history — even in private repos.

    How to fix it: Add .env to .gitignore before the first commit. Use .env.example for the repo. Rotate any keys that were exposed.

  • Choosing the wrong host for your stack

    What happens: Deploy fails, times out, or runs but API/database features break on serverless limits.

    How to fix it: Django and long-running Python APIs belong on Railway or Render, not Vercel serverless (without extra config). Match host to framework.

  • Not redeploying after adding environment variables

    What happens: The live app still uses old or missing config until a new build runs.

    How to fix it: Trigger a new deploy from your host dashboard after every env change.

  • Leaving localhost in OAuth or API callback URLs

    What happens: Login and OAuth work on your laptop but fail or redirect wrong on the live URL.

    How to fix it: Search the codebase for localhost and update URLs to your production domain in both code and provider dashboards.

Copy-ready prompt

Prompt: prepare Cursor project for deployment

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready to paste

I built this app in Cursor and I am ready to deploy. Review the entire project and prepare it for production.

1. Identify the framework and recommend a hosting platform (Vercel, Railway, Render, etc.).
2. List every environment variable needed. Create or update .env.example with placeholders only.
3. Find any hardcoded secrets, localhost URLs, or DEBUG=True settings and fix them.
4. Tell me the exact build command and start command for production.
5. Confirm .gitignore excludes .env, node_modules, __pycache__, and .DS_Store.
6. Add or improve README with setup instructions and required env vars.
7. List anything that will break in production if I only run it locally today.

Do not put real API keys in any file committed to GitHub.

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready check

Before you launch

Work through these checks before you connect a host.

  • Located project folder and created a backup
  • Identified stack (Next.js, Django, React+Vite, etc.)
  • Chose a hosting platform that fits the stack
  • .env in .gitignore — not on GitHub
  • .env.example committed with all variable names
  • Code pushed to GitHub and verified on github.com
  • Launch readiness scan run — critical issues fixed
  • Environment variables set on hosting dashboard
  • Build and start commands confirmed
  • Deployed successfully — main flow tested on live URL

Frequently asked questions

Does Cursor deploy for me?
No. Cursor is a local editor. You deploy by connecting your GitHub repo to a hosting platform like Vercel or Railway and configuring environment variables there.
My app works in Cursor but fails online — why?
The most common causes are missing environment variables on the host, debug-only settings, wrong build/start commands, or a database that only exists on your laptop. Check host deploy logs first.
Can I deploy without using the terminal?
Yes. Use Cursor's Source Control panel or GitHub Desktop for uploads. Hosting platforms like Vercel and Railway deploy from GitHub with dashboard clicks — no terminal required for basic launches.
Should I let Cursor auto-generate my Dockerfile?
Only if you plan to deploy with Docker. Many beginners deploy Next.js or Django without Docker using platform-native buildpacks. Ask Cursor which path fits your stack before adding Docker complexity.
How do I update my live app after fixing bugs in Cursor?
Commit and push to GitHub from Cursor. Most hosts automatically rebuild and redeploy. Verify the deploy succeeded in your host dashboard before telling users to refresh.

Related reading