For indie hackers, startups, and infra nerds. Cost, speed, ease-of-use breakdown with real-world deployment logs. Bonus: when to not use the big clouds.
Press enter or click to view image in full size
Too many clouds. Too many tutorials. Not enough real talk.
You can host an app in 100 different ways now but half of them make you feel like you need a PhD in cloud billing, and the other half break the moment you scale past 10 users.
I wanted to figure out what actually works.
So I took 5 real projects ranging from static sites to fullstack apps with WebSockets and DBs and deployed each one across platforms like AWS, Azure, Vercel, Fly.io, Render, and Railway.
This is a devlog, not a cloud marketing pitch. It covers:
- Setup time (from repo to prod)
- Cold starts, scaling, and latency
- How much it cost me (spoiler: AWS still hurts)
- Logs, configs, DX wins, and backend limits
- One brutally honest meme you’ll feel in your wallet
If you’re an indie hacker, early-stage startup dev, or infrastructure nerd who’s tired of “best cloud in 2025” listicles, this post is for you.
What I am covering in this article:
1. The 5 projects real-world context
Quick overview of each project, what it needed, and why hosting choice mattered
2. AWS Still the king? Or just complicated royalty?
Setup friction, Lambda latency, infra-as-code, billing pain
3. Azure Surprisingly usable… for once
Nice UI, okay pricing, confusing docs, GitHub deploys
4. Vercel The MVP launcher’s best friend
Lightning speed, perfect for Next.js, hits backend walls fast
5. Other clouds Fly.io, Render, Railway
The good, the bad, and the “I’d maybe use it again”
6. Comparison table cost, speed, ease, gotchas
One big table with final ratings per platform
7. When not to use the big clouds
Why sometimes a $5 VPS > fancy serverless everything
8. Final thoughts Hosting in 2025
My actual go-to stack now + helpful tools and links
The 5 projects real-world context
Before we talk performance, pricing, or platform pain, here’s a quick overview of what I actually hosted. No “hello world” fluff just real apps with real requirements.
Press enter or click to view image in full size
Why this matters
Each project had very different needs:
- Some were static-heavy with occasional dynamic API routes.
- Others had persistent WebSockets, which ruled out some serverless platforms.
- A few needed cron jobs, background workers, or file storage.
- And most of them needed “just enough” scalability without melting my wallet.
I wasn’t just testing hosting platforms I was stress testing what kind of project fits where.
AWS Still the king? Or just complicated royalty?
I used AWS to host TelemetryX, my realtime dashboard project that pulls system metrics, processes them with Go services, and serves a live UI to users with a React frontend. It also runs scheduled jobs to aggregate daily data.
What I used:
- API Gateway + Lambda (for metrics API)
- ECS Fargate (for long-running Go services)
- S3 + CloudFront (for React frontend)
- EventBridge + CloudWatch (for cron jobs & logging)
- Infra-as-code via Terraform
Setup time: 9 hours
Not a typo. Between setting up IAM roles, wiring VPCs, defining security groups, and fighting Terraform state files, it ate nearly a full day.
Deploying the React frontend to S3 with CloudFront was the easy part.
Here’s a snippet from the main.tf for ECS + Fargate:
h
resource "aws_ecs_cluster" "main" {
name = "telemetryx-cluster"
}
resource "aws_ecs_task_definition" "app" {
family = "telemetryx-app"
requires_compatibilities = ["FARGATE"]
cpu = "256"
memory = "512"
network_mode = "awsvpc"
...
}
It worked. Eventually. But it wasn’t fun.
Cold starts & latency
For the Lambda + API Gateway combo, cold starts averaged ~500ms in us-east-1. It wasn’t game-breaking, but noticeable on the first API hit. After warm-up, performance was solid.
Realtime data came from ECS services over internal VPC endpoints, which added complexity but improved latency once tuned. Monitoring via CloudWatch helped catch a rogue job that ballooned memory to 800MB (thankfully caught before it cost me $50).
Cost breakdown (monthly)
Press enter or click to view image in full size
Could be worse. Could be better. Definitely wouldn’t call it “free-tier friendly.”
Verdict
When AWS worked well:
- When I needed multiple services talking to each other
- When I cared about region placement & scaling knobs
- When I was okay debugging 3-letter acronym errors
When it didn’t:
- Getting started is rough
- Complex projects snowball in config hell
- Cold starts for API Gateway + Lambda aren’t ideal for snappy UX
TL;DR:
AWS is like the Elden Ring of cloud providers. You can do incredible things, but you’ll suffer if you don’t spec your build properly.
Azure Surprisingly usable… for once
I used Azure for DevChat, a fullstack chat app built with FastAPI, PostgreSQL, and Socket.IO. I expected pain. I got… a mostly tolerable experience.
What I used:
- Azure App Service (for FastAPI backend)
- Azure Web PubSub (for Socket.IO over WebSockets)
- Azure Database for PostgreSQL
- Azure Monitor (for logs & tracing)
- GitHub Actions for CI/CD via Azure’s built-in deploy pipeline
Setup time: ~3.5 hours
Creating resources via the portal UI was actually smooth.
Azure’s App Service had “Deploy from GitHub” built-in, so I had preview environments and auto-deploys working in under an hour.
The only catch? Azure loves to rename things constantly.
At one point I was 95% sure “Azure Static Web Apps,” “App Service,” and “Function Apps” were just different names for the same thing. They are not. That rabbit hole took 40 minutes of documentation reading.
Here’s what the GitHub Action deploy looked like:
- name: 'Deploy to Azure Web App'
uses: azure/webapps-deploy@v2
with:
app-name: 'devchat-backend'
publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
package: '.'
It Just Worked™ and I didn’t hate myself after writing it.
Realtime performance
Azure Web PubSub did its job.
Socket.IO stayed connected under low to moderate traffic, latency was ~30–60ms from EU regions, and reconnects were minimal even after sleep or mobile toggles.
The biggest issue was connection limits on the free tier, which forced me to scale to a Standard SKU just to test concurrent user spikes. Not terrible, but worth noting.
Cost breakdown (monthly)
Press enter or click to view image in full size
Almost identical to AWS in cost, but easier to set up and maintain.
Verdict
When Azure worked well:
- GitHub integration made deploys effortless
- WebSockets were stable, surprisingly
- Portal UI was genuinely helpful
When it didn’t:
- Service names are a naming disaster
- Some docs are outdated or weirdly inconsistent
- Debugging issues in Web PubSub took way too many clicks
TL;DR:
Azure felt like the Microsoft Office of cloud hosting. It works surprisingly well but you will click too many buttons, and half the settings live in a tab you forgot existed.
Vercel The MVP launcher’s best friend
I used Vercel to host ShopPilot, a Next.js e-commerce MVP with dynamic routes, a Stripe integration, and a small PostgreSQL backend (hosted separately on Supabase).
And yeah Vercel was stupid fast to set up.
What I used:
- Next.js app with API routes
- Vercel Edge Functions (for auth + Stripe)
- Environment variables via dashboard
- Supabase (hosted DB + auth, not part of Vercel)
- Custom domain + automatic HTTPS
Setup time: ~15 minutes
No joke. I connected my GitHub repo, selected the main branch, and Vercel built + deployed it before I finished making coffee.
Preview deployments? Automatic. Rollbacks? One click.
Even my environment variables were picked up without manual .env dancing.
Here’s a vercel.json I used for rewrites + API routing:
{
"rewrites": [
{ "source": "/api/(.*)", "destination": "/api/$1" }
],
"cleanUrls": true,
"trailingSlash": false
}
The DX was smooth from start to finish.
It felt like deploying on Easy Mode.
Performance & limits
Cold starts were non-existent on static and edge functions.
Edge functions were blazing fast in most regions (EU and US East), with ❤0ms latency on average.
But Vercel starts to push you toward upgrades fast:
- Background jobs? Nope.
- Custom backend? Bring your own server.
- Long-running tasks or queues? You’re on your own.
Also, while serverless is cool, function execution time was capped, which made Stripe webhook retries fail occasionally under load.
Cost breakdown (monthly)
Press enter or click to view image in full size
Even with Supabase in the mix, this was my cheapest and fastest stack to deploy.
Verdict
When Vercel worked well:
- Instant deploys, previews, HTTPS, CI/CD all out of the box
- Perfect for frontend-heavy apps with light serverless needs
- Super fast edge performance
When it didn’t:
- You’ll need to offload anything “backend-ish”
- Pricing gets fuzzy at scale (functions + bandwidth = surprise bills)
- No cron jobs, workers, or background tasks
TL;DR:
Vercel is what I wish AWS felt like. It’s the best place to throw up a SaaS MVP. Just don’t try to run your backend inside it or you’ll start duct-taping Supabase, cron jobs on GitHub Actions, and Firebase functions like a madman.
Other clouds Fly.io, Render, Railway
Sometimes you don’t need AWS-scale or Vercel-slickness you just want simple hosting that doesn’t suck.
So I tried a few solid alt-clouds for my remaining projects.
Notedrop on Railway.app
A small realtime note app using Nuxt + Supabase + WebSockets. Railway felt like the perfect home for this kind of lightweight project.
Why I picked it:
- Built-in Postgres support
- Deploys from GitHub
- Realtime logs, fast CI/CD
- Free tier was enough for testing
railway init
railway up
Yes. That’s it.
Deploy time: ~5 mins
Gotchas: CLI updates break sometimes; environment variables were quirky
Cost: $0 (free tier, 500 hours/month)
Would use again: Absolutely, for prototypes
Snapsight on Render
Static site with a dynamic image search (Astro + S3 + Algolia). Needed background job support and some serverless routing. Render delivered.
What worked:
-
render.yamlfor infra-as-code - Easy static hosting w/ API backend
- Cron job support (!)
- Great dashboard UX
services:
- type: web
name: snapsight-api
env: node
plan: free
Deploy time: ~10 mins
Gotchas: Sometimes builds just hang? UI gets sluggish
Cost: ~$7/month total (static + Node service)
Would use again: Yep especially for fullstack projects that aren’t giant
TelemetryX on Fly.io (originally tried AWS, but…)
Switched TelemetryX over from AWS → Fly.io after hitting config fatigue. Fly has a very cool “run anywhere near your users” model with edge VM support.
What I liked:
- Docker deploys with minimal config
- Built-in metrics, logs, CLI that doesn’t feel like a relic
- Free PostgreSQL starter DB (shocking)
fly launch
fly deploy
Deploy time: ~15–20 mins (mostly waiting for image build)
Gotchas: Networking is a bit weird; debugging health checks is painful
Cost: ~$13/month for app + DB
Would use again: Yes, for global apps and hobby projects
Verdict
Press enter or click to view image in full size
Comparison table cost, speed, ease, gotchas
Here’s how all five platforms (plus the wildcards) stacked up across real-world usage.
This isn’t just theory this is what actually happened when I shipped production apps on each.
What these ratings really mean:
- Setup Time: Anything over 3 hours = pain. Vercel spoiled me.
- Cost: Under $50/month is fine for MVPs. AWS + Azure toe the line.
- Speed: Vercel’s edge network is 🔥. Fly.io comes close. Lambda is hit or miss.
- Ease of Use: Vercel wins. AWS loses. Azure’s UI helps. Railway is basically Heroku reborn.
- Gotchas: Everyone has one. Even the “simple” platforms can bite back.
TL;DR?
If I had to spin up a new MVP right now:
- Frontend-heavy app with light APIs? → Vercel + Supabase
- Fullstack chat app or dashboard? → Render or Fly.io
- Heavy compute, real scheduling? → AWS or Azure if I have time to waste
- Trying something fast just to demo? → Railway every time
When not to use the big clouds
AWS and Azure are powerful. No doubt.
But should you really spin up an S3 bucket, 5 IAM roles, a VPC, 2 Lambdas, and a broken billing alarm just to host your side project?
Probably not.
Here’s when I learned the hard way not to use the big clouds:
For MVPs or prototypes
Unless you’re building the next Stripe or Twitch, don’t waste hours wiring up AWS for your weekend project. Use Vercel, Railway, or Render.
You’ll ship faster, cheaper, and with less config PTSD.
When your app is mostly frontend
Serverless and static-first platforms (like Vercel, Netlify, Astro.build, or even Cloudflare Pages) crush it here.
Why spin up 12 microservices when all you need is fast CDN hosting with edge functions?
When time > customization
The deeper you go into AWS or Azure, the more you trade flexibility for complexity.
If you’re trying to validate a product or iterate quickly, those 200 service dashboards aren’t helping.
When your infra budget is $0
Yes, the free tiers exist. No, they’re not easy to monitor.
One mistake on AWS (like forgetting to turn off a Lambda or choosing the wrong DB region) and you’re suddenly holding a surprise $83 bill with no refunds.
When you don’t have a DevOps person
If your “DevOps team” is just… you, don’t pick a stack that expects deep knowledge of IAM policies, VPC peering, or container orchestration.
Start with a platform that lets you stay in dev mode, not ops mode.
So when should you use AWS or Azure?
You need fine-grained control over networking, scaling, or security
You’re building multi-region infra with real uptime SLAs
Your company already has credits (hey, why not)
You’ve got infra engineers who love pain
TL;DR:
Don’t over-engineer your hosting stack. Pick the tool that gets your app into users’ hands the fastest and scale up when you actually need to.
Press enter or click to view image in full size
Final thoughts Hosting in 2025 and what I’d do differently
After trying all these platforms across 5 real projects, here’s what I realized:
You don’t need the “perfect cloud.”
You need the right cloud for the stage you’re in.
My current go-to strategy (2025 edition)
For most indie devs and small teams, here’s the stack that worked:
Press enter or click to view image in full size
Start simple. Add complexity only when your users force you to.
What I’d do differently
- Set budget alerts from day one (especially on AWS)
- Use infra-as-code early (even on Render or Fly.io)
- Don’t trust “free tiers” check bandwidth and function limits
- Stick to PostgreSQL or SQLite unless you have a reason not to
- Build locally first, deploy late don’t debug in prod
Helpful tools & links
- Vercel Great for frontend-first projects
- Fly.io Edge VMs with global reach
- Render Fullstack-friendly and stable
- Railway Super fast for protos
- Supabase DB + auth + storage that works
- Terraform Infra as code (worth learning)
- Budget Alerts (AWS) Please… save your wallet
Final TL;DR
- Vercel is perfect for MVPs.
- AWS is powerful, but punishing.
- Azure is… not bad anymore (weird, right?).
- Fly.io and Render are low-key underrated.
- Use the simplest thing that works until it doesn’t.
Thanks for reading!
If this helped you avoid cloud regret, consider sharing it with your team or that one friend who’s about to manually configure NGINX on an EC2 box 😅
Top comments (0)