How to Deploy a Web App You Built With AI

So you built a web app and it runs on your laptop. Now you want strangers to reach it. Here's how to deploy a web app in one breath. Pick a managed host, connect your git repo, set your environment variables, and hit deploy. That's the happy path, and it's genuinely shorter than it used to be. The part nobody warns you about is everything that happens after the deploy button goes green, which is where most of this page lives.

I deploy things for a living, more or less. I build and run real products with Cursor and Claude Code, an AI studio called Apatero and a tool directory called Tool Index among them, and they live on a mix of managed hosts and a small cluster I run myself. If building the app this way is still new to you, I wrote the plainer version of what vibe coding actually is first. This one assumes the app already works locally and you just need it on the internet.

What the First Page Is Missing

I read the top results before writing anything, same as always. The number two spot is a Reddit thread. Actual position two, a guy on r/webdev asking the same thing you're asking, ranking above almost every real guide. When a forum post beats the tutorials, it usually means the tutorials are answering a slightly different question than the one people actually have.

The rest is a spread. MDN walks you through GitHub Pages, which is great, except it only does static sites, so the moment your app has a login or a database it can't help you. freeCodeCamp points you at an hour-long video. GeeksforGeeks lists eight platforms and never tells you what a single one costs. Not one page on that first screen puts real, current prices next to each other, and not one is written by someone deploying apps an AI helped build, which is most of you now. So that's the hole I'm filling.

First, What Kind of App Do You Actually Have

Before you pick a host, answer one question, because it decides everything after it. Does your app have a backend that stays running, or is it just files a browser downloads?

If it's a static site or a frontend, a React or Svelte or plain-HTML thing that talks to APIs but doesn't run its own server, you want a frontend host. Vercel, Netlify, Cloudflare Pages. They take your repo, run the build, and serve the result off a CDN, and they're stupidly good at it.

If your app runs a server that has to stay awake, an Express or FastAPI or Django backend, a database it queries, background jobs, then you want a host that keeps an always-on box running for you. Railway, Render, that category.

Plenty of apps are both, a frontend on one host and a backend on another, and that's normal, nobody's going to dock you points. But knowing which half you're deploying is the exact thing the eight-platform listicles skip, and it's why people pick a host that physically can't run their app and then sit there confused about why nothing works.

The Managed Hosts, With Numbers That Are Actually Real

Here's the table I wish the ranking pages had. I pulled every one of these off the hosts' own pricing pages in July 2026, because these numbers move and a stale price is worse than no price.

Sources, all checked July 2026: vercel.com/pricing, netlify.com/pricing, pages.cloudflare.com, railway.com/pricing, render.com/docs/free.

A couple of things a table cell can't hold. That Vercel non-commercial line trips people up constantly. You build your side project on the free Hobby plan, it runs great, then you bolt on a Stripe button and now you're technically supposed to be on Pro. Nobody at Vercel is kicking your door in over a hobby project, but if you're building a business, just budget the twenty bucks. And Render's free tier napping is not a footnote. A visitor clicks your link, waits a full minute at a blank screen, and leaves. For a demo you're showing one friend, free is perfect. For anything a stranger might land on cold, pay the seven dollars or pick a host that doesn't sleep.

Where the AI-Built Part Bites You

Here's the stuff that's specific to apps an agent helped write, and it's the reason I bothered with this instead of just linking you to MDN.

The build passes on your machine and dies on the host. Happens constantly. The agent installed something locally that never made it into your package file, or it leaned on an environment variable that only exists on your laptop, and the production build has no clue what you mean. So you're reading deploy logs at midnight for a typo you didn't write. I've done it more times than I'd like to admit.

Then there's the bug the agent is weirdly proud of. You ask it to fix one thing, it fixes it, and it also quietly rewrites a nearby function it decided looked messy, and that function was holding something up. On one build an agent tidied some auth code I hadn't asked it to touch, and for about a day a logged-out stranger could load a page they had no business seeing. Nothing errored. I only caught it clicking around in a private window out of pure paranoia, which is now a permanent step in how I work.

