T

This is a different kind of post.

I've deployed on Fly.io, Railway, Render, and raw VPS in real production environments. Each has a legitimate use case. Each has a cliff you don't see until you're already falling. By the end of this you'll know which option fits your stack and your budget, and which ones are traps dressed up as good developer experience.

What You're Actually Comparing

This isn't a feature matrix exercise. Four things decide which platform is right:

Traffic pattern. Steady and predictable, or spiky and seasonal? If you're running an e-commerce platform in Indonesia, your Lebaran traffic looks nothing like your January traffic. Some platforms handle that gracefully. Others hand you a surprise invoice.

Stack. A Next.js app with heavy server-side rendering is a different animal from a stateless Go API. Not every platform handles Next.js well outside of Vercel's own infrastructure.

Team ops maturity. Can someone on your team own infrastructure decisions? Or does every deployment need to just work without touching a config file? Be honest here.

Budget horizon. Cheap now versus cheap at scale are often different platforms.

Fly.io: The Best Option You Have to Earn

Fly.io is not a platform-as-a-service in the traditional sense. It's closer to a global VM orchestrator with a very good CLI. You define your app in a fly.toml, push it, and Fly runs your Docker container on hardware near your users.

The architecture is built around anycast networking with WireGuard meshes between app instances. That sounds like marketing copy, but it has real production implications: routing is fast and the network between your services is private by default.

Where it wins. API services, background workers, any workload where latency to global users matters. If you're running a Go service and you need it deployed across multiple regions, Fly is probably the cleanest option that isn't "roll your own Kubernetes."

Where it struggles. Next.js SSR on Fly requires you to containerise your app properly. Vercel abstracts that away entirely. On Fly, you're writing a Dockerfile, thinking about cache layers, deciding how many machines you want running. The operational overhead is real.

Pricing reality. Fly charges per machine, per CPU, per memory, per outbound data. At small scale it's genuinely cheap a single shared-CPU machine with 256MB RAM costs under $2/month. At production scale with autoscaling enabled, the bill becomes a direct function of your traffic. Set up budget alerts on day one.

Regional Latency Note. Fly does not maintain a physical point of presence inside Jakarta. Their nearest regional clusters route through Singapore and Sydney. For an Indonesian user base that is not catastrophic, but it lacks localized edge density. The round-trip ping from Singapore to Jakarta lands between 20-30ms. While unnoticeable for generic static delivery, it introduces perceptible overhead for high-frequency transactional data streams or real-time web socket communication.

Railway: Vercel-Like Experience with Usage-Based Pricing Surprises

Railway is the closest thing to Vercel's developer experience outside of Vercel. Connect a GitHub repo, Railway detects your stack, and it builds and deploys. No Dockerfiles required for most Node.js and Python stacks. It feels effortless.

That's both the appeal and the problem.

Where it wins. Early-stage products where the team is small, the budget is limited, and the priority is shipping. Railway's free tier is generous. The hobby plan covers a lot of ground for a product still finding product-market fit. If you're running a side project that might become a real business, Railway lets you defer infrastructure decisions while you validate.

Where it struggles. Railway's production pricing is usage-based. You pay separately for CPU time, RAM, network egress, and persistent storage. For a well-optimised stateless API, this is manageable. For a Next.js app with heavy SSR that handles traffic spikes, you can watch the meter run on a good day and feel genuinely anxious about it.

The platform also has less operational flexibility than Fly. Fine-grained control over health check behaviour, connection draining, or graceful shutdown requires workarounds. If you need to handle SIGTERM cleanly, you'll find the guardrails become friction.

The operational gotcha. Railway's internal tracing and telemetry interfaces are structurally shallow. When an active data layer exception drops at 3am, browser-bound interface logs fail to deliver the granular context required for high-velocity diagnostics. Running critical enterprise production workloads here forces you to pipeline your telemetry out to dedicated logging arrays, which immediately introduces the exact administrative complexity you deployed a PaaS to avoid.

Render: The Predictable Middle Option

Render sits between "managed PaaS with guardrails" and "you own this now." It's not as polished as Railway, not as powerful as Fly, and not as cheap as raw VPS at scale. But it's the most predictable of the managed options.

Static sites are free. Web services start at $7/month for a shared instance. Persistent disks exist. Private networking between services works. PostgreSQL is available as a managed add-on.

Where it wins. Teams that need more than Railway offers but aren't ready to manage their own server. The pricing model is flat per service tier rather than variable usage. That makes budgeting straightforward you know the bill before the month ends.

Where it struggles. Cold starts on the free and lower tiers are real. If your service hasn't received a request in a few minutes, the next request wakes it up. For anything user-facing in production you'll need a paid tier to avoid this. Render's build times on large Next.js projects are also slow compared to Railway or Fly.

The performance ceiling on shared instances is another honest limitation. If you need consistent throughput under sustained load, you'll outgrow the smaller tiers quickly and the economics start to look less attractive.

Raw VPS: The Right Answer More Often Than You Think

This is where most comparison posts go wrong. Raw VPS gets positioned as the "advanced option" or "too much overhead for a startup." That framing is misleading.

