Leaving Heroku in 2026: Where Your App Actually Belongs

Des Conlon — Tue, 28 Jul 2026 16:08:02 +0000

I work at Railway, so take everything here with that in mind. But I've spent the last year talking to teams migrating off Heroku, and the pattern is consistent enough that it's worth writing down. Not a feature matrix. Not a pricing calculator. Just an honest read on where five platforms actually deliver and where they don't.

Heroku invented this category. That matters. But "invented" and "still the best option" are different statements, and the gap between them has been widening for a while.

Why people actually leave

The reasons teams give for leaving Heroku fall into a few buckets, and they're rarely about one thing.

The bill. Heroku's pricing made sense when the alternative was hiring someone to manage EC2 instances. In 2026, platforms that run on their own hardware or use usage-based billing have fundamentally different cost structures. A production app on Heroku costs more than the same app on most alternatives, and the gap grows with scale.

The missing pieces. No persistent storage via volumes. No native multi-region. No shared environment variables across apps. No built-in health checks for zero-downtime deploys. Private networking locked behind enterprise pricing. Each of these is solvable with workarounds, but workarounds compound. After three or four of them, you're maintaining a platform on top of a platform.

The architecture. Every app on Heroku is an island. There's no project-level grouping, no way to see your API server and your worker and your database as parts of the same system. If your app has grown past a single process, this gets painful fast.

The trajectory. Salesforce moved Heroku into sustaining mode. The platform still works. The roadmap has gone quiet. "Still works" is a fine answer for something running in production today. It's a harder answer for something you're about to build.

The platforms, honestly

Railway

This is where I work, so I'll lead with the caveats. Multi-region is supported for stateless services but not for database writes across regions. The enterprise compliance story is newer than what Heroku or the hyperscalers carry. If your procurement team needs SOC 2 Type II with a specific scope, verify the current attestation list before you start that conversation.

What Railway gets right for most teams: your API, your workers, your cron jobs, and your databases live in the same project on a shared private network. One canvas, one invoice. Postgres, MySQL, Redis, MongoDB, ClickHouse, and a dozen other storage engines deploy in one click. Environments are first-class, so staging, production, and PR previews each carry their own variables and their own database instances without manual wiring.

Pricing is usage-based. You pay for active compute time multiplied by resource size. Idle apps cost nearly nothing. Traffic spikes show up on the invoice, which is the honest trade-off of usage-based billing. Set spend caps.

The platform runs on hardware Railway owns and operates. That matters for cost structure. When your PaaS runs on AWS, AWS's margins are baked into your bill. When the PaaS owns the metal, those margins disappear.

Vertical scaling is automatic. No threshold configuration, no manual instance upgrades. Horizontal scaling works by deploying replicas, which can be placed in different regions with automatic routing to the nearest one. If you want to save money on low-traffic services, app sleeping suspends a service after ten minutes of inactivity and wakes it on the next request.

Render

Render is the platform people pick when they want Heroku's model with the rough edges sanded down. Multi-service projects, managed Postgres, background workers, cron jobs, internal networking. It covers the standard checklist without drama.

The pricing model is instance-based, like Heroku. You pick a size, you pay a fixed monthly rate. No metered surprises, but also no scaling to zero. If your app is idle at 3 AM, you're paying the same rate as peak hours. Each team member you invite adds a per-seat fee regardless of whether they deploy anything.

Render runs on AWS and GCP, so the infrastructure cost structure mirrors Heroku's. The margins of the underlying cloud provider are in your bill.

The meaningful limitation for growing apps: no native multi-region support. Each service is pinned to one region. If you need global distribution, you're provisioning separate instances and wiring up an external load balancer yourself. Render's opinions work in your favor until your app outgrows one of them, and backend-heavy apps find those walls sooner than static sites do.

Persistent storage via volumes is supported. Shared environment variables work through environment groups. Health checks and instant rollbacks are built in.

Fly.io

Fly is solving a different problem than the other platforms on this list. If your app needs to run in twelve regions with read replicas placed at the edge and you have latency benchmarks that justify the operational complexity, Fly is the serious answer.

The deployment model uses lightweight VMs (Fly Machines) on hardware Fly owns. You configure CPU and memory per machine and choose between shared CPUs (cheaper, subject to throttling) and performance CPUs (dedicated, no throttling). Multi-region is native and well-executed.

The trade-off is operational surface. The mental model sits closer to VM orchestration than application deployment. Scaling options include manual machine management, autostop/autostart pools, and a metrics-based autoscaler you deploy yourself. There's no built-in CI/CD. No native preview environments. No instant rollbacks. Environment isolation requires creating separate organizations. You'll integrate GitHub Actions or equivalent for the workflow pieces other platforms include.

