Leaving Heroku: Which Alternatives Need the Least Re-Architecture?

Key Points:

• For a standard 12-factor web-plus-worker app, Render and Railway need the least re-architecture (a move measured in days, and both publish Heroku migration guides). Fly.io is next (days to weeks, because you adopt its Machines and private-networking model). Qovery needs a short setup and then matches the Heroku workflow while running in your own cloud account, which makes it the least-regret choice when cost, scale, compliance, data residency, or unused cloud credits are why you are leaving. Vercel, Neon, and Upstash each replace one layer and are not Heroku replacements.
• Only four things drive re-architecture effort: how your app builds (buildpack vs Dockerfile), your add-ons (Postgres, Redis, Kafka), your background workers and cron jobs, and your Review Apps workflow. Inventory those four before you shortlist anything. The app code itself is rarely the problem.
• Score candidates on 7 criteria at 0-2 points each, 14 max: workload fit, data parity, workflow parity, environment parity, ownership of the cloud account, cost model at scale, and compliance and residency. 11-14 means a drop-in move in days, 7-10 means weeks of adaptation, 0-6 means genuine re-architecture, so pick another candidate.
• Qovery keeps the Heroku-style developer experience (git-push deploys, preview environments per pull request, databases backed by managed cloud services, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC) while deploying into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so the cloud bill, committed-use discounts, and data residency stay in your name.
• The database is the migration project, not the app. Plan the Heroku Postgres cutover as its own window using logical replication (or pg_dump/pg_restore under roughly 50 GB with a short read-only window), verify row counts and sequences, and never move the database and the web tier on the same night.

---

I have talked to a few hundred founders and engineering leaders over the last several years, and the Heroku conversation almost always follows the same arc. A team leaves Heroku for cost, scale, or compliance, moves to whatever platform their loudest engineer prefers, and roughly 18 months later hits the exact same ceiling on the next vendor. Same wall, new logo.

The reason is simple. Most teams pick their next platform by feature checklist, not by how much of their architecture they have to tear apart to get there. Those are different questions. This article answers the second one with a real verdict and a scoring rubric you can run yourself.

The short version is at the top of this page. Below, I show my work: what actually makes a migration painful, the rubric, a fair scored comparison of ten options, and the two passages you will reuse every time you do this - a pre-migration inventory and a phased sequencing plan.

What actually makes a Heroku migration painful?

A 12-factor Heroku app is already portable, so the pain concentrates in exactly four places: the add-ons, the background workers and scheduler, the release phase plus buildpack behavior, and the Review Apps habit your team built around Heroku. Name those four and the project stops being vague.

Here is why the app itself is usually the easy part. The 12-factor methodology that Heroku's own engineers authored assumes config in the environment, stateless processes, logs to stdout, and disposable dynos. If you followed it, your code already runs anywhere a container runs. The friction lives in the glue Heroku gave you for free.

Where re-architecture actually bites:

• Buildpack behavior. Heroku's buildpacks detect your language and assemble the runtime for you. On most alternatives you reproduce that in a Dockerfile, pinning the runtime and OS packages the buildpack used to inject silently.
• Add-on sprawl. Every DATABASE_URL, REDIS_URL, and add-on-specific SDK is a coupling point. The app reads them from config vars, but the backing service and its connection semantics change underneath you.
• Fixed-IP assumptions. If a partner allowlists your egress IP, you probably bought a static-IP add-on. That assumption breaks the moment you move.
• Router and dyno semantics you lose for free. Heroku's router kills any request that runs past 30 seconds (error H12), the dyno filesystem is ephemeral and wiped on every restart or deploy, and you have leaned on documented error codes like H12 (request timeout), H10 (app crashed), and R14 (memory quota exceeded) for years. On the new platform you own those behaviors and their monitoring.

The triggers that push teams off Heroku are worth naming honestly, because they decide which alternative fits. Heroku ended its free product plans (free dynos, free Postgres, free Data for Redis) - announced August 25, 2022, effective November 28, 2022. After that it is cost per dyno, scale ceilings, and compliance tiering: HIPAA and PCI on Heroku require Shield Private Spaces rather than Common Runtime dynos, and the Private Space you choose determines your region. If any of those is your reason for leaving, it will follow you onto the next vendor unless you plan for it.