Here's the one that cost me real stress. On Tool Index my first sale was $29.99, and it turned up maybe two months after I put the pricing page live. I checked the database three separate times that the payment webhook had actually flipped the order to paid, because the agent's first version of that webhook silently hadn't. The deploy worked. The feature it deployed didn't. Those are two different things, and the gap between them is basically the whole job. If you want the longer version of that shipping-half story, I put it in how to build a SaaS with AI and actually ship it.

Set the Env Vars, Then Set Them Again on the Host

This is the single most common reason a first deploy face-plants, so it gets its own heading even though it's small.

Your app reads its secrets from a .env file on your laptop. That file does not get deployed, and it shouldn't, it's stuffed with keys you never want in your repo. Every managed host has a settings panel where you paste those same variables in by hand. Miss one and the app builds fine, then crashes the instant it tries to reach your database or your payment provider. The fix is boring. Open your local .env, and copy each key into the host's environment settings before your first deploy, not after it breaks at 11pm.

Should You Just Host It Yourself

I'm about to give you advice I don't personally follow, which is the most honest kind there is.

I run a chunk of my own stuff on a small Kubernetes cluster I manage on a rented server. Full control, cheap once you've got a few things on it, and I like knowing where everything lives. And I'd tell you, deploying your first app, do not do that. Self-hosting means you now own the operating system updates, the SSL certificates, the firewall config, the thing that quietly falls over at 3am. A managed host handles all of that, and its free tier covers you until you have real users. I self-host because I run a pile of apps and the control pays off spread across all of them. For one app you're trying to get live this week, it's a hobby wearing the costume of a decision. Start managed. Move later if you ever genuinely need to, and you probably won't.

The Questions Everyone Types Into Google

A cluster of these follow this search around, so, quick answers, straight.

How much does it cost to host a web app? To start, nothing. Every host up in that table has a free tier that carries a small project. The cost shows up when you get real traffic or you start taking money, and even then a small live app runs you somewhere from a few dollars to twenty a month on hosting, plus a domain, which is cheap, plus whatever cut your payment processor skims off each sale. It isn't the hosting that gets pricey. It's the app getting popular, which is the good kind of problem.

Where can I deploy my web app for free? Cloudflare Pages if it's static, genuinely free with unlimited bandwidth. Netlify or Vercel's Hobby plan for frontends, though remember Vercel's free tier is personal-use only, so don't run a business on it. Render's free tier for a backend, as long as you can stomach it sleeping. Free is real here. Free with zero asterisks is rarer.

Is deploying a website hard? The happy path, no. Connect a repo, click deploy, live in minutes, and that part is genuinely easier than it was five years back. The hard part isn't the first deploy. It's the second one, where production behaves differently than your laptop and you're hunting for why.

How do you deploy your own web app, start to finish? Push your code to GitHub. Sign into a managed host using that same GitHub account. Point it at the repo. Paste in your environment variables. Deploy. Then open the live URL in a private window and click every important thing, because that's where you find what the deploy didn't bother telling you.

Can ChatGPT build the app in the first place? It can write a lot of the code, sure, same as Claude or Cursor can. Writing the code and getting it live are different sports though, and the second one is what this whole page is about.

What I'd Tell You Before You Click Deploy

Ship it ugly and ship it early. The first deploy, while your app is tiny, is the cheapest one you'll ever run, and getting the pipeline working before there's much riding on it means the production-only weirdness surfaces when it's a five-minute fix instead of the night before you show people.

Everything I've shipped adds up to something like ten grand lifetime, cumulative, across a heap of products, not per month, and I bring that up only so the deploy-your-app-and-get-rich crowd gets a reality check from someone who actually deployed. The deploy itself is quick, a twenty-minute job the first time and two minutes after that. The hours all go into the bugs. Now you at least know which ones to expect before you go looking.