How to Deploy a Vibe-Coded App in 2026 (Step-by-Step)

You built a full-stack app with Cursor, Claude Code, or Lovable in about five minutes. Now it works perfectly on localhost and goes absolutely nowhere on the internet. That is the deployment gap, and it stops more vibe-coded projects than bad code ever does.

This guide covers every deployment option for vibe-coded apps in 2026: what works, what does not, how to identify your stack, and the fastest path from localhost to live URL for each type of app.

Key Takeaway

Identify your stack first (static, full-stack Node.js, Python, or mixed) before choosing a hosting platform, deploying to the wrong one costs an hour.

Static apps (React SPA, plain HTML/CSS/JS) deploy to Vercel, Netlify, or Cloudflare Pages in under two minutes for free.

Full-stack apps with a backend need a runtime environment; serverless platforms like Vercel will break SQLite and persistent file storage.

AI-generated code almost always has three problems before production: hardcoded localhost URLs, missing environment variables, and CORS errors.

What Vibe-Coded Apps Look Like

Before picking a hosting platform, it helps to know what AI coding tools typically produce. The output depends on which tool you used.

Cursor and Claude Code generate code locally on your machine. The typical output is:

• React or Next.js frontends – single-page apps, dashboards, landing pages
• Node.js backends – Express or Fastify APIs, sometimes with SQLite or PostgreSQL
• Python backends – Flask or FastAPI services, data dashboards with Streamlit

Lovable and Bolt.new generate apps in the browser and usually produce:

• React + Vite frontends – often connected to Supabase for auth and database
• Full-stack prototypes – frontend + API routes, ready to demo but often needing cleanup before production (hardcoded URLs, missing error handling)

The key difference from WordPress: these apps need a runtime. WordPress runs on any shared hosting with PHP and MySQL, and tools like InstaWP make spinning up a WordPress site trivial. But a Next.js app needs Node.js. A FastAPI app needs Python. A React SPA needs a static file server. The hosting requirements depend entirely on what the AI generated.

This is where most vibe coders get stuck. WordPress has a thousand one-click hosting options. A Node.js app with SQLite? The options get thin fast.

How to Create a Vibe Coded App?

Let’s start learning the basic of a vibe coded app development.

Step 1: Figure Out What You Have

This is the step most guides skip, and skipping it is why developers end up trying to deploy a full-stack app on a static hosting platform. Look at your project structure and match it to one of these patterns:

• Static or frontend-only (no server needed) You have an index.html file, or a React/Vue/Svelte app with only client-side code. No API routes, no database calls from a backend, no server-side rendering. Look for a vite.config.js with no SSR config, or a plain HTML/CSS/JS folder.
• Full-stack Node.js You have a package.json with a start script that runs a server, Express, Fastify, or Next.js with API routes. Possibly a prisma/ folder or direct database calls. Look for server.js, app.js, next.config.js with API routes, or a src/server/ directory.
• Full-stack Python You have a requirements.txt or pyproject.toml with Flask, FastAPI, or Django. A main.py or app.py that starts a web server. Database operations, background tasks, or file processing.
• Mixed (frontend and separate backend) Two directories — something like frontend/ and backend/ or client/ and server/. The frontend is static, the backend is Node.js or Python. This is common with Cursor-generated apps.

Your stack determines everything else. Get this right before you read another word.

Step 2: Deploy a Static/Frontend-Only App

If your vibe-coded app is purely client-side, React, Vue, or plain HTML, you are in the easy case. Multiple platforms handle this well, most with free tiers, and all of them deploy in under two minutes.

Option A: Vercel

Vercel is the best choice for Next.js apps (they built Next.js) and React SPAs. Use the command below to deploy a static-only app using Vercel.

npm i -g vercel
cd my-app
vercel

npm i -g vercel
cd my-app
vercel

Vercel auto-detects your framework, builds it, and gives you a live URL. The free tier is generous for static sites.

One important gotcha: if your Next.js app has API routes with database calls or file system access, Vercel converts them to serverless functions. SQLite will not work. Persistent file storage will not work. If your app does either of those things, skip to Step 3.

Option B: Netlify

Similar to Vercel but more framework-agnostic, and slightly more flexible for non-Next.js projects.

npm i -g netlify-cli
cd my-app
netlify deploy --prod

npm i -g netlify-cli
cd my-app
netlify deploy --prod

Free tier, automatic HTTPS, and preview deploys for pull requests. Same serverless limitations as Vercel for anything beyond static files.

Option C: Cloudflare Pages