The Heroku primitive to target mapping

Before you compare anything, translate your Heroku primitives into what you will actually run. This table is the Rosetta Stone for the rest of the project.

The pre-migration inventory you can run in one afternoon

This is the single most valuable hour of the whole project. Produce this list before you shortlist anything:

1. Process types and how many of each you run at peak (web, worker, clock).
2. Every add-on and its plan tier, with monthly cost.
3. Every scheduled job and what it does.
4. Config var count, and which are secrets.
5. Postgres data volume, installed extensions, and major version.
6. Peak concurrent dyno count.
7. Monthly Heroku spend, itemized.
8. Who owns DNS.
9. Which third parties allowlist your egress IPs.

The falsifiable rule: if you cannot fit that inventory on one page, no shortlist you build from it is meaningful. Every effort estimate in this article assumes you have it.

What criteria should we score Heroku alternatives against?

Score every candidate on seven criteria at 0 to 2 points each, 14 maximum: workload fit, data and add-on parity, deployment workflow parity, environment and preview parity, where it runs (vendor account vs your own cloud account), cost model at your scale, and compliance and data residency. 11-14 means a drop-in move in days, 7-10 means weeks of adaptation, 0-6 means real re-architecture and you should pick another candidate.

Publish this rubric internally and score candidates as a team. It turns "I have a good feeling about X" into a number you can argue about.

Every score in this article is my assessment based on each vendor's documented capabilities, not a number the vendor published. I link the doc page behind each judgement so you can check my reasoning and re-score for your own workload.

A worked example, with the arithmetic visible

Take a common shape: a Rails app with Sidekiq workers, one Heroku Postgres, one Redis, and Review Apps. I will score two real contenders, Render and Fly.io, so you can see the rubric produce different numbers for different reasons. I am deliberately not using Qovery here.

Render

• Workload fit 2 - web services, background workers, and cron jobs are all first-class.
• Data parity 2 - managed Postgres and a Redis-compatible Key Value store with backups.
• Workflow parity 2 - git-push deploys, streamed build logs, rollback, and a pre-deploy command.
• Environment parity 2 - preview environments per pull request via render.yaml, torn down on merge.
• Ownership 0 - runs in Render's account.
• Cost model 1 - per-instance and predictable at small scale, with vendor markup as you grow.
• Compliance 2 - SOC 2 Type 2, ISO 27001, and HIPAA with a BAA on the Scale plan or above.

Total: 2 + 2 + 2 + 2 + 0 + 1 + 2 = 11/14. A drop-in move in days.

Fly.io

• Workload fit 2 - runs any process, workers included.
• Data parity 1 - you take on more of the database operation yourself than a fully managed add-on gives you.
• Workflow parity 1 - fly deploy with a release_command, but git-push is something you wire through CI rather than getting by default.
• Environment parity 1 - per-PR previews are possible through the GitHub Action, not turnkey like Review Apps.
• Ownership 0 - runs in Fly's infrastructure.
• Cost model 2 - usage-based, and Machines can scale to zero, which is efficient.
• Compliance 1 - SOC 2 and region choice, with HIPAA available on higher tiers.

Total: 2 + 1 + 1 + 1 + 0 + 2 + 1 = 8/14. Weeks of adaptation, mostly because you adopt the Machines lifecycle and private networking model rather than because your Rails code changes.

Same app, 11 versus 8, and the gap is entirely in workflow and environment parity - not the application. That is the rubric doing its job.

Which Heroku alternatives require the least re-architecture?

Ranked by re-architecture effort for a standard 12-factor web-plus-worker app: Render and Railway are closest to drop-in, Fly.io is close but you adopt its Machines and private-networking model, DigitalOcean App Platform is simple with a lower ceiling, Aptible is the pick when HIPAA or SOC 2 is the driver, Vercel/Neon/Upstash each replace one layer, self-hosted PaaS trades money for your own on-call, and Qovery trades a short setup for running inside your own cloud account.

