Render vs Railway vs Fly.io: Brazilian comparison 2026

In August 2022 Salesforce announced the end of Heroku's free plan. The decision was written in two lines on a corporate blog post, became a meme in three hours, and within three months was rewriting the hosted PaaS map for every indie dev in the world. Brazilians took the hit twice: lost the free tier and also saw the dollar rise from R$5.20 to R$5.90 in the same period.

Three products picked up most of the inheritance: Render, Railway, and Fly.io. Each bets on a different philosophy — predictable fixed pricing, pay-as-you-go with pretty UI, or multi-region edge with low-level primitives. For Brazilian devs, the choice mixes DX, cost in USD that becomes reais, latency to São Paulo, and the scale ceiling before the project starts to hurt the wallet.

This article is the honest map. No "best" ranking, because there isn't one — there's the best for each stage. And at the end of the line, when the three become expensive, there's the self-hosted path, which is where HeroCtl comes in. But let's go in parts.

The Heroku inheritance

To understand what each one copied and what each one discarded, it's worth remembering what Heroku did well in its ten glory years.

The first thing was git push heroku main. That command became the mental deploy standard for an entire generation of devs. There was no pipeline to configure, no image registry to populate, no orchestration file to write. You pushed code to the remote repository and the platform took care of the rest — buildpack detected the language, installed dependencies, started the process. Render and Railway inherited this almost intact. Fly.io swapped it for fly deploy, which has the same face but works with explicit container image.

The second thing was the notion of "dyno" as a billing and scaling unit. You didn't think in terms of server, vCPU, or RAM — you thought in terms of how many web processes and how many workers. Render kept that simplification on the Starter plan. Railway abandoned it and charges by real consumed resource. Fly.io swapped dyno for VM with declared size.

The third thing was the addons marketplace: Postgres, Redis, MongoDB, transactional email, all one click away. That's the piece where the three successors diverge most. Render has some native managed addons. Railway has a template marketplace covering the basics. Fly.io pushes you to run your own Postgres in a dedicated app, with all the responsibility that brings.

And the fourth thing, the painful one, was vendor lock-in disguised as simplicity. Whoever had fifty services on Heroku discovered in 2022 that migrating would cost months. The three successors promise to be better in this regard; we'll see.

Render: the "predictable Heroku 2.0"

Render is the most conservative successor. The premise is simple: you describe the service in a render.yaml file or via the panel, connect the repository, and each push to main triggers a deploy. Build, TLS certificate, custom domain, all automatic.

Philosophy. Fixed prices per instance. The cheapest Starter instance costs US$7/month — and costs US$7/month whether you make five requests per day or fifty thousand. There's a free plan, but with a big asterisk: the service sleeps after fifteen minutes without traffic and takes about thirty seconds to wake up on the first request. It's exactly the same tradeoff as 2015 Heroku free. Works for portfolio, doesn't work for serious product.

Strong points. Budget predictability is the great appeal for small teams. You know that three Starter services will cost US$21/month, period. There's no end-of-month surprise because a cron ran in a loop. Managed Postgres and Redis exist as own products, with automatic backup and recent version. The panel is clean, focuses on doing few things well. Latency to São Paulo from Ohio data center stays around 120ms — not ideal, but viable for typical web app where the bottleneck is usually the database query.

Weak points. The sleeping free tier is sad for anything that isn't a personal showcase. Scaling is expensive because it's linear: four Starter instances cost four times US$7. There's no native multi-region on the basic plan — you're stuck with the region you chose. CDN and edge computing are limited; whoever needs heavy geographic cache will suffer. And managed Postgres starts at US$7/month, so the real floor of an app with database is US$14/month, which for MVP at zero revenue stage already bothers.

Cost in reais. Simple app without database: US$7/month = R$36 to R$40 depending on exchange rate. With minimum Postgres: US$14/month = R$72 to R$80. Production version with two web instances and Standard Postgres (US$20/month): US$34/month = R$170 to R$190. Add domain, transactional email, monitoring and you're at R$300/month easy for a small SaaS. It's not expensive by American standards. It's expensive by Brazilian standards of those who pull salary from their own MRR.

When it makes sense. Indie hacker already on Heroku and wants to migrate with minimal mental friction. Team of one to three people that values predictable budget more than absolute minimum cost. Traditional web app without low geographic latency requirements. Project where you'd rather pay US$30/month and not think about it more than pay US$10/month with possibility of exploding to US$80 in a bad month.

