Heroku Replacement: The Nine Things Heroku Did for You, and How to Check a Replacement Does Them

A Heroku replacement is not a vendor. It is a host that covers the nine things Heroku quietly did for you: build the app from a push, run it as a managed process, hold config in environment variables, attach a database, keep logs, roll back, scale by a slider, serve a domain with a certificate, and give every branch a preview. Most candidates cover six or seven. The migration goes wrong on the two or three they skip, so check the list before you check the price.

The pages that rank for this term are lists of platforms, ten or eleven names with a paragraph each, refreshed every year. They are useful for knowing what exists and useless for choosing, because the question is not which platforms are popular but which one covers what your app currently depends on. In early 2026 Heroku said it was moving to a sustaining engineering model, stability over new features, which is a polite way of telling long-time users to start reading these lists. This post is the checklist to read them with.

Table of contents

• Why people are replacing Heroku now
• The nine things Heroku actually did
• How to score a candidate against the list
• The three shapes a replacement takes
• What the migration actually involves
• What a small app costs after the move
• How this fits the rest of the stack
• FAQ

Why people are replacing Heroku now

Heroku was the platform that made git push a deploy. For a decade that was enough of a reason to pay its premium: you pushed, a buildpack detected the language, a dyno ran the process, and the database was one command away. The price was never the problem for a small app. The problem arrived later, in three forms.

The first was the end of the free tier, which pushed hobby projects and side businesses to look elsewhere and discover that the elsewhere was fine. The second was cost at the top of the ladder, where a few production dynos and a mid-sized Postgres add up to a bill that a VPS or a newer platform undercuts by a wide margin. The third, and the one behind the searches this year, is the announcement that the platform is now maintained rather than developed. Nothing breaks the day a vendor says that. The question it raises is whether you want to build the next five years on it.

So the search is reasonable. What is not reasonable is picking a replacement from a listicle, because Heroku’s value was never any single feature. It was the nine below working together, and a replacement is only a replacement if it covers the ones your app uses.

The nine things Heroku actually did

Write down which of these your app relies on. Most Rails, Django, Node and Go apps use seven or eight without anyone having decided to.

1. Build from a push. A buildpack detected the language, installed dependencies and produced a runnable slug. No Dockerfile, no CI config.
2. Run a managed process. The dyno ran the web and worker lines from a Procfile, restarted them when they crashed and cycled them daily.
3. Config in the environment. Every setting was a config var, injected at boot, changeable without a redeploy of code. The Heroku environment variables model is the one every platform since has copied.
4. A database one command away. Postgres as an add-on, with backups, a connection string in DATABASE_URL, and a plan ladder.
5. Logs in one stream. Build output, router lines and app output interleaved, with heroku logs --tail as the only command anyone remembered.
6. Rollback. Every release kept; heroku rollback put the previous one back in seconds.
7. Scale by a number. More dynos or a bigger dyno type, changed from a slider or a command, with no capacity planning.
8. Domains and certificates. A custom domain, a certificate issued and renewed automatically, HTTPS enforced.
9. Review apps. A running copy of every pull request, with its own database, destroyed on merge.

Add-ons beyond Postgres, scheduled jobs, pipelines with staging and production, and the metrics tab are real too, but they are the layer above. If a candidate covers the nine, those can be rebuilt. If it misses two of the nine, no amount of add-on marketplace makes up for it.

How to score a candidate against the list

Take the list to each platform’s documentation, not its landing page, and ask a specific question for each item. The landing page says deploy from Git; the docs say whether that means a buildpack, a Dockerfile you must write, or a Nixpacks-style detector with its own quirks.

• Build. Does it detect the language, or do you write a Dockerfile? A Dockerfile is not a problem, but it is a migration task, and a Procfile with a release: step for migrations needs an equivalent.
• Process model. Can you run a web process and a separate worker from the same repo, and does each get its own size and count? Some platforms make a worker a second service with a second bill.
• Config. Environment variables per service, per environment, changeable without a code deploy. Check whether changing one restarts the process, because on Heroku it did and your app may assume that.
• Database. Managed Postgres with automated backups, point-in-time recovery if you had it, and a private connection so the database is not on the public internet. Check the connection limit against your dyno count times pool size.
• Logs. Build and runtime in one place, retained for longer than the last thousand lines, searchable. The Heroku logs habit of tailing everything only works if the replacement has a tail.
• Rollback. Is a previous deploy re-deployable in one action, or is rollback a git revert and a rebuild? The second is five minutes instead of five seconds, which matters at two in the morning.
• Scaling. Vertical by plan, horizontal by instance count, and ideally automatic between a floor and a ceiling.
• Domains. Custom domain, automatic certificate, renewal you never think about.
• Previews. Per-branch or per-pull-request deploys. If the platform lacks them, decide whether you actually used review apps or just liked having them.

Score honestly. A platform that scores nine with a Dockerfile is a better replacement than one that scores seven with buildpacks, because the missing two are the ones that page you.

The three shapes a replacement takes

Every candidate on the lists falls into one of three shapes, and the shape decides how much of the operational work comes back to you.

A platform-as-a-service. The direct successor: push a repo, get a running service, a database beside it, logs and rollback in a dashboard. The PaaS services post covers what that category sells in general. This is where most Heroku apps should land, because the migration is a config-var export and a repo connection. The deployment platforms post walks through picking among them by the shape of the app.

