The hosting decision gets exactly two kinds of treatment. The first: "Vercel, I guess" typed without thinking, because Vercel is what the tutorial used. The second: three weeks of Hacker News thread archaeology, comparing egress fees on a spreadsheet for an app with zero users.
Both are the wrong approach. The first will bite you later. The second is just procrastination dressed up as due diligence.
This is an honest field guide for deciding where to deploy your indie app. Which platform wins for which kind of project, where "free" quietly becomes $50/month, and what it actually costs you to leave when you outgrow a platform. No religious opinions. No sponsored rankings.
One note before we get into platforms: hosting and stack are separate decisions, but they're related. If you haven't nailed down your stack yet, start with picking a tech stack without the Reddit rabbit hole. The stack narrows the hosting shortlist considerably.
Start here: what kind of app are you deploying?
Not all apps fit all platforms. The fastest way to cut the comparison list in half is to know which box your app falls into.
Pure frontend, no custom backend. You're deploying a React SPA, a static site, or a Vite app that talks to external APIs. No server-side logic you wrote yourself. This is the easiest case: Vercel and Netlify both handle it brilliantly, and so does Cloudflare Pages.
Full-stack web app with a database. You have a backend (Node, Python, Ruby, Go), a database, and maybe some background jobs. This is where the platforms diverge most sharply. Railway and Render shine here; Vercel works but has caveats.
Long-running processes or background jobs. Cron jobs, queues, websocket servers, anything that stays alive for more than a few seconds per request. Vercel and Netlify are the wrong choice here. Their functions have hard timeouts (10 seconds on Vercel's Hobby tier, 26 seconds on Pro for serverless, though Edge Functions can be even shorter). Railway, Render, and Fly handle persistent processes without drama.
You're using Supabase, Firebase, or another BaaS for your backend. You only need to deploy the frontend. Vercel or Netlify, done.
That last case covers a huge chunk of indie apps, especially anything built with Lovable, v0, Bolt.new, or Cursor with a Supabase backend. If that's you, the decision tree ends here: Vercel, free tier, done.
The free-tier reality check
Every platform has a generous free tier in the marketing materials. Here is where each one actually starts charging you.
Vercel is free for personal projects and genuinely good free. You get unlimited deployments, 100 GB of bandwidth per month, and serverless function invocations up to 100k/month. Where it goes sideways: bandwidth overages ($0.15/GB after the free 100 GB), and the 10-second function timeout on Hobby means some things simply don't work without upgrading to Pro ($20/month). The pro tier also requires all team projects to be on Pro, so if you add a collaborator to a personal project, you're suddenly paying.
Netlify is similar territory. The free tier covers 100 GB bandwidth, 125k serverless function invocations, and 300 build minutes. The function runtime limit is 10 seconds on free, 26 seconds on Pro. Netlify's Pro starts at $19/month. The trap here is build minutes: if you're triggering lots of CI builds (every push, every branch, every PR preview), 300 minutes goes fast.
Railway has no permanent free tier as of 2024. They moved to a $5/month minimum (the Hobby plan), which includes $5 in usage credits. After the credits, you pay for what you use: compute time, memory, egress. For a low-traffic app, $5–$10/month is realistic. For a busier app, it scales with you linearly rather than jumping in pricing tiers. The surprise bill risk on Railway comes from leaving a service running that you forgot about, not from hidden per-request pricing.
Render has a genuine free tier for web services, but with a catch that matters: free web services spin down after 15 minutes of inactivity and take 50+ seconds to cold-start. If your app has any kind of inbound traffic that can't wait a minute, the free tier is effectively unusable for backend services. Render's paid plans start at $7/month per service, which is reasonable. Static site hosting on Render is free with no spin-down issue.
Fly.io is free for small amounts of compute (3 shared-CPU VMs, 160 GB outbound bandwidth), but the free tier is minimal and configuration-heavy. Fly is a container platform: you deploy Docker images, configure regions, and manage more primitives than the others. The payoff is maximum flexibility and the ability to run code close to your users across dozens of regions. Cost for a small hobby app: roughly $3–5/month. Setup time: meaningfully higher than the rest.
The surprise bill scenario most worth worrying about is Vercel + a backend-heavy use case. If you're running a lot of serverless function invocations or hitting bandwidth limits on a viral post, the Pro tier switch can happen automatically depending on your billing settings. Worth checking before you go to sleep. The full cost picture of building an AI-powered app covers this kind of surprise more broadly if you want to read ahead.
The things the marketing pages don't tell you
This is the section for the footnotes.
Egress fees. Vercel and Netlify both charge for data leaving their network after the free bandwidth allowance. For most apps, 100 GB is plenty. But a viral traffic spike or large file downloads will put egress on the invoice in a way you didn't plan for. Railway and Fly charge for outbound bandwidth but are generally cheaper per GB.
Cold starts. Serverless functions on Vercel and Netlify start fresh for each invocation, or spin down during low-traffic periods. For a user clicking a button in your app, a 200-300ms cold start is probably acceptable. For a webhook receiver that needs to respond within a tight window, it may not be. Railway and Render run persistent processes that stay warm.
Region constraints. Vercel's Edge Network is global, but their serverless functions default to a single region (usually US East). If your database is in a different region, you're adding a cross-region round-trip to every database call. Fly is specifically built to fix this problem: you can run your app in the same region as your database easily. For most indie apps this doesn't matter. For latency-sensitive apps or GDPR situations requiring EU data residency, it matters a lot.
Build speed and limits. Netlify's 300-minute build limit on the free tier catches you with iterative deployments. Vercel has generous build limits but can be slower for complex builds. Railway and Render build from source or Docker and have no minute-based limits.
Custom domains on free tiers. All five platforms support custom domains on free tiers. Not a differentiator.
Preview deployments. Vercel and Netlify are the clear leaders. Every pull request gets its own live preview URL automatically. Railway and Render can do this with more configuration; Fly doesn't support it out of the box.
The boring recommendation for most indie apps
If you're a solo founder or a vibe-coder building your first or second app and you want a simple answer: deploy your frontend to Vercel, and use Railway or Render for anything with a persistent server.
More precisely:
- Frontend only (React, SPA, static site): Vercel. Zero configuration, best developer experience, preview deployments work without thinking about them.
- Full-stack with a BaaS (Supabase, Firebase): Vercel for the frontend. You don't need to deploy a backend.
- Full-stack with your own server: Render for simplicity, Railway for price predictability as you grow.
- Region constraints, WebSockets, or maximum control: Fly.io. Accept that setup takes longer.
- Netlify: a fine Vercel alternative if you're already on it. Not a reason to switch if you're starting fresh.
The boring recommendation for 90% of apps built with Cursor, Lovable, Bolt.new, or v0: the BaaS handles your backend, Vercel handles your frontend, and the only hosting decision you'll make is linking a GitHub repo and clicking deploy. That's the actual right answer for that use case.
How painful is it to leave each platform?
This question matters more than people realize, because the platform that's right for a 100-user app is often not right for a 10,000-user app. Knowing the migration cost changes how seriously you take the initial choice.
Leaving Vercel. Relatively painless. Vercel is a deployment platform for standard web apps, and almost everything it runs can be deployed elsewhere. If you're using Vercel serverless functions extensively, there's some rewriting involved. If you're on Edge Runtime with Vercel-specific APIs, there's more. If you're using Vercel's KV, Blob, or Postgres storage products, plan for a real migration. The more you lean into Vercel's proprietary storage products, the stickier it gets.
Leaving Netlify. Similar to Vercel. Netlify Functions are AWS Lambda under the hood, so migration paths exist. Proprietary add-ons create lock-in; the core hosting does not.
Leaving Railway. Easy in principle: Railway runs standard Docker containers and doesn't impose proprietary APIs. Your code runs on Railway because you pointed it there, not because you integrated any Railway-specific SDK. You can take the same container to Fly, Render, or any VPS.
Leaving Render. Same story as Railway. No lock-in at the platform level. The Docker image you gave Render works anywhere.
Leaving Fly.io. The most portable of all. Fly is container-first, so your Docker image goes wherever Docker goes.
The lock-in risk for hosting is almost never the code. It's the data. Keep your data in a real database (Postgres via Supabase or Neon) and your files in an object store you control (S3 or R2), and the hosting layer stays swappable.
What actually matters when you're deciding
You're not picking a hosting platform for life. You're picking one that gets you to users without a surprise invoice and without three weeks of configuration.
The real decision is whether your app needs a persistent process. If it doesn't, Vercel. If it does, Railway or Render. If you need fine-grained region control, Fly.
Know which box you're in before you start configuring. That means knowing what you're building first. Draftlytic helps you think through the structure upfront, so you're not knee-deep in a deployment that doesn't fit what you made.