Railway: the "pay-as-you-go with premium UX"

Railway is the successor that dared to invert the billing model. Instead of fixed instance, you pay for actual consumed resource — vCPU, RAM, network egress, storage. The premise is that small apps and intermittent jobs come out cheaper on pay-as-you-go than on instance-based.

Philosophy. Granular billing by real usage. You don't choose machine size, you choose the app and Railway decides how much resource to deliver as demand goes, within a ceiling. Excellent UI — probably the prettiest in the hosted PaaS segment. One-click templates cover dozens of combinations: Postgres, Redis, MongoDB, MeiliSearch, n8n, Strapi.

Strong points. UX wins on first contact. In fifteen minutes you have an app running with database, Redis, and real-time logs dashboard. The template marketplace is friendly for those who don't want to write Dockerfile. For low-traffic apps pay-as-you-go can come out much cheaper than Render's fixed instance — a cron that runs ten seconds a day pays only those ten seconds, not twenty-four hours.

Weak points. Unpredictable cost is the Achilles heel. Railway has a soft spending ceiling, but not a hard one by default — a job in infinite loop can burn US$50 over a weekend before you notice. The pricing has fine print: the Hobby plan (US$5/month) includes US$5 of usage, so technically you start from zero every month, but the bill can pass that easily. The original free plan was removed in 2023 — another repetition of the Heroku pattern. Datacenter is US-only, latency to SP stays at the same 120ms as Render. And there was history of pricing changes that caught users by surprise, like the removal of the more generous trial in mid-2023.

Cost in reais. Hobby plan: US$5/month fixed = R$25 to R$28. But real usage usually pulls the bill to US$10-20/month on an app with database and light workers = R$50 to R$110. In a bad month, with traffic spike, it's easy to see the bill near US$30-40 = R$150 to R$220. The second standard deviation is what scares.

When it makes sense. Small team in experimentation phase, launching dozens of tests per week, where most never get traffic and would be wasteful to pay fixed instance. Genuinely small low-traffic apps where pay-per-use comes out cheaper in the long run. Devs who value pretty UI and frictionless deploy flow above rigid budget predictability. Personal projects that run in bursts.

Fly.io: the "edge multi-region for serious workloads"

Fly.io is the most technical of the three. The premise is different from the base: your app doesn't run in one region, it runs in several. When a user in Brazil accesses, the request hits the nearest region — and Fly.io has a point in São Paulo, GRU. For perceived latency by the Brazilian user, that's the most important thing in the PaaS market today.

Philosophy. Global application by default. Real VMs (not shared containers) on top of Firecracker. Low-level primitives — you deal with fly.toml, with regional persistent volumes, with private network between apps via WireGuard, with anycast IPs. More power, more responsibility.

Strong points. GRU datacenter is real and measurable advantage: latency to user in São Paulo drops from 120ms (Render/Railway via US) to 30-60ms. For interactive app, that's the difference between "fast" and "instant". Multi-region is native — you run the same binary on three continents, and routing hits the region closest to the user. Regional persistent volumes allow patterns like Postgres with Litestream replicating to object storage. Pricing starts very cheap: US$1.94/month for the smallest VM (shared-cpu-1x, 256MB), plus fractions of a cent per GB transferred.

Weak points. Real learning curve. flyctl, fly.toml, Machines vs Apps concepts, WireGuard networks — all of that you have to digest. It's not "open panel and click deploy", it's "read the docs for an afternoon". Variable pricing like Railway, with the same trap: app that suddenly grows can triple the cost in a month. Community is smaller than Render/Railway, especially in PT-BR — finding recent Brazilian tutorial is task. And there were publicly reported stability incidents in 2023-2024 that affected base confidence; they improved, but the memory still weighs.