Pricing is per-machine, per-second. Transparent once you internalize it, but the model rewards teams who understand their resource consumption patterns. Stopped machines still incur storage charges.

The concern that keeps coming up in conversations: uptime. A fleet-wide orchestration failure in late 2024 set the tone, and the incident cadence since has kept reliability as a discussion point. Review their public status history before committing production traffic.

Fly has persistent storage via volumes and built-in monitoring through a managed Prometheus stack. Alerting and custom dashboards require additional tooling. No webhook support.

Vercel

Vercel is not a Heroku alternative. It's a frontend deployment platform that has added backend capabilities, and being clear about that distinction saves everyone time.

If your product is a Next.js app where the frontend is the core of the experience and the backend is a handful of API routes, Vercel is excellent at that job. The deployment experience, preview environments, and edge network are best-in-class for that use case.

The serverless model imposes hard constraints that matter for backend workloads. Functions max out at 4 GB of memory and 800 seconds of execution time. Cold starts are a real factor. There's no persistent storage, no long-running processes, no message queues, no internal service routing between backend components.

Anything that requires persistent connections (chat, live dashboards, WebSocket-heavy features) or long-running jobs (video processing, large data imports, report generation) won't work in Vercel's function model. These aren't edge cases. They're the standard requirements of most backend systems.

Pricing is usage-based, which is good. But Vercel runs on AWS, so the cost structure reflects that. The Vercel marketplace integrates external services for databases and caching, but managing those services still means switching between dashboards.

The honest recommendation: ship your frontend on Vercel, ship your backend on a platform built for backends.

DigitalOcean App Platform

DigitalOcean App Platform is the budget pick. Push from git, attach a managed database, deploy on fixed-price instances. It does the basics without charging a premium for them.

The platform supports multi-service projects, Docker and source code deployment, instant rollbacks, SSH access, and shared variables between services through bindable variables. Health checks are built in.

The limitations are real. No persistent storage via volumes. No native multi-region. No preview environments. No concept of environments for dev/staging/production workflows. You create separate projects for each, which is the same workaround you'd use on Heroku. No webhook support.

Scaling follows the same instance-based model as Heroku and Render. Vertical scaling is manual. Horizontal autoscaling requires threshold configuration. DigitalOcean owns its hardware, so pricing is competitive, but the developer experience lags the rest of this list.

The pattern I hear: teams pick DigitalOcean for the price, then move when the first production incident reveals the tooling gap. It works for small, steady-state apps on a tight budget. It stops working when the app stops being small or steady.

What actually matters when you're choosing

Skip the feature matrices. Here's what determines whether a platform works for your team in practice.

Does pricing match your traffic pattern? If your app has variable load, usage-based pricing (Railway, Vercel) means you're not paying for idle capacity. If your load is flat and predictable, instance-based pricing (Render, DigitalOcean) gives you a number you can budget against. Fly's per-machine billing rewards teams who actively manage their fleet.

Can your whole app live in one place? If your app is an API server, a worker, a database, and a cron job, you want a platform where those are part of the same project with shared networking and shared configuration. Railway, Render, and DigitalOcean support this natively. On Heroku, Vercel, and Fly, each component is a separate entity you wire together yourself.

Do you need multi-region? Railway and Fly support it natively. Vercel's serverless functions deploy globally by default. Everyone else requires manual setup with external load balancers. Most apps don't need multi-region. If yours does, the list gets short.

Do you need persistent storage? Railway, Render, and Fly support volumes. Heroku, Vercel, and DigitalOcean don't. If your app writes data to disk that needs to survive a deploy, this is a hard filter.

How much operational surface do you want? Railway and Render minimize it. Fly exposes more control but expects more from you. Vercel abstracts it away entirely but constrains what you can run. DigitalOcean sits in the middle.

If you're migrating from Heroku

Railway is the shortest path. The concepts map directly: services instead of dynos, projects instead of apps, environments instead of pipelines. The workflow is similar enough that the migration is mostly mechanical.

Create an account, connect your GitHub repo, add your environment variables (you can paste in a .env file), configure a domain. Your app is running. The pricing model and the feature set are different enough to justify the move. The workflow is familiar enough that the move isn't painful.

If Railway's constraints don't fit (you need multi-region database writes, or your compliance requirements exceed current attestations), Render is the next closest in developer experience, and Fly is the answer if multi-region latency is the driving requirement.

Whatever you pick, pick something. Staying on a platform in sustaining mode is a form of technical debt that compounds quietly. The migration gets harder the longer you wait, and it never gets easier.

DEV Community: Des Conlon