A standard cloud VPS compute instance providing 2 vCPUs and 4GB of RAM sits at accessible tier baselines internationally. It delivers an un-abstracted Linux runtime with zero provider policy controls.

If your team can write a standard Dockerfile and maintain a predictable docker-compose.yml config file, deploying on a raw virtual server is intensely competitive. This is not advanced architecture it is the industry baseline. You execute a clean runtime engine, lock down incoming access rules via standard firewalls, and provision certificates locally.

Where it wins. Any workload you understand well enough to containerise. At medium scale say, 5 to 50 million requests per month the economics are significantly better than any managed PaaS. You're paying for compute, not for an abstraction layer on top of compute.

Where it struggles. You own the ops. Nobody calls you when the disk fills up. You need monitoring, alerting, and at least one person on the team who can read a df -h output and act on it. If your team has zero infrastructure experience, raw VPS without investment in tooling will cost more in engineer time than it saves in hosting.

For deployments targeting Indonesian users, [→ VPS vs Managed Cloud vs Serverless] covers the regional trade-offs in detail. The deployment of a lean, self-directed cloud instance inside a dedicated local region (like AWS Jakarta) bypasses transit latency bottlenecks while remaining intensely competitive with global generic compute specs.

The Part Most Teams Get Wrong

The most common mistake is choosing based on developer experience at zero scale and being surprised by costs or limitations at real scale.

Railway is easier to start with than Fly. But "easier to start" doesn't mean "right for production." Teams pick Railway for a new service because the first deploy took four minutes, then discover six months later that the observability and operational flexibility don't meet their incident response requirements. Migrating away from Railway under production pressure is not a fun exercise.

The second mistake is treating raw VPS as the sophisticated option and everything managed as the practical choice. If you're spending $200/month on managed platforms and your engineers can containerise an application, do the math on what a comparable VPS setup costs. The number often ends the conversation.

The third mistake is ignoring regional latency when your users are in Southeast Asia. Fly and Railway both have Singapore regions. Confirm where your containers are actually running before you commit. "Global" in a deployment platform's marketing copy usually means "wherever we have capacity," not "near your users."

Real-World Example

A localized B2B SaaS architecture was executing its Next.js interface on managed edge environments while driving its core application API through variable managed tiers. While passing through growth thresholds, their batch transaction engines regularly locked up allocated CPU bounds, creating cascading timeouts across user workflows.

They transitioned the heavy API block to a dedicated flat-rate virtual instance running a containerised environment. The shift was completed within a single developer shifts: packaging the runtime into an explicit image, mapping basic proxies, routing updates via basic pipeline automations, and adding light log endpoints. The background tasks now scale without triggering unpredictable billing surges.

Total platform spend dropped significantly while improving system consistency. The Next.js client engine remained anchored on edge architecture—Vercel continues to deliver optimized asset performance for Next.js rendering paths at this traffic index, making a complete migration counter-productive. Our tactical playbook on [→ When to Move Off Vercel] isolates exactly when that calculation changes.

FAQ

Q: Is Fly.io a realistic option for a Next.js app?

A: Yes, but you'll containerise the app yourself and manage more configuration than Vercel requires. If your Next.js app is relatively simple mostly static output with a few API routes the overhead is manageable. If it's SSR-heavy with edge middleware or image optimisation, the work to replicate what Vercel handles automatically increases substantially.

Q: How does Railway compare to Render at $50/month in spending?

A: Render gives you more predictable spending at that level. Railway's usage-based model can cost less for low-traffic services and more for high-traffic ones within the same month. Teams that can't monitor billing weekly tend to prefer Render's flat-rate model. Teams that can optimise for low CPU usage often find Railway cheaper.

Q: Can I run a managed PostgreSQL database on Fly.io?

A: Fly has a Postgres offering built on their machine infrastructure. It's not a fully managed service in the RDS sense you're responsible for backup configuration and recovery procedures. Their documentation is explicit about this. For production workloads with real data loss consequences, treat it as "self-managed Postgres on reliable hardware" and set up automated backups accordingly.

Q: What's the minimum viable monitoring setup for a raw VPS?

A: Docker for your app, Nginx as a reverse proxy, Certbot for SSL, and an uptime monitor. Uptime Kuma runs on Docker and gives you basic alerting for under 256MB RAM. For logs and metrics, Grafana Cloud's free tier handles 50GB of logs per month enough for most early-stage products. Add a disk usage alert before you need it, not after.

Q: Is there a meaningful latency difference between Fly's Singapore region and AWS Jakarta for Indonesian users?

A: Around 20-30ms round-trip difference. For most web applications this is below the threshold that users notice. For real-time features collaborative editing, live chat, anything that requires sub-100ms response Jakarta gives you a meaningful edge. If your product doesn't have real-time requirements, Singapore is a reasonable choice and saves you the operational complexity of a Jakarta-only deployment.

If you're spending more than $100/month on Vercel or Railway and haven't done the math on what a comparable VPS setup would cost, that calculation is worth thirty minutes before your next billing cycle. The numbers often end the conversation faster than any comparison article does.

We help startups work through these infrastructure decisions without the trial and error whether that's auditing your current hosting spend or designing the architecture that holds up over the next 18 months of growth.