First, group the options by what they actually are, so nobody compares a frontend host to a dyno platform:

• Heroku-style PaaS: Render, Railway, DigitalOcean App Platform, Aptible.
• Machine runtime: Fly.io.
• Frontend and serverless platform: Vercel.
• Managed data layers: Neon (Postgres), Upstash (Redis and Kafka-compatible).
• Platform on your own cloud (BYOC): Qovery.
• Self-hosted PaaS: Dokku, Coolify, Dokploy.

Render and Railway are usually the fastest, lowest-effort move for a small 12-factor app. I am not asserting that from vibes - both publish Heroku migration guides that spell out exactly what changes (Render, Railway). If your Heroku bill is modest and nobody on the team wants to own infrastructure, pick one of them and move on. That is the honest answer for a large share of Heroku teams.

Fly.io is strong when you need global latency or per-machine control. What changes is the networking model (6PN and Flycast), volumes, and the Machines lifecycle - not your app code. Its own Heroku migration guide is a good map.

Vercel is the right answer for Next.js and frontend workloads and the wrong answer for a Rails or Django monolith with Sidekiq or Celery workers. This is not an opinion. Vercel functions are request-scoped, and its own docs cap function duration at 300 seconds by default and 800 seconds on Pro, with no persistent background-worker process model. A job queue that runs for minutes has nowhere to live. Teams that try end up running Vercel for the frontend and a second platform for the backend.

Neon and Upstash are components, not destinations. Neon is excellent managed Postgres with branching and scale-to-zero; Upstash is serverless Redis and Kafka-compatible messaging. They can cut your database cost or add scale-to-zero, but they do not replace dynos, workers, or your deploy workflow. Reach for them alongside a platform, not instead of one.

Aptible is the strongest fit when HIPAA or SOC 2 is precisely why Heroku's compliance tiering stopped working for you. It carries HIPAA, HITRUST, SOC 2, and PCI and signs a BAA with every customer by default. If compliance is the driver, that default matters more than a point of DX.

Self-hosted PaaS (Dokku, Coolify, Dokploy) has the cheapest sticker price. Dokku in particular is git-push Heroku-style deployment on your own server. The trade is that you become the platform team: OS patching, database backups, TLS renewal, and the 3am page all move to you.

Qovery keeps git-push deploys, per-pull-request preview environments, databases backed by managed cloud services, environment auto-stop for non-production, managed cluster upgrades, and per-environment RBAC, while deploying into your own AWS, GCP, Azure, or Scaleway account, or an existing Kubernetes cluster. The developer experience stays Heroku-shaped; the cloud bill, committed-use discounts, and data residency stay in your name.

The alternatives matrix

Scores are my assessment of documented capability for a 12-factor web-plus-worker app, on the rubric above. Prices and features change - I checked vendor docs and pricing in September 2026.

* Vercel's 7 is misleading on purpose: workload fit scores 0 for a Rails-plus-Sidekiq monolith, and a 0 on that one criterion disqualifies it no matter what the total says. That is the rubric working as designed.

† Neon and Upstash are single-layer components. Scoring them on a whole-app rubric is a category error; I included them only to show they fill one criterion and leave six empty.

About that 14 for Qovery. I want to be straight, because a vendor scoring its own product top of the table earns a raised eyebrow. The rubric rewards ownership, cost control, and compliance, and BYOC exists specifically to win those three. Strip out ownership, cost, and compliance because you genuinely do not care about any of them, and the picture flips: Render or Railway win on smaller surface area, and I would tell you to pick one. Qovery earns its 14 exactly when those criteria are why you are leaving Heroku in the first place.

Should we move to another PaaS or run on our own cloud account?

Pick another managed PaaS if your monthly bill is modest and nobody on the team wants to own infrastructure. Pick your own cloud account with a developer platform on top if cost, scale, compliance, data residency, or unused cloud credits are what pushed you off Heroku, because those five problems follow you onto the next vendor's platform.

