How to deploy a vibe-coded app, from localhost to a live URL

Your app works. It runs on your laptop, it does the thing, and now you want other people to use it. The gap between those two states feels bigger than it is, and a lot of good little apps die in that gap because "deploying" sounds like a job you need a platform team for.

It isn't. For a small vibe-coded app you can be on a real URL in about fifteen minutes, for the price of a coffee a month. Here's the calm version.

What "deploying" actually means

Right now your app runs because your laptop is on and you typed a command. Deploying just means moving that to a computer that is always on, and giving it a public address so other people's browsers can reach it.

That's the whole idea. A machine that stays running, a public URL, and a lock icon (HTTPS) so the connection is encrypted. Everything below is just the practical way to get those three things without becoming a sysadmin.

Pick a host: start with a platform, not a server

You have two broad options, and for your first deploy one of them is clearly right.

A platform host (Railway, Render, Fly, and Vercel for purely front-end apps) takes your code from GitHub, builds it, runs it, and hands you an HTTPS URL. You don't touch a server. Updates, restarts, and certificates are handled for you. This is where you should start.

A VPS (a raw virtual server from someone like DigitalOcean, Hetzner, or AWS) gives you a bare machine and total control. It's cheaper at scale and lovely when you know what you're doing, but you become the person responsible for security updates, configuring HTTPS, and restarting things at 2am. That's a fine trade later. It's the wrong one for your first deploy.

So: platform host. Pick whichever one supports your stack, connect your repo, and move on. The choice between Railway and Render matters far less than just shipping.

On cost, be reassured. The hobby tiers are genuinely cheap, usually a few dollars a month, sometimes free until you get real traffic. You are not committing to an enterprise bill by putting a side project online.

The five things every deploy needs

Whatever host you pick, a deploy comes down to the same short list. If something breaks, it's almost always one of these.

A start command. The host needs to know how to run your app. Define it in package.json (a start script) or your host's settings. If it runs locally with bun start, that's usually your answer.

Your secrets, as environment variables. API keys, database passwords, tokens, these go in the host's dashboard as environment variables, and your app reads them at runtime. They never go in your code, and they never get committed to git. This is the one rule I'd ask you to never bend. If a key does end up in a commit, rotate it, because git history doesn't forget.

A database that persists. If your app stores anything, it needs somewhere that survives a restart. Most platform hosts offer a managed Postgres or a persistent volume you attach in a couple of clicks. The thing to watch: a plain container filesystem is wiped on every redeploy, so don't keep your only copy of anything there.

A domain. The host gives you an ugly default URL to start, which is completely fine for testing. When you're ready, buy a domain, add it in the dashboard, and point a DNS record at the host. Ten minutes, mostly waiting.

HTTPS. On a platform host this is automatic, the certificate is issued and renewed for you. On a VPS it's your job (look up Caddy or Let's Encrypt). Another reason to start with a platform.

Get those five right and you're live. Get a confusing error, and it's worth checking them in order before you assume something deeper is wrong.

Don't over-build it

The most common mistake I see isn't shipping too little infrastructure. It's reaching for too much.

You do not need Kubernetes. You do not need microservices, a message queue, a multi-region setup, or a load balancer. One small instance, running one app, talking to one database, will happily serve a real product with real users for a long time. Shipyard itself runs as a single server. Plenty of businesses you've heard of started exactly there and stayed there far longer than you'd guess.

Add complexity when something actually hurts, a slow response, a bill that climbs, a limit you keep hitting. Not before. Every piece you add is a piece you now have to understand when it breaks at the wrong moment.

So pick a platform host, set your five things, and put the thing online. You can make it fancy later. Right now the only number that matters is that the count of people who can reach your app goes from one to more than one.