Free, fast, and runs on Cloudflare’s edge network.

npm i -g wrangler
cd my-app
npm run build
wrangler pages deploy dist

npm i -g wrangler
cd my-app
npm run build
wrangler pages deploy dist

Best raw performance for static sites. The Workers platform can handle some backend logic, but it uses a different programming model than what most AI tools generate, so expect friction if you go that route.

All three options work for static apps. Pick whichever you already have an account with. Deploy time is under two minutes for all of them.

Step 3: Deploy a Full-Stack App (Where It Gets Hard)

This is where the deployment gap lives. Your AI-generated app has a backend — an Express API, a FastAPI service, or a Next.js app with server-side rendering and real database calls. The static hosting platforms from Step 2 cannot run it. You need a platform that provides an actual server runtime.

Option A: Railway

Railway detects your stack from your repo and deploys it. It is the closest experience to static hosting simplicity, but for full-stack apps.

1. Push your code to GitHub
2. Connect Railway to the repo
3. Railway detects Node.js or Python, builds, and deploys

Pricing: $5/month subscription plus usage-based billing for compute. A small app typically runs $5 to $10/month. A busier app can climb to $30 to $40/month.

Limitation: No SSH access. Usage-based pricing can surprise you. The database is a separate add-on billed by usage.

Option B: Render

Similar to Railway with a more traditional dashboard interface.

1. Push to GitHub
2. Connect Render, select “Web Service”
3. Render builds and deploys

Pricing: The free tier spins down after 15 minutes of inactivity, meaning your app cold-starts on each visit. Paid plans from $7/month per service. Managed PostgreSQL starts at $7/month extra. The free-tier sleeping behavior is a dealbreaker for anything you want to demo to a client or share publicly.

Option C: CLI Deploy (One Command)

If you want to skip the GitHub-connect-configure-wait flow, CLI deployment is the fastest path. You run a command in your project directory and get a live URL.

One-command deploy platforms like InstaPods handle this for Node.js, Python, and static apps. One command from your terminal:

cd my-vibe-coded-app
instapods deploy 

cd my-vibe-coded-app
instapods deploy 

The CLI reads your project files (package.json, requirements.txt, or index.html), creates a server, uploads your code, installs dependencies, and returns a live URL with HTTPS.

No GitHub repo required, no build config, no Dockerfile. The whole process takes about 5 seconds, you go from terminal to live URL before you can switch browser tabs.

Pricing: $3/mo flat for the base plan. Databases (PostgreSQL, MySQL, Redis) included at no extra cost. No usage billing.

Why this matters for vibe coders: When you’re iterating with Cursor or Claude Code, changing things every few minutes, a CLI deploy that takes 5 seconds beats a GitHub push-and-wait pipeline that takes 2 minutes. You stay in flow instead of waiting for builds.

Option D: VPS (The Honest Option)

You rent a virtual server from DigitalOcean ($6/month), Hetzner ($4/month), or AWS Lightsail ($3.50/month) and configure it yourself. This means SSH-ing into the server, installing Node.js or Python, uploading your code, installing dependencies, configuring a process manager, setting up nginx as a reverse proxy, provisioning an SSL certificate, and configuring the firewall.

The first-time setup runs one to four hours depending on experience. Each step has real gotchas. Nginx config alone has derailed more side projects than bad product ideas.

When this makes sense: if you need full control, want to learn Linux ops, or plan to run multiple apps on one server with shared infrastructure. It is not worth it for a side project you built in five minutes with Cursor.

Deployment Comparison for Vibe-Coded Apps

Step 4: Handle Databases

AI coding tools have a strong preference for SQLite. Cursor and Claude Code generate SQLite-backed apps constantly because it is the simplest option — no external database server, just one file on disk. This works fine on your machine and causes real problems on certain hosting platforms.

The core issue: serverless platforms like Vercel and Netlify have ephemeral file systems. Your SQLite database file disappears on every deploy. If you are on one of those platforms with a SQLite-backed app, you need to either migrate to a hosted database or move to a platform with persistent file storage.

Here is the simplest decision path:

• If the AI used SQLite, deploy to any platform with persistent storage — a VPS, Railway with a persistent volume, or Render with a mounted disk. Do not migrate to Postgres unless you have a specific reason to.
• If the AI used Prisma or another ORM, check the connection string. Switching from SQLite to Postgres usually means changing one line in your config.
• If you need a hosted Postgres, Supabase’s free tier is the most popular choice among vibe coders. Neon is another strong option.

