The Complete Guide to Taking a Cursor-Generated App from Local to Live in 2026

You built something in Cursor. It runs on your machine. You want it online.

Getting there is not hard, but there are a predictable set of steps between "works locally" and "live on the internet," and Cursor does not walk you through them. This guide does.

What Cursor typically produces

Cursor generates full-stack apps that are optimized for local development. The code is usually solid. The gap is in the infrastructure configuration: what the app needs to run on a server, not just on your machine.

Depending on what you asked Cursor to build, you will usually have:

A Node.js backend, typically Express, Fastify, or a framework like AdonisJS, NestJS, or Hapi. Possibly a Next.js or Remix app that handles both the frontend and backend.

A database connection, usually Prisma or Drizzle connecting to a PostgreSQL database that is running on your machine.

A .env file with secrets and configuration that is not committed to your repository.

A package.json with a dev script that starts everything locally.

What you usually do not have: a production build step, a start command that runs compiled code, a database that lives somewhere accessible from a server, or any documentation of what environment variables are needed.

Step 1: Make sure you have a Git repository

If you started your project in Cursor without explicitly setting up Git, check whether a repository exists:

git status

If you get an error, initialize one:

git init
git add .
git commit -m "initial commit"

You need a Git repository because deployment platforms pull your code from one. If your project is already on GitHub, you are ready. If not, create a new repository on GitHub and push to it.

Step 2: Audit your environment variables

Open your .env file and make a list of every value in it. Every one of these values needs to be provided to your deployment environment, either by you manually or by the platform automatically.

Categorize them:

Values the platform can generate for you: database connection strings, internal service URLs between your own services.

Values you need to provide: third-party API keys (Stripe, SendGrid, Resend, Cloudinary), OAuth secrets, JWT signing keys, any key from an external service.

Values that need to be updated for production: callback URLs that currently point to localhost, app URLs, webhook endpoints.

Write these down. You will need them in a few steps.

Step 3: Check your start command

Open your package.json. Look at the scripts section.

If you only have a dev script, you need to add a build script and a start script. The build script compiles your TypeScript. The start script runs the compiled output.

For a typical Express/TypeScript app:

{
  "scripts": {
    "dev": "ts-node-dev src/index.ts",
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

Run npm run build locally to make sure it works before you try to deploy. Fix any TypeScript errors that come up.

Step 4: Check your port and binding configuration

Find where your server starts in the code. Look for something like app.listen(...).

Make sure it reads the port from the PORT environment variable:

const port = process.env.PORT || 3000
app.listen(port, '0.0.0.0')

The '0.0.0.0' binding address is important. Without it, many hosting platforms cannot route traffic to your app.

Step 5: Set up a database

Your local database does not come with your deployment. You need a hosted database your production app can connect to.

If you are deploying to Jetpacked, a PostgreSQL database is provisioned for your project automatically. The connection string is injected as an environment variable. You do not need to set this up separately.

If you are setting up a database elsewhere, you need a connection string in the format postgres://user:password@host:5432/dbname. Store this as DATABASE_URL in your deployment environment.

Step 6: Wire in your database migrations

Prisma users: your deployment needs to run prisma migrate deploy before the app starts. This applies any pending migrations to the production database.

Drizzle users: make sure your migration runner is awaited before your server starts listening.

If your deployment platform supports a pre-start command or a release command, that is where migrations go. If it does not, you can add prisma migrate deploy && before your start command:

prisma migrate deploy && node dist/index.js

Step 7: Deploy

Connect your Git repository to your deployment platform. Provide the environment variables from your audit in step 2. Set the build command and start command you confirmed in step 3.

Trigger a deployment and watch the logs. The build should succeed, migrations should run, and the app should start.

If the build fails, look for TypeScript errors or missing dependencies. If migrations fail, check that DATABASE_URL is set correctly. If the app starts but the health check fails, check the port and binding address from step 4.

Step 8: Update OAuth callback URLs

If your app has Google or GitHub login, the callback URL registered with those providers still points to localhost. Log into the Google Cloud Console or GitHub app settings and add your live URL as an authorized redirect URI.

For Google OAuth, add https://yourdomain.com/auth/google/callback. For GitHub OAuth, add https://yourdomain.com/auth/github/callback.

Without this, OAuth login will fail with a redirect URI mismatch error.

Step 9: Set up a custom domain

Your deployment platform will give you a URL. For most projects, you eventually want your own domain.

Point your domain to the platform by adding a CNAME record in your DNS settings. The exact record depends on your platform. Once DNS propagates, usually within a few minutes but sometimes up to an hour, your app is accessible at your custom domain with HTTPS.

Step 10: Test it as a new user

Before announcing your app to anyone, test it as a first-time user:

Open a private browser window with no session, no cookies, and no cached data.

Try to sign up. Go through the full flow as someone who has never heard of your app.

Try to log in. Test OAuth if you have it.

Try the core feature of the app. Make sure it works end to end with a fresh account.

This is the experience your users will have. It is often different from what you see when you test it yourself.

What Jetpacked handles automatically

If you deploy through Jetpacked, steps 4 (port binding), 5 (database provisioning), and 6 (migrations) are handled automatically. Jetpacked detects the framework, the ORM, and the port configuration. It provisions the database, injects the connection string, runs migrations, and starts your app.

You provide the environment variables specific to your app (API keys, OAuth secrets) and Jetpacked handles the infrastructure. The goal is that getting from Cursor to a live URL should take minutes, not a day of reading documentation.