The honest case for another PaaS: fastest migration, no platform hire, a tiny ops surface, and a predictable bill at small scale. For a lot of teams that is the whole decision, and they should stop reading here and go migrate to Render or Railway.

The honest case for your own cloud account is about where the money and the data live. Committed-use discounts, savings plans, and startup credits only land when the bill is in your name. AWS publishes up to 72% on Savings Plans, Azure up to 72% on Reservations, and Google Cloud up to 55% on standard committed use discounts (higher on memory-optimized). Spot capacity for stateless workers runs up to 90% off on-demand on AWS. None of that reaches you through a PaaS reseller. You also get VPC-private data paths, any region you need, and the managed services your team already knows - Amazon RDS, Cloud SQL, Azure Database for PostgreSQL, ElastiCache, Memorystore.

The trap is in the middle. Assembling Kubernetes plus Terraform plus Argo CD plus IAM plus a secrets manager plus a home-grown review-app system is where teams lose a quarter and still have no preview environments. Kubernetes is now the default substrate - 82% of container users run it in production per the 2025 CNCF survey - but the platform layer on top of it is what actually ships software, and hand-rolling it is a multi-month detour. Gartner's read is that by 2026, 80% of software engineering organizations will establish platform teams; the question is whether you build that platform or adopt one.

The third path is a BYOC internal developer platform such as Qovery: Kubernetes-native and cloud-agnostic across AWS, GCP, Azure, Scaleway, or your existing cluster, with git-push deploys, per-PR preview environments, environment auto-stop, managed cluster upgrades, and per-environment RBAC. You get the PaaS developer experience without building the plumbing, and the bill stays yours.

Three paths compared

A decision rule you can self-select against in one paragraph: if your Heroku bill is under roughly a few thousand dollars a month and compliance is not in scope, move to Render or Railway and do not think about infrastructure again. If your bill is meaningfully larger, or HIPAA/SOC 2/EU residency is in scope, or you are sitting on cloud credits, run on your own account with a platform on top. Only build your own Kubernetes platform if platform engineering is your product, or you have a funded team whose full-time job is to run it.

How do we migrate Heroku Postgres and Redis without downtime?

Treat data as its own project with its own cutover window. For Postgres, use logical replication into the target managed database (or pg_dump/pg_restore for datasets under roughly 50 GB where a short read-only window is acceptable), verify row counts and sequences, then flip DATABASE_URL. For Redis, first decide whether the data is disposable cache or queue state that must be drained. Logical replication has been in PostgreSQL since version 10 and is documented for replicating across major versions, which is what makes a near-zero-downtime cutover possible.

The Postgres path, step by step:

1. Size the dataset and provision the target - Amazon RDS or Aurora, Cloud SQL, Azure Database for PostgreSQL, Scaleway, or Neon.
2. Test the restore into a throwaway copy first. Never rehearse on the real target.
3. Set up logical replication, or schedule a dump/restore window if you are under ~50 GB.
4. Take a short read-only window on the source.
5. Verify row counts, sequence values, and constraints against the source.
6. Cut over by flipping DATABASE_URL.
7. Keep Heroku live as a rollback path for 48 hours.

Heroku Postgres specifics to check before you commit: the available extensions, major-version parity with your target, connection limits per plan and whether you need PgBouncer or connection pooling (Essential-tier plans cap at 20 to 40 connections, Standard and Premium at up to 500), follower databases, and credential rotation.

If you want the hand-rolled steps to disappear, the managed migration services all document PostgreSQL sources: AWS Database Migration Service, Google Cloud Database Migration Service, and the migration service in Azure Database for PostgreSQL.

Redis is not one thing. Separate cache from session store from queue. Disposable cache can be re-warmed and needs no migration. Session state needs a quiet window. Sidekiq and Celery queues need draining, not replication - stop enqueuing, let the workers finish, then point the new workers at the new Redis. Kafka and other add-on data map to Amazon MSK, Confluent Cloud, or Upstash, and what changes is client config: broker list, SASL mechanism, and TLS.