Cost in reais. Small app with minimum VM and modest storage: US$2-6/month = R$10 to R$32. Postgres run as dedicated app (you're responsible for backup): plus US$2-10/month = R$10 to R$50. Serious production app with two regions and real bandwidth: US$15-40/month = R$80 to R$220. The low band is unbeatable for personal project; the high band starts competing with self-hosted on dedicated VPS.

When it makes sense. B2B SaaS with customers distributed across multiple regions — app that needs to be in US-East and in GRU simultaneously without you operating two clusters. App where latency to Brazilian user is competitive differentiator. Team comfortable with primitives like VM, mesh network, regional block storage — typically devs with DevOps background or those who migrated from bare-metal. Personal hobby project where the US$2/month pays for five apps at once.

Comparison table

The table hides nuance worth making explicit: none of the three is "best" at everything. Render wins on predictability. Railway wins on UX. Fly.io wins on performance for Brazilian user. The choice is a function of what you're optimizing.

What the three have in common (and where HeroCtl comes in)

Four points the three share, and each one is a reason to eventually leave.

First: billing in USD. None of the three bills in reais. Exchange rate goes up, your bill goes up with it, and you discover in February that the infra that cost R$300 in January costs R$340 with no technical change. For bootstrapped team without exchange rate protection, that's exposure no one asked to have.

Second: you don't control the server. You don't choose the kernel, you don't have SSH access, you don't run background process beyond what the platform allows. For ninety percent of cases that's an advantage. For the remaining ten percent — when you need fine-tuning, custom daemon, some specific OS capability — you're limited.

Third: free tiers shrinking year after year. Heroku killed free in 2022. Railway removed the generous trial in 2023. Render keeps free with sleep but has reduced limits. The pattern is clear: free tier serves to acquire dev at zero revenue stage; when the product grows, the company needs to monetize and free shrinks. It's not betrayal, it's economics. But it implies your long-term strategy can't depend on free continuing as it is.

Fourth and most important: when the startup grows, cost scales disproportionately. Small US$15/month app is negligible. Real app with five services, two databases, Redis, and two environments (staging + prod) starts at US$80-150/month — between R$450 and R$850. Add workers, background jobs, monitoring, and you pass US$200/month easily. That's the point where self-hosted stops being DevOps hobby and becomes clear savings.

The typical band where the tradeoff turns: when your hosted PaaS passes US$50/month of consistent spending, three Hetzner VPSes of US$5 each (~R$80 total) running an orchestration platform start to make financial sense. You trade convenience for savings, and you gain server control as a bonus. HeroCtl is designed for that range: simple installation, real high availability between multiple servers, automatic certificates, web panel. No operational ceremony, no SRE team.

Decision by project stage

The right question isn't "what's the best PaaS", it's "what's the best for the stage I'm at now".

Hobby stage, zero revenue. Render free tier (with sleep), or Fly.io taking advantage of the minimum tier (US$2-3/month covers personal project), or a US$5/month VPS with Coolify running solo if you enjoy tinkering. Railway lost spot here after removing the original free tier.

Indie hacker stage, up to US$5k MRR. Render if you prioritize predictable budget and the app has a "instance running 24/7 with constant traffic" profile. Railway if you're experimenting a lot, want pretty UI, and pay-as-you-go will favor you. Cost in this band stays at US$15-50/month, manageable.

Early startup stage, US$5k to US$50k MRR. Time to evaluate seriously. If latency to Brazilian user matters (B2C, interactive app), Fly.io becomes a strong candidate because of GRU. If the team already has a dev comfortable with basic infra, simple self-hosted (Coolify on a server, or HeroCtl on three for high availability) starts to pay. The bill in this band on hosted PaaS runs US$80-300/month — on self-hosted, R$150-400/month with more headroom.

Startup stage with first serious B2B customer, SLA required. Here hosted PaaS starts breaking in other ways: you need contractual SLA, redundancy across multiple servers, predictable maintenance window, audit logs. Render and Railway don't offer strong SLA on standard plan. Fly.io offers, but multi-region implies operational complexity the team will have to learn anyway. That's the point where HeroCtl with three-server cluster comes in as alternative: real high availability, admin panel, audit, without the US$300+ monthly of hosted PaaS for the same level of robustness. The other option is the opposite path: managed AWS if some customer pulls specific compliance requirements.

When NOT to leave Render, Railway, or Fly.io

Migration costs expensive, and most of the time it's premature optimization. Four clear situations to stay where you are.

Team of one or two people without any time for operational stuff. If you're a solo founder on the product and every hour spent on infra is an hour not spent on sales, keeping the PaaS is the right decision. R$200/month of hosted is cheaper than seventeen hours of yours in the month tinkering with server.

Platform cost is negligible compared to revenue. Simple rule: if infra is less than two percent of MRR, don't optimize. SaaS with US$50k MRR spending US$500/month on hosted is paying one percent on infra. It's excellent. Tinkering there is micro-optimizing to save coins.

You use proprietary addon without easy substitute. If you depend on some specific Railway addon that has no obvious equivalent outside — some custom template with proprietary integration, some unique feature — migration isn't just re-deploy, it's re-architecture. Evaluate total cost before.

Migration would take more than two weeks and the company can't stop for it. There are moments when the product is in hyper-growth, or in critical funding cycle, or simply in feature sprint that matters to the customer. Don't migrate infra in those windows. Note the technical debt and come back later.

FAQ

Can I use Render for production and Railway for staging? You can, and people do. The justification is simple: production demands predictability (Render shines there), staging has bursty traffic and ideally should cost little when no one is using (Railway pay-as-you-go wins). The cost of maintaining two vendors is the mental overhead of two dashboards and two sets of credentials. Makes sense for disciplined team, hampers small team that prefers monoculture.

Is Fly.io GRU region reliable? Today yes, with asterisk. Works well since 2023, measured latency to SP/RJ is what it promises (30-60ms typically). The asterisk is that GRU is a smaller region in Fly's portfolio, so capacity can get tight on peaks and new features usually arrive in US-East first. For serious production, worth running in at least two regions (GRU + a US) with failover.

How do I migrate from Render to HeroCtl without downtime? Pragmatic roadmap: provision three VPS, install HeroCtl, bring up the application in parallel pointing to a temporary domain. Replicate the database with pg_dump + initial load, then keep in sync with logical replication until switchover. When ready, change the DNS of the main domain to the new cluster with low TTL. The risk window stays around the DNS TTL — typically five to ten minutes. Small databases (up to a few GB) migrate in an afternoon; large databases ask for a coordinated window.

Is managed Postgres on these three good? Render Postgres is decent, with automatic backup and updated version — equivalent to classic Heroku Postgres. Railway Postgres via template works, but the backup is more manual and the default configuration is conservative. Fly.io doesn't have its own managed Postgres; you run as app, which gives control and responsibility. For a team that doesn't want to take care of database, Render takes this category. For a team that prefers control, Fly.io.

Which of these has support in Portuguese? None officially. Documentation is all in English, support via chat/email is in English. There are unofficial PT-BR communities on Discord and Twitter for each, but most serious tickets you open in English. For a team uncomfortable with that, it's a variable that weighs.

And performance for Rails / Django / Node app? For the three frameworks the three PaaSes work well. Render has mature Rails buildpack and runs Sidekiq easily. Railway detects Django and Node automatically via templates. Fly.io has specific documentation for Rails and Phoenix, with official deploy guides. The practical difference appears in details: Rails with heavy asset pipeline gets faster on Render because of predictable build cache; Node with background workers wins on Railway via pay-as-you-go; any framework wins on Fly.io if the user is in Brazil because of GRU.

Do preview deploys per PR work on the three? Yes on the three, with nuances. Render has the best: each PR becomes a temporary URL automatically, no extra configuration. Railway offers via repository integration, simple configuration. Fly.io does via CLI (fly deploy --config preview.toml) and requires a bit more manual setup or a custom CI workflow. For team prioritizing preview deploys as part of code review, Render is the most fluid.

Closing

The choice between Render, Railway, and Fly.io has no universal answer. Render is the predictable conservative. Railway is the experimenter with pretty UI. Fly.io is the technical with real latency advantage for Brazil. The three are honest about what they are, and the three have the same structural destiny: from a certain growth point, cost in USD scales faster than your revenue in reais, and self-hosted starts to make sense.

When that point arrives, consider HeroCtl. Three Linux servers, real high availability between them, automatic certificates, built-in web panel, no operational ceremony. Community plan free forever, Business and Enterprise plans for when the team needs SSO, audit, and SLA support. No retroactive contract changes.

To get started:

curl -sSL get.heroctl.com/install.sh | sh

If you want to read first, two complementary posts: Self-hosted Heroku in 2026 covers the general thesis of when to leave hosted PaaS, and Brazilian alternatives to Kubernetes gets into which orchestrator makes sense for small team outside the three PaaSes of this article.

The good choice is the one that fits your stage now, not the one that seems sophisticated. Start simple, migrate when cost justifies, and never before.