You built something. The AI wrote the code, it runs on your machine, you can click around in it — and now it’s stuck on localhost, which is the one address nobody else on earth can visit. Getting it the rest of the way, from “works on my laptop” to “has a real URL,” is the step where a lot of first projects quietly die.
It shouldn’t. Deploying a vibe-coded app is genuinely easy in 2026, and for most projects it’s free. The catch is that the right way to deploy depends entirely on what your app actually is — and AI tools love to generate code that runs beautifully on localhost and then falls over the moment it hits a real server. This guide gets you live and warns you about the cliffs.
If you haven’t built the thing yet, start with our walkthrough on building your first project with AI and come back here when you have something that runs.
First, figure out what kind of app you have
This is the one decision that determines everything else, and it’s the step people skip. Deploy to the wrong kind of host and you’ll spend an hour fighting errors that have nothing to do with your code.
There are really only three buckets:
- Static app — Plain HTML/CSS/JavaScript, or a React/Vue/Next.js frontend with no backend of its own. It talks to APIs (if at all) directly from the browser. The vast majority of “build me a landing page / dashboard / portfolio” prompts produce this.
- Full-stack app with a server — Has its own backend: an Express or FastAPI server, API routes, server-side logic. Anything where the AI wrote code that “runs on the server” lives here.
- Full-stack app with a database — All of the above, plus it stores data that needs to persist: users, posts, orders. This is where hosting gets opinionated.
Not sure which you have? Ask the AI that built it. A prompt like “Is this a static frontend, or does it have a backend server and a database? What do I need to deploy it?” gets you a straight answer and usually a deployment checklist too.
Serverless hosts like Vercel and Netlify are fantastic for static and frontend apps — and they will silently break an app that expects a long-running server or a local SQLite file. The mismatch is the single most common reason a deploy “works” but the app doesn’t.
The fast path: static and frontend apps
If you have a static or frontend-only app, you’re minutes away from live. Three hosts dominate this space and all three have a genuinely free tier:
- Vercel — The default for React and Next.js. Connect a GitHub repo, it auto-detects the framework, and every push redeploys. Best choice if your app is or might become a Next.js app.
- Netlify — Excellent for static sites and simple frontends. Built-in form handling and basic auth are nice extras if you don’t want a backend at all.
- Cloudflare Pages — Fast, generous free tier, great if you’re already using Cloudflare for your domain.
The workflow is nearly identical for all three:
Get your code into GitHub
If your app only exists in a folder on your computer, it needs a home first. Create a free GitHub account, make a new repository, and push your project to it. Don’t know git? Ask your AI tool: “Walk me through putting this project on GitHub from scratch, assuming I’ve never used git.” Most AI coding tools can run the commands for you.
Connect the host to your repo
Sign up for Vercel, Netlify, or Cloudflare Pages with your GitHub account. Click “New Project,” pick your repository, and let it auto-detect the settings. For 90% of apps the defaults are correct — framework detected, build command filled in, output folder set.
Deploy and grab your URL
Hit deploy. A minute or two later you have a live your-app.vercel.app URL you can send to anyone. From now on, every time you push a change to GitHub, the host rebuilds and updates the live site automatically. That’s it — you’re in production.
If the build fails, don’t panic — it’s almost always a missing build command or a wrong output directory. Copy the full error log, paste it into your AI tool, and ask it to fix the build configuration. This is exactly the kind of problem covered in our guide to debugging AI-generated code.
The fuller path: apps with a server or database
The moment your app has a real backend, the serverless hosts above stop being a perfect fit. A long-running Express server, background jobs, or a database that needs to keep its data between requests all need a platform built for that.
Two hosts make this easy without forcing you to become a DevOps engineer:
- Railway — Connect a repo and it’ll run your server, give you a managed Postgres database, and handle the wiring. The cleanest option for a vibe-coded full-stack app. Small monthly free-ish credit, then usage-based.
- Render — Similar idea: web services, databases, and a persistent disk if your app writes files. Has a free tier for small services (they sleep when idle, which is fine for a demo).
AI tools love to reach for SQLite because it’s zero-config on your laptop — it just writes to a file. On a serverless host that file vanishes between requests, so your data disappears. If the AI used SQLite and you have real data to keep, either deploy to a host with a persistent disk (Railway, Render) or ask the AI to migrate the app to Postgres before you launch. It’s a five-minute prompt now versus a confusing data-loss bug later.
Environment variables and API keys
If your app uses any API keys — for an AI model, a payments provider, an email service — they are almost certainly sitting in your code or a .env file right now. Two rules:
- Never commit secrets to GitHub. Make sure your
.envfile is listed in.gitignore. If you’ve already pushed a key, rotate it (generate a new one) — assume the old one is burned. - Set them in the host’s dashboard instead. Every platform above has an “Environment Variables” section. Paste your keys there, and the live app reads them securely at runtime.
This is the number-one security mistake in deployed AI apps, and it’s worth doing right the first time. We go deep on it in our guide to vibe coding security risks — read that before any app you build touches real users.
”It worked on localhost” — why production is different
Here’s the part nobody warns first-time builders about: AI tools are trained to produce code that works under ideal conditions — clean inputs, one user, a local machine, a tiny dataset. Production is none of those things. Apps that run flawlessly on your laptop hit a different set of problems the moment they’re live: hardcoded localhost URLs, missing environment config, file paths that don’t exist on the server, and edge cases the happy-path code never considered.
This isn’t a reason to avoid deploying — it’s a reason to deploy early and often, while the app is small and the surface area is easy to reason about. If you want the full picture of what tends to break and how to get ahead of it, we wrote a whole piece on why vibe-coded apps break in production.
A deployed app that’s a little rough beats a perfect app on your laptop that nobody can see. Get it live, get feedback, then harden it. The hardening is a phase, not a prerequisite.
Quick reference: which host for which app
| Your app | Best free host | Watch out for |
|---|---|---|
| Static site / portfolio | Netlify or Cloudflare Pages | Nothing — easiest case |
| React / Next.js frontend | Vercel | Set env vars in the dashboard, not the code |
| Frontend + a few API routes | Vercel | Long-running tasks will time out |
| Full-stack with a server | Railway or Render | Free services may sleep when idle |
| Anything with a database | Railway or Render | The SQLite trap — migrate to Postgres |
What to do next
Pick the row that matches your app, push your code to GitHub, and deploy it today. Don’t overthink the host — you can always move later, and for a first project any of these is fine.
Once it’s live, the work shifts from building to refining — fixing the rough edges, closing the security gaps, handling the inputs you didn’t expect. That’s a prompting skill more than a coding one, and it’s exactly what our prompt library and our guide to writing better AI coding prompts are built to help with. Ship the thing, then make it solid.
