For more than a decade Heroku set the standard for Git-push deployments. In 2026, that standard is being rewritten. With Salesforce moving Heroku into a more limited maintenance posture and pricing pressure forcing teams to re-do the math, what should we use instead of Heroku?
has gone from a curiosity question to a quarterly planning item.
This is a positioning piece, not a takedown. Render, Railway, Fly.io and a self-managed VPS paired with a Git deployment automation tool all solve different versions of the same problem. The right answer depends on whether you want zero-ops convenience, global edge presence, or the lowest total cost of ownership with full control.
Why teams are leaving Heroku in 2026
Three pressures are pushing teams off the platform at the same time:
- Sustaining engineering posture. Heroku is no longer the focus of major roadmap investment from Salesforce. We covered the implications in detail in our breakdown of what Heroku's sustaining engineering mode means for production teams. The short version: existing dynos still run, but if you were waiting for new runtimes, faster builds, or modern observability, the wait is effectively over.
- Pricing. The end of free dynos in 2022 set the trend; subsequent professional-tier increases have pushed even small production apps past $50/month for what used to cost $7. Add Heroku Postgres, Heroku Redis, and a couple of paid add-ons and a hobby project quickly costs more than a $20 VPS that could run the whole stack.
- Dyno limitations. 30-second request timeout, ephemeral filesystem, no native long-running workers without separate dynos, slug size caps. Workable, but every constraint is a tax on architecture decisions you would otherwise not have to make.
Combine the three and the question stops being should we leave?
and becomes where do we go?
The four categories of Heroku alternative
Most of the noise in the Heroku alternative
space collapses into four distinct shapes. Pick the shape first, then the vendor.
1. Render — the closest Heroku-shape PaaS
Render is the most direct philosophical successor to Heroku. Connect a Git repo, pick a runtime, get a URL. Buildpacks-style autodetection, managed Postgres and Redis, background workers, cron jobs and preview environments are all first-class.
If your team's deployment muscle memory is git push heroku main,
Render is the lowest-friction destination. The tradeoff is the same as Heroku's: you pay a premium for the operational simplicity, and you accept the platform's opinions about how apps should be shaped.
2. Railway — modern PaaS with a developer-friendly UI
Railway took the Heroku idea and rebuilt it around a polished UI, a usage-based pricing model, and an aggressive focus on developer experience. Database provisioning is fast, environments are easy to fork, and the dashboard surfaces the things you actually need (logs, metrics, build status) without burying them.
It tends to appeal to indie devs and small teams who want PaaS convenience but find Heroku's interface dated and Render's pricing rigid. Caveat: usage-based billing is great when traffic is low and predictable; it is less great when something runs hot at 3 AM.
3. Fly.io — global edge VMs, Docker-shaped
Fly.io takes a different posture. Apps run as Firecracker microVMs that can be deployed to dozens of regions worldwide with a single command. The mental model is closer to tiny VMs at the edge
than PaaS
— you ship a Dockerfile, you scale by launching more machines, you handle volumes and networking explicitly.
Fly is the right call when latency matters: globally distributed users, real-time apps, edge compute, gaming. It asks more of you operationally than Render or Railway, but rewards you with capabilities those platforms cannot match.
4. DeployHQ + your own VPS — control, lowest TCO, and you own the box
The fourth path is the one most Heroku alternatives
listicles skip: rent a Linux server (Hetzner, DigitalOcean, OVH, Vultr) and use an automated deployment tool to ship code to it from Git. You get the entire box, you choose the runtime, and your bill is the VPS plus the deployment service.
This is where DeployHQ fits. It is not a PaaS — it is a Git-to-server deployment automation layer. You point it at GitHub, GitLab, Bitbucket or your own Git host, define a build pipeline, and every push deploys atomically to one or many servers with zero downtime deployments and one-click rollbacks. For teams that already understand Linux and want Heroku's deployment workflow without Heroku's pricing or constraints, the math is hard to argue with.
Side-by-side comparison
Pricing on hosted PaaS platforms changes frequently. Verify against the current vendor pricing pages before making a procurement decision — the numbers below reflect publicly available pricing as of mid-2026 and should be treated as directional, not definitive.
| Capability | Render | Railway | Fly.io | DeployHQ + VPS |
|---|---|---|---|---|
| Entry tier (per month) | Free static / ~$7 web service | $5 hobby + usage | Free allowance, then per-resource usage | DeployHQ from $10 + VPS from ~$5 |
| Build minutes | Generous on paid tiers; check current limits | Included in usage allowance | Builds run remotely; metered as compute | Unlimited builds on DeployHQ paid plans |
| Custom domains | Yes, free TLS | Yes, free TLS | Yes, free TLS via Let's Encrypt | Yes — terminated on your VPS, free via Let's Encrypt or Caddy |
| Postgres included | Managed Postgres add-on | Managed Postgres provisioned in-platform | Managed Postgres available, or self-host on a Fly volume | Self-host (full control) or use a managed Postgres provider |
| Background jobs / workers | Yes, separate worker service | Yes, multi-service projects | Yes, additional machines | Yes — systemd, supervisor, or whatever your stack uses |
| Deploy method | Git push, autodetected runtime | Git push, autodetected runtime | flyctl deploy (Dockerfile) |
Git push triggers DeployHQ build + atomic SSH deploy |
| Lock-in score (1=low, 5=high) | 3 — buildpacks + managed services | 3 — usage model + Railway primitives | 2 — standard Docker, but volumes and networking are Fly-specific | 1 — your VPS, your code, your runtime; portable by definition |
Two columns deserve a footnote. Build minutes on the PaaS platforms are usually generous enough that they are invisible until you trip a limit during a busy release week. Lock-in score is qualitative — it reflects how much of your stack would have to change if you migrated away. Self-hosting on a VPS is the only category where the answer is essentially nothing.
Migration friction: what actually changes
Leaving Heroku is rarely swap a YAML file.
The real work lives in five places:
- Buildpacks → Dockerfile (or equivalent). Heroku's autodetected buildpacks are convenient until you leave. Render and Railway support similar autodetection; Fly expects a Dockerfile; a VPS expects whatever your team writes. Plan to author a clean, reproducible build step you actually own.
- Add-ons → managed or self-hosted services. Heroku Postgres becomes a managed Postgres elsewhere, a self-hosted Postgres on your VPS, or a third-party managed DB. Heroku Redis, Papertrail, Scheduler — each gets a deliberate replacement.
- Environment variables. Easy to move, easy to forget. Audit which ones are secrets versus configuration, and use the new platform's secret store for the former.
- Scheduler / cron. Heroku Scheduler becomes Render Cron Jobs, Railway cron, a Fly machine, or plain
cron/ systemd timers on a VPS. Each has its own gotchas around timezone and missed runs. - Log routing. No more
heroku logs --tail. Decide early whether you stream logs to a hosted service (Logtail, Datadog, Better Stack), to your VPS journald, or both.
None of these are hard individually. Together they account for most of the calendar time on a migration.
When to pick each
- If you want zero-ops and a Heroku-shaped workflow: pick Render (closest replacement) or Railway (if developer experience and a modern UI matter more than pricing predictability).
- If you want global edge presence and per-region scaling: pick Fly.io. No other option in this category puts your app in 30 regions with one command.
- If you want the lowest total cost of ownership and full control: pick DeployHQ + a VPS. You trade some convenience for ownership of the runtime, the data, the network, and the bill. Teams comfortable with Linux usually find the tradeoff compelling once monthly spend crosses the $50–$100 threshold on a managed PaaS.
- If you want repeatable, audited deployments without changing your hosting strategy: DeployHQ also fits in front of Render, Railway, or any SSH-accessible target. It is the layer that turns
git push and pray
into a build pipeline with logs, approvals, and rollbacks. For a fuller comparison of how this differs from a generic CI runner, see our breakdown of DeployHQ vs traditional CI/CD pipelines and the head-to-head with Buddy as a deployment tool.
The honest tradeoff: what you give up by leaving Heroku
Migration posts tend to skip this part. Heroku, even in sustaining mode, still does several things genuinely well:
- Operational simplicity at small scale. A single dyno with a Postgres add-on requires zero infrastructure literacy. Replacing that on a VPS means owning OS patches, backups, monitoring, and TLS renewal — all solvable, none free.
- A mature add-on marketplace. A decade of integrations means there is a Heroku add-on for nearly anything. On other platforms you assemble equivalents yourself.
- Predictable behavior. Dynos restart cleanly, releases are atomic, the platform's edges are well-documented. Self-hosting introduces variance you have to engineer away.
If your team has no operational appetite, a managed PaaS — Heroku, Render, or Railway — will remain the right answer regardless of price. Be honest about which side of that line you sit on. For broader context on how deployment tooling has evolved, our overview of the best software deployment tools in 2026 covers the full landscape, and the foundational guide to what software deployment actually means is worth a read for anyone newer to the space.
A high-level migration playbook
A workable path off Heroku, regardless of destination:
- Inventory. List every dyno, add-on, scheduled task, env var, and external integration. This list is the migration scope.
- Pick the shape. PaaS replacement (Render/Railway), edge VMs (Fly), or VPS + DeployHQ. Don't conflate the choice with the vendor.
- Reproduce the build. Containerise or buildpack-equivalent. Get a clean local build green before touching the destination.
- Stand up parallel infra. Deploy to the new target with production-equivalent data (sanitised) and run smoke tests.
- Cut over DNS with low TTL. Pre-lower TTL on the Heroku domain a day in advance. Cutover is then minutes, not hours.
- Decommission deliberately. Keep Heroku running for at least one billing cycle in case of regressions. Then tear down.
For teams choosing the VPS path, the deployment side is the easy part once DeployHQ is wired in: a build pipeline, a deploy target, a Git push. The interesting work is the inventory and the cutover, not the deploy mechanics.
Closing thoughts
Heroku taught a generation of developers what good deployment ergonomics feel like. The good news in 2026 is that the standard it set is now the floor, not the ceiling — Render and Railway match the workflow, Fly extends it geographically, and the VPS-plus-deployment-tool combination undercuts all of them on price for teams willing to own a server.
If the cost and control story resonates and you want Heroku-style git-push deploys to a VPS you own — with build pipelines, atomic releases, and rollbacks — start a DeployHQ trial or browse the pricing tiers. Teams running deploys from a terminal or coding agent can also wire DeployHQ into the deployment agent workflow.
Questions, corrections, or migration war stories? Email us at support@deployhq.com or find us on X / Twitter @deployhq.