A self-hosted PaaS on a VPS. Dokku, Coolify and their relatives run a Heroku-like push-to-deploy on a server you rent. Buildpacks still work, the bill is the server, and the operational work, patching, backups, the disk filling up, is yours. Good for a team that wants the Heroku workflow and already has someone who enjoys servers. The DigitalOcean and Heroku comparison covers how the two models differ in practice.

A container platform or the raw cloud. Kubernetes, ECS, a fleet of containers behind a load balancer. This is a replacement in the sense that it can run the app, and not a replacement in any other sense, because it covers item two of the nine and leaves the rest to you. Teams choose it when they have grown past what a PaaS can express, not because Heroku got expensive.

The honest mapping: if your app is a web process, a worker and a Postgres, shape one. If you have a platform engineer and eight services, shape three. Shape two is for the people in between who would rather pay in hours than in dollars.

What the migration actually involves

The move is shorter than the decision. For a typical app it is five steps, and the first four are the same on any replacement.

1. Export the config. heroku config -s > .env.production gives every var in KEY=value form. Read it before importing it; there will be add-on credentials for services you are also replacing.
2. Move the database. heroku pg:backups:capture then heroku pg:backups:download produces a custom-format dump; pg_restore loads it into the new managed instance. Do it once for a rehearsal, then once more for real with the old app in maintenance mode.
3. Connect the repository and describe the processes. On a buildpack platform this is nothing; on a Dockerfile platform it is a Dockerfile and a start command per process.
4. Set the environment variables, point DATABASE_URL at the new instance, deploy, and read the build log end to end. The first build finds the things the export missed.
5. Move DNS last. Lower the TTL a day before, cut over, watch the logs for an hour, then keep the Heroku app around for a week in case something only runs on the first of the month.

Scheduled jobs are the usual casualty. Heroku Scheduler was an add-on people forgot they had; find them with heroku addons and recreate them as cron entries or a scheduled worker on the new platform before the old app is deleted.

What a small app costs after the move

Heroku’s pricing model was per dyno per month, plus a database plan, plus each add-on. Replacements price the same three things, so the comparison is straightforward once the shapes are sized. A typical small production app is one web process, one worker and a Postgres that fits in a couple of gigabytes.

On RunxBuild, that maps to two web services and a managed database on the same plan ladder. A web process on the $6 Basic plan (0.5 vCPU, 624MB) handles a small Rails or Django app; a worker on the $4 Dev plan is enough for a queue that mostly sleeps; a managed Postgres on the $13 BasicMini plan (1 vCPU, 1GB) covers the database with backups, a connection limit you can read, and private networking so it is not reachable from the internet. That is $23 a month for the three, and every one of them can scale between a floor plan and a ceiling plan automatically when traffic arrives, which is item seven on the list done for you. The web services docs cover the build-from-GitHub, logs and rollback side, which are items one, five and six.

The honest caveat is that the cheapest plan is rarely the right one for a production app that people pay for. Size the web process for the peak, not the average, and read the memory number rather than the price when choosing.

How this fits the rest of the stack

A Heroku replacement is a host that scores nine out of nine on the things Heroku did for you, or eight with a gap you have consciously accepted. Score candidates against the list from their docs, choose the shape that matches how much operational work you want back, and rehearse the database move before the real one. For a sense of what the replacement costs before it commits, the RunxBuild hosting calculator shows the line items together: the web process, the worker, the database, the bandwidth, each as its own number, so the comparison to the old bill is a real one rather than a landing-page claim.

Useful related references:

• DigitalOcean and Heroku: How the Two Deployment Models Actually Differ
• PaaS Services: What You Are Actually Buying
• Deployment Platforms: The Five Kinds, and How to Pick One by the Shape of Your App
• Deploy from GitHub on RunxBuild
• Managed Databases on RunxBuild

FAQ

Is Heroku shutting down?

No. In early 2026 the company said the platform was moving to a sustaining engineering model, meaning it will be maintained for stability and security rather than gaining new features. Existing apps keep running. The reason to look for a replacement is that a maintained-only platform is a poor foundation for the next several years, not that the current one stops working.

What is the closest replacement for Heroku?

Any platform-as-a-service that builds from a Git push, runs web and worker processes, holds config in environment variables, provides a managed Postgres, keeps logs, and can roll back a deploy. Several platforms do all of that. Score them against the nine-item list in this post from their documentation rather than choosing from a ranked listicle.

Do I need a Dockerfile to leave Heroku?

On some platforms yes, on others no. Buildpack-style detection still exists on several hosts, and a Dockerfile is a one-time cost of an hour or two for a standard Rails, Django or Node app. Treat a Dockerfile requirement as a migration task, not as a reason to reject a platform that otherwise covers the list.

How do I move a Heroku Postgres database?

Capture a backup with heroku pg:backups:capture, download it with heroku pg:backups:download, and load it into the new managed instance with pg_restore. Rehearse once against a scratch database, then do it for real with the Heroku app in maintenance mode so no writes are lost between the dump and the cutover.

What usually breaks after migrating from Heroku?

Scheduled jobs, because Heroku Scheduler was an add-on people forgot; processes that assumed a config change restarts the app; and anything that depended on the daily dyno cycle to clear a memory leak. Export the add-on list before deleting the old app, and read the first build log on the new platform end to end.