Deploying Vibe-Coded Apps: The Complete Guide

You built something. It works on your machine. Now what?

Deployment is where vibe coders often get stuck. It feels technical. There are too many choices. You’re not sure if you’re doing it right. So you end up running the project locally in a terminal window and calling it done.

That’s not shipping. That’s hiding.

Deployment is actually the easiest part of the entire build process once you understand the landscape. There are five platforms worth considering, each designed for different use cases. Pick one. Follow the steps. Deploy. Done.

This guide covers exactly how to ship from Cursor, Replit, or any editor. We’ll compare platforms, walk through each step, handle environment variables correctly, set up custom domains, and fix the deployment errors that trip up 90% of first-time deployers.

The Deployment Landscape: Five Platforms, Clear Trade-offs

There are dozens of hosting providers. Most of them are noise. These five are the only ones you should seriously consider:

Vercel (Best for Most Projects)

Vercel is the default choice for vibe coders building Next.js, React, or static sites.

Strengths:

• Connects directly to GitHub. Push code, Vercel deploys automatically.
• Zero configuration for Next.js. Works out of the box.
• Free tier is genuinely usable (5 projects, unlimited deployments).
• Next.js creator (Guillermo Rauch) built this, so framework alignment is perfect.
• Fast performance, global CDN, SSL included.

Weaknesses:

• Limited to the Vercel ecosystem (Node.js hosting)
• Can get expensive if you exceed free tier limits
• Vendor lock-in: Built for Next.js, mediocre for other stacks

Best for: Next.js apps, React SPA, static sites. If you’re building with Cursor and shipping a modern web app, Vercel is your default answer.

Cost: Free tier (5 projects, unlimited deployments). Pro: $20/month for team collaboration.

Cloudflare Pages (Best for Speed + Flexibility)

Cloudflare Pages is the global-first choice. It’s built on Cloudflare’s edge network, which means your site runs from servers near your users, not from a single data center.

Strengths:

• Instant global deployment. Your site is fast everywhere.
• Works with any static site generator (Astro, Hugo, Jekyll).
• Free tier is legitimate. No credit card required.
• Cloudflare’s DNS + Pages combo = integrated domain management.
• Serverless functions (Cloudflare Workers) for API routes.
• Best price-to-performance ratio.

Weaknesses:

• Worker functions have constraints (CPU time, memory)
• Learning curve for advanced features (D1 database, KV storage)
• Not the obvious choice for heavy backend servers

Best for: Astro sites, static blogs, marketing sites, JAMstack projects. Also works great for Next.js if you’re willing to build for Edge Runtime.

Cost: Free (unlimited deployments, Pages + Workers). Paid plans for advanced features.

Railway (Best for Backend + Full Stack)

Railway is “Heroku but not dying.” It’s a platform-as-a-service designed for developers who want to deploy anything.

Strengths:

• Deploy containers, Node.js, Python, Go, anything.
• Built-in databases (PostgreSQL, MongoDB, Redis).
• Simple pricing: $5/month base, then pay for what you use.
• Good documentation and support.
• Works with private GitHub repos out of the box.

Weaknesses:

• No free tier (paid only, but starts at $5/month)
• Slower global performance vs. Cloudflare
• Overkill for simple static sites

Best for: Full-stack apps with backend services. Anywhere you need a real server, database, or queue. Also great for migrating from Heroku.

Cost: $5/month minimum. Pay-as-you-go for compute, storage, network.

Netlify (Good but Overcomplicated)

Netlify is polished but trying to do too much. It’s good; it’s just not the best at anything specific.

Strengths:

• Excellent build tools and form handling
• Good CI/CD integration
• Works with multiple static generators
• Teams and collaboration features

Weaknesses:

• Pricing is confusing and gets expensive
• Marketing fluff obscures the actual product
• Cloudflare Pages and Vercel do what it does better

Best for: Marketers who want drag-and-drop site building. Developers should use Vercel or Cloudflare Pages instead.

Cost: Free tier (limited builds). Pro: $19/month.

Render (Similar to Railway, Simpler)

Render is like Railway’s younger sibling. It’s simpler, with cleaner pricing and solid docs.

Strengths:

• Easy deployment from GitHub
• Built-in databases and environment management
• Good for small full-stack apps
• Straightforward pricing

Weaknesses:

• Less mature than Railway
• Smaller community
• Slower performance vs. edge-based platforms

Best for: Small full-stack projects, Node.js/Python apps, when you want simplicity over features.

Cost: Free tier (limited resources). Paid plans start at $7/month.

How to Choose (Decision Tree)

Ask yourself these questions:

1. Is your app mostly static HTML/CSS/JS with no backend?

   • Yes → Cloudflare Pages or Vercel
   • No → Go to question 2