Two things teams forget until cutover night. Static egress IPs: a NAT gateway with an elastic IP in your own VPC replaces Heroku's fixed-IP add-on, and you must re-register those IPs with partners days ahead, not the night of. And a first-24-hour dashboard: error rate, p95 latency per endpoint, connection-pool saturation, queue depth, and replication lag. Watch those, not the deploy log.

What does a Heroku migration cost, and how long does it take?

These are estimates based on experience, not guarantees. For a standard 12-factor app with one Postgres, one Redis, and a worker fleet, a PaaS-to-PaaS move is typically days to two weeks of engineering time. Moving onto your own cloud account with a platform on top is typically two to six weeks. Assembling your own Kubernetes platform is where multi-month timelines and a platform hire come from. Treat every number here as a range, because your inventory from section one is what really sets it.

Split the cost into three buckets and price each separately:

1. Engineering hours for the move - the one-time cost.
2. Monthly platform plus compute cost after - the recurring cost.
3. Ongoing ops cost - who upgrades the cluster, who is on call at 3am. This is the bucket teams forget, and on the DIY path it is the biggest one.

For the compute comparison, put Heroku's published prices next to the closest cloud equivalents and check the dates yourself. Heroku dyno pricing runs from Eco ($5/month for a shared pool) and Basic ($7/month) up through Standard-1X ($25), Standard-2X ($50), Performance-M ($250), and Performance-L ($500), with Postgres plans starting around $5/month (all checked September 2026). Compare against AWS EC2 and RDS for PostgreSQL, GCP Compute Engine and Cloud SQL, Azure VMs and Database for PostgreSQL, or Scaleway. The raw instance is almost always cheaper than the dyno; the platform layer is what you are really paying for on either side.

Where the savings actually come from on your own account: no per-dyno markup, right-sizing to real CPU and memory usage, spot or preemptible capacity for stateless workers (up to ~90% off), committed-use discounts and savings plans (up to ~72%), and auto-stopping non-production environments overnight and at weekends.

The hidden costs teams forget: NAT gateway hours and per-GB processing ($0.045/hour plus $0.045/GB on AWS), data egress (roughly $0.09/GB to the internet, $0.01/GB cross-AZ), load balancers, log and metrics ingestion, backup storage, and preview environments nobody shut down.

This waste is not hypothetical. The Flexera 2024 State of the Cloud Report found respondents estimate 27% of cloud spend is wasted, and the FinOps Foundation's State of FinOps 2024 ranked reducing waste and managing commitments the top priority for the first time. Owning the bill is what lets you attack that 27%. On a PaaS you cannot.

Effort and cost profile by path

How should we sequence the migration so nothing breaks?

Migrate in this order: reach build and runtime parity in staging, move stateless background workers first, then the web tier behind DNS weighting, then the database in its own planned cutover window. Never move the database and the web tier on the same night. This ordering front-loads the low-risk work and isolates the one step that can actually lose data.

• Phase 0 - inventory and build parity. Reproduce buildpack behavior in a Dockerfile, pin runtime and language versions, keep each Procfile process type as its own service, and port the release phase to a pre-deploy migration step that runs before traffic shifts.
• Phase 1 - target and staging. Provision the environment, wire secrets, prove build-and-deploy on every push, and get preview environments per pull request working so the team keeps its Review Apps habit from day one.
• Phase 2 - workers and cron first. This is the lowest user-facing risk and the highest confidence gain. It proves your queue and secrets wiring before a single customer is involved.
• Phase 3 - web tier. Shift traffic with DNS weighting or a reverse-proxy split, add health checks and autoscaling rules, and load-test at your peak dyno equivalent. Then, and only then, do the database cutover in its own separate window.
• Phase 4 - decommission. Retire add-ons in dependency order, rotate every credential, and keep the Heroku rollback path alive for one week.

Definition of done, stated as measurable outcomes: developers ship without a platform engineer in the loop, preview environments cost less than Heroku Review Apps did, and p95 latency plus error rate match or beat the Heroku baseline. If you cannot say yes to all three, you are not done.