Fix Your Cursor App: Works Locally, Breaks in Production

You've just spent a few evenings with Cursor, crafting what feels like a genuinely innovative application. It runs beautifully on localhost:3000, the UI is slick, and the backend hums along. You're ready to share it with the world. Then, the inevitable happens: you deploy, and your Cursor app works locally but not in production. This isn't a unique problem; it's a rite of passage for many AI-generated apps that move from local sandbox to live server.

At Convergex AI, we regularly see these issues with 'vibe coded' applications. The gap between 'working on my machine' and 'accessible via a URL' is often wider than expected, leading to frustration and wasted time. The good news is that most of these deployment pitfalls are predictable and fixable. Let's dive in and get your app running reliably.

The Local-to-Production Chasm

Why does a Cursor app that works locally often stumble in production? The core reason is a fundamental difference in environments. Your local machine has a specific configuration, often with local databases, development-specific API keys, and a localhost context. Production environments, on the other hand, are typically:

• Stateless: Filesystems are often ephemeral; what you write might disappear.
• Secure: Secrets are managed differently, not directly from .env files.
• Networked: Applications need to communicate with external services via public URLs, not localhost.
• Scalable: Designed for multiple users and higher loads, requiring robust databases.

Ignoring these differences is the primary reason your Cursor app works locally but not in production. Let's tackle the most common culprits.

Hardcoded URLs: The Silent Killer

One of the most frequent offenders in AI-generated code is the presence of hardcoded localhost URLs. While perfectly functional during local development, these references break instantly when deployed to a live server.

Where to Look for Hardcoded URLs

• API Endpoints: Any fetch requests or Axios calls within your frontend or backend that point to http://localhost:3000/api/.
• OAuth/Authentication Callbacks: Redirect URIs configured with third-party authentication providers (e.g., Google, GitHub, Supabase Auth) often default to localhost during development.
• Image/Asset Paths: Less common for full URLs, but still worth checking if you're serving assets from a local development server.

The Fix: Environment Variables for URLs

The solution is straightforward: externalize all environment-specific URLs using environment variables. This allows you to configure different URLs for development, staging, and production without changing your codebase.

Example:

Instead of:

// Bad: Hardcoded localhost
const API_BASE_URL = 'http://localhost:3000/api';
fetch(`${API_BASE_URL}/users`);

Use:

// Good: Using an environment variable
const API_BASE_URL = process.env.NEXT_PUBLIC_API_BASE_URL || 'http://localhost:3000/api';
fetch(`${API_BASE_URL}/users`);

For frontend variables in frameworks like Next.js, remember to prefix them with NEXT_PUBLIC_ so they are exposed to the client-side bundle.

Environment Variables: The Missing Configuration

Your Cursor app works locally because it's happily reading secrets and configurations from your .env file. However, production servers don't read these files directly. This is a critical point: every secret, API key, and callback URL is missing in production unless explicitly configured, leading to silent failures or crashes.

Audit Every Variable

Before deploying, you need to audit every variable your app needs. Search your entire codebase for process.env references and list them out. This process helps you:

• Separate Concerns: Identify which variables are public (e.g., NEXT_PUBLIC_API_BASE_URL) and which are server-only secrets (e.g., DATABASE_URL, STRIPE_SECRET_KEY).
• Build-Time vs. Runtime: Determine which variables must be available during the build process (common for Next.js API routes or Prisma client generation) versus those only needed at runtime. For example, Prisma often requires DATABASE_URL at build time (Source 6).
• Update Values: Note which URLs and keys still point to local or test values that need to be updated for your production environment.

If you find your Cursor app running into these common deployment issues, it's a sign that the 'vibe coded' prototype needs a professional finish. Convergex AI specializes in helping developers fix Cursor apps and get them production-ready.

Setting Variables on the Production Server

Once you have your audited list, you must load these environment variables from your deploy panel or server environment, not from files. Popular hosting platforms like Vercel, Cloudflare Pages, or Railway provide dashboards where you can add each variable as a key-value pair. Ensure you:

• Add every identified variable.
• Update all callback URLs for third-party services to point to your live domain.
• Rotate any secrets or API keys that were used for local testing to production-grade values.

// Example: Accessing an environment variable
const apiKey = process.env.SUPER_SECRET_API_KEY;

if (!apiKey) {
  throw new Error('SUPER_SECRET_API_KEY environment variable is required.');
}

Database Migration: From SQLite to PostgreSQL

Many Cursor-built apps start with SQLite for simplicity. It's file-based and requires no setup, making local development a breeze. However, SQLite is rarely suitable for production environments because:

• Ephemeral Filesystems: Most cloud hosting platforms use ephemeral filesystems, meaning any data written to SQLite will be lost when your server restarts or scales.
• Concurrency Issues: SQLite doesn't handle concurrent writes well, which is a significant problem for a multi-user production application.

If your Cursor app works locally with SQLite but fails in production, a database migration to a robust relational database like PostgreSQL is almost certainly required.

The Migration Process

1. Provision a PostgreSQL Database: Set up a managed PostgreSQL instance with a service like Supabase, Railway, Neon, or directly through your cloud provider (AWS RDS, Google Cloud SQL). This should happen before your first production deploy (Source 6).

2. Update Connection String: Your ORM (e.g., Prisma) will need a new DATABASE_URL environment variable pointing to your PostgreSQL instance. This variable is crucial and often required at build time.

   # .env.production
   DATABASE_URL="postgresql://user:password@host:port/database?schema=public"
   

3. Run Migrations: Apply your database schema to the new PostgreSQL instance. With Prisma, this typically involves commands like npx prisma migrate deploy or npx prisma db push if you're comfortable with a simpler, non-migration workflow for initial setup. If tables don't exist, your app will throw `PrismaClientKnownRequestError: The table

public.users does not exist(Source 6). 4. **Data Migration (If Applicable)**: If you have existing data in your local SQLite database that needs to be preserved, you'll need to export it and import it into PostgreSQL. Tools likepgloader` or custom scripts can assist with this.

Verifying Your Fixes in a Real Environment

After implementing these changes, don't just assume everything is perfect. The only way to truly confirm your Cursor app works locally but not in production fixes is to test them in a real environment.

• Deploy to Staging: Use a staging environment that mirrors production as closely as possible. Many platforms offer this out of the box.
• Check Logs: Always, always, always check your deployment logs. They are your first line of defense against cryptic errors. Look for environment variable warnings, database connection failures, or API request errors.
• Monitor Network Requests: Use browser developer tools to inspect network requests from your deployed frontend. Ensure they are hitting the correct production API endpoints, not localhost.
• Test Database Connectivity: Perform actions in your deployed app that interact with the database (e.g., user registration, data retrieval) to confirm the PostgreSQL connection and migrations are working as expected.

Platforms like Vercel for Next.js, Cloudflare Pages, or Railway are excellent choices for deploying Cursor-built apps, offering robust environments and good debugging tools (Source 2, 5).

Conclusion

Seeing your Cursor app work locally but break in production is a frustrating but entirely solvable problem. By systematically addressing hardcoded URLs, correctly configuring environment variables, and migrating from SQLite to a production-ready database like PostgreSQL, you can bridge the gap between your local development sandbox and a robust, live application. These steps are crucial for transforming an AI-generated prototype into a reliable, production-ready product.

If these challenges feel overwhelming, remember that Convergex AI specializes in finishing and fixing vibe-coded applications, ensuring they run flawlessly in any environment.