2. Are you using Next.js?

   • Yes → Vercel
   • No → Go to question 3

3. Do you need a database or backend server?

   • Yes → Railway or Render
   • No → Cloudflare Pages or Netlify

4. Do you care about global edge performance?

   • Yes → Cloudflare Pages
   • No → Vercel or Railway

TL;DR priority order:

1. Using Next.js? → Vercel
2. Building with Astro, static site, or just HTML? → Cloudflare Pages
3. Need a backend or database? → Railway
4. Want simple and straightforward? → Render

Deploying from Cursor: Step-by-Step

You’ve built an app in Cursor. Now ship it.

Step 1: Initialize a Git Repository

Deployment platforms watch your Git repository. When you push code, they rebuild and deploy automatically.

Open your terminal (in Cursor, use Cmd+`):

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

That’s it. Your project is now tracked.

Step 2: Push to GitHub

Create a new private or public repo on GitHub. Copy the repository URL. Then:

git remote add origin https://github.com/your-username/your-repo.git
git branch -M main
git push -u origin main

Your code is now on GitHub.

Step 3: Connect Your Platform

If you’re using Vercel:

1. Go to vercel.com/new
2. Click “Import Git Repository”
3. Authorize GitHub and select your repo
4. Vercel auto-detects your framework (Next.js, React, etc.)
5. Click “Deploy”
6. Done. Your site is live.

If you’re using Cloudflare Pages:

1. Go to dash.cloudflare.com → Pages
2. Click “Create a project” → “Connect to Git”
3. Authorize GitHub and select your repo
4. Set build command (e.g., npm run build) and output folder (e.g., dist)
5. Click “Save and Deploy”
6. Done.

If you’re using Railway:

1. Go to railway.app
2. Click “New Project” → “Deploy from GitHub”
3. Authorize and select your repo
4. Railway detects your runtime and deploys
5. Click “View” to see your live site

Step 4: Set Up Environment Variables

Your app probably has secrets: API keys, database URLs, auth tokens.

Never commit these to GitHub. Instead, use environment variables.

On Vercel:

1. Go to your project settings
2. Click “Environment Variables”
3. Add each variable (e.g., NEXT_PUBLIC_API_URL, DATABASE_URL)
4. Re-deploy (push a new commit to GitHub, or manually redeploy)

On Cloudflare Pages:

1. Go to Pages project settings
2. Click “Environment variables”
3. Add variables for both “Production” and “Preview” environments
4. Re-deploy

On Railway:

1. Click “Variables” in your Railway project
2. Add each variable
3. Re-deploy automatically

Important: Variables that start with NEXT_PUBLIC_ (in Next.js) or need to be visible in the browser must be added correctly. Framework-specific variables work differently. Ask your AI what variables you need for your specific framework.

Step 5: Connect a Custom Domain

By default, Vercel gives you your-project.vercel.app, Cloudflare gives you your-project.pages.dev, etc.

To use your own domain (myapp.com):

If you own the domain through the platform:

• Vercel: Go to project settings → Domains → “Add domain”
• Cloudflare: Go to Pages → Custom domains → “Add custom domain”
• It detects your Cloudflare nameservers and connects automatically

If you own the domain elsewhere (GoDaddy, Namecheap, etc.):

1. Go to your domain registrar’s DNS settings
2. Add a CNAME record pointing to your deployment platform
3. Example: www.myapp.com CNAME → your-project.vercel.app
4. Wait 5-30 minutes for DNS to propagate

Cloudflare has the smoothest experience here because it owns the DNS. If your domain is already on Cloudflare, adding it to Pages is one click.

Environment Variables: The Trap Most People Fall Into

This is worth its own section because 40% of deployment failures are environment variable issues.

The Problem

You develop locally with a .env.local file:

DATABASE_URL=postgres://localhost:5432/mydb
API_KEY=abc123xyz

This file is in .gitignore, so it never goes to GitHub. Locally, your app reads it and works great.

Then you deploy to Vercel or Cloudflare. You forgot to add environment variables there. Your app crashes because DATABASE_URL is undefined.

The Solution

For every .env.local variable you have locally, add it to your deployment platform’s environment settings.

Rule of thumb:

• Variables starting with NEXT_PUBLIC_ or PUBLIC_ need to be visible to the browser, so they’re “baked in” during build time.
• Variables without the prefix are kept secret on the server and never exposed to the browser.

Example: If you’re building a Next.js app:

# Public (safe to expose to browser)
NEXT_PUBLIC_API_URL=https://api.myapp.com
NEXT_PUBLIC_ANALYTICS_KEY=xyz123

# Secret (server-only, never expose)
DATABASE_URL=postgres://...
STRIPE_SECRET_KEY=sk_live_...
GITHUB_TOKEN=ghp_...

Add all of these to your platform’s environment settings. The NEXT_PUBLIC_ ones are visible in the browser; the others stay secret on the server.

Common Deployment Errors (And How to Fix Them)

Error: “Build failed. Command ‘npm run build’ exited with code 1”

What it means: Your build process failed. The platform tried to compile your code and it errored.

Fix:

1. Run npm run build locally on your machine
2. Look at the error message
3. Fix it locally first
4. Commit and push
5. Re-deploy

Never push code that doesn’t build locally.

Error: “Cannot find module ‘react’” or “Module not found”

What it means: A dependency is missing. Your code imports a package that isn’t in package.json.

Fix:

1. Run npm install locally to get your full node_modules
2. Check package.json to see if the package is listed
3. If not: npm install package-name
4. Commit and push
5. Re-deploy

Error: “EACCES: permission denied, open ‘/data/.env’”

What it means: Your app is trying to write to the filesystem, but the server doesn’t allow it.

Fix: Don’t write to the filesystem. Use a database instead. Or use a platform-specific solution like Cloudflare KV or Railway persistent volumes.

Error: “Build succeeds, but app shows 404”

What it means: The build passed, but the platform can’t find your HTML file or is using the wrong output folder.

Fix:

1. Check that your dist/ (or build output) folder exists locally
2. Verify the build command in your platform settings (e.g., npm run build)
3. Verify the output folder setting (e.g., dist/ for Vite, build/ for Create React App)
4. Different frameworks use different conventions

Error: “Timeout” or “CPU limit exceeded”

What it means: Your function took too long to run or used too much compute.

Fix:

• Optimize your code (remove long loops, use caching)
• Use a faster platform (Cloudflare Workers have CPU limits; Railway has more headroom)
• If you need heavy compute, Railway is better than Vercel or Cloudflare

Error: “Deployment succeeded but API calls return 500”

What it means: Your frontend deployed fine, but your backend is broken.

Fix:

1. Check your environment variables are set correctly
2. Check that your database is running (if you’re using Railway’s database)
3. Check your backend logs (platform dashboards show logs)
4. Test your API endpoints locally before deploying

CI/CD Basics: Automate Your Deployments

“CI/CD” is just a fancy way of saying “automatically deploy when I push code.”

You’ve already set this up by connecting GitHub to your deployment platform. Here’s what’s happening:

1. You commit code locally: git commit -m "fix bug"
2. You push to GitHub: git push
3. GitHub sends a webhook to your deployment platform
4. The platform runs your build command
5. If it succeeds, it deploys automatically
6. If it fails, it notifies you

That’s CI/CD. No extra setup needed for simple cases.

If you want to customize this:

Most platforms let you set a build.yml or deployment config file:

Vercel: Uses vercel.json in your repo root to customize build settings.

Cloudflare Pages: Uses wrangler.toml or environment variables to control build behavior.

Railway: Uses railway.json or environment variables.

For most vibe coders, the defaults are fine. Only customize if the platform isn’t auto-detecting your framework correctly.

Testing Before You Deploy

The best fix for deployment errors is to avoid them.

Before pushing to production:

1. Build locally: npm run build
2. Run the build output locally: npm start or open the dist/index.html
3. Test in a real browser
4. Check for errors in the browser console (F12 → Console)
5. Only then: Commit and push

Most deployment failures are actually local failures you didn’t catch.

Rollback: What If Things Break?

You deployed and everything is on fire. Don’t panic.

Every deployment platform keeps a history of previous deployments.

On Vercel: Go to your project → Deployments → Click the previous successful deployment → “Promote to Production”

On Cloudflare Pages: Go to your project → Deployments → Click a previous deployment → “Rollback to this deployment”

On Railway: Go to Deployments → Click a previous deploy → “Rollback”

You’re back to the last working version in 30 seconds. No scary recovery process.

This is why shipping incrementally matters: Each commit is a checkpoint you can return to.

The Vibe Coder’s Deployment Workflow

Here’s the loop that works:

1. Build locally in Cursor
2. Test: npm run build and verify it works
3. Commit: git add . && git commit -m "feature: add user auth"
4. Push: git push
5. Watch the deployment (platform dashboard auto-refreshes)
6. Test in production (visit your live URL)
7. If broken, rollback immediately
8. If good, tell people it’s live

This takes 2 minutes end-to-end once you’ve set it up.

---

Related Reading

• How to Start Vibe Coding — Set up your first vibe-coding project
• Cursor Tips and Tricks — Maximize your development speed
• Prompt Engineering Guide — Write better prompts for AI-generated code
• Vibe Coding with Claude — Using Claude for your projects