The WordPress Developer’s Cheat Sheet

If you’re coming from WordPress development (maybe you’ve been using InstaWP for staging sites) and vibe coding your first non-WordPress app, here’s the mental model:

The biggest shift: WordPress hosting abstracts the server completely. With Node.js and Python apps, you’re closer to the metal. That’s why the deployment step feels harder – there’s no “one-click install” equivalent for a custom Express API.

The platforms listed above exist to close that gap. Pick the one that matches your stack and budget.

Which Deploy Path Should You Pick for Your Vibe-Coded App?

• Your app is static (React SPA, HTML/CSS/JS): Use Vercel or Netlify. They’re free and deploy in under a minute.
• Your app is full-stack Node.js or Python, and you want the fastest path: Use a CLI deploy tool. One command, live URL, done.
• Your app needs a database: Check if it’s SQLite (deploy anywhere with persistent storage) or Postgres (add Supabase or use a platform with built-in databases).
• You want full control and don’t mind the setup time: Rent a VPS and configure it yourself. Budget 2-4 hours for the first time.
• You’re prototyping and don’t want to pay anything yet: Vercel free tier for frontends, Railway’s $5 credit for full-stack, or Render’s free tier (accepts the cold start tradeoff).

The vibe coding workflow is build fast, deploy fast, iterate fast. If deployment takes longer than building the app, you’ve picked the wrong platform. Pick the deploy option that keeps the loop tight, your next idea is already waiting.

The Most Common Deployment Mistakes with AI-Generated Code

AI coding tools generate working code for localhost. They do not always generate code that works in production. These are the six patterns that cause the most trouble.

1. Hardcoded localhost URLs

AI tools generate code that talks to http://localhost:3000 or http://localhost:8080. This works in development but breaks immediately in production where your API lives at a different URL. Search your codebase for “localhost” and replace every hardcoded URL with an environment variable:

// Before — breaks in production
const API_URL = 'http://localhost:3000/api';

// After — works everywhere
const API_URL = process.env.NEXT_PUBLIC_API_URL || 'http://localhost:3000/api';

// Before — breaks in production
const API_URL = 'http://localhost:3000/api';

// After — works everywhere
const API_URL = process.env.NEXT_PUBLIC_API_URL || 'http://localhost:3000/api';

2. Missing start scripts

Cursor sometimes generates a package.json without a proper start script. The app runs fine with npm run dev locally but has no production entry point. Make sure your package.json includes:

{
  "scripts": {
    "start": "node server.js",
    "build": "next build"
  }
}

{
  "scripts": {
    "start": "node server.js",
    "build": "next build"
  }
}

For Python, ensure you have a clear entry point. Most hosting platforms look for main.py, app.py, or a Procfile.

3. Secrets in the code

AI-generated code often includes placeholder API keys or hardcoded secrets. These need to be set as environment variables on your hosting platform, not committed to your repo. Common ones to check: database URLs, API keys for Stripe or OpenAI, JWT secrets, and SMTP credentials.

4. Building in development mode

React and Next.js apps need a production build. Deploying the dev server is slow and leaks debug information. Run npm run build before deploying, or confirm your hosting platform runs it automatically (most do).

5. Wrong Node.js version

Your local machine might run Node 22 but the hosting platform defaults to Node 18. If the AI used newer syntax or APIs, the app crashes silently. Add an engines field to package.json to lock the version:

{
  "engines": {
    "node": ">=20.0.0"
  }
}

{
  "engines": {
    "node": ">=20.0.0"
  }
}

6. CORS errors after deployment

Works on localhost, breaks in production. Classic. The AI probably set CORS to allow localhost origins only. Update your CORS config to include your production domain

app.use(cors({
  origin: [
    'http://localhost:3000',
    'https://my-app.example.com'
  ]
}));

app.use(cors({
  origin: [
    'http://localhost:3000',
    'https://my-app.example.com'
  ]
}));

Test Before You Ship

One thing most deployment guides do not mention: the fastest way to catch the common mistakes above, hardcoded URLs, CORS errors, missing environment variables, is to test your app in a clean environment before pushing it to a public URL.

For WordPress-connected apps and WordPress-adjacent tooling, InstaWP gives you instant sandbox environments where you can spin up a clean site, test integrations, and verify your setup without touching production. Get started with $25 in free credits; no credit card required.

Keep Reading

• Best AI Coding Tools for WordPress Developers in 2026
• Headless WordPress Frontend – Build and Deploy Guide

Frequently Asked Questions