Leaving Heroku With Your Procfile Intact: 7 Migration Paths for a 5-Person Team

Key Points

• Your Procfile travels further than your buildpacks. Dokku, Railway, and Fly.io build from Heroku-compatible buildpacks or Cloud Native Buildpacks and honour Procfile process types. Render, DigitalOcean App Platform, Northflank, and Qovery want a Dockerfile or a prebuilt image, and each Procfile line becomes a separate service.
• Shortest-diff ranking for a 5-person team with no ops hire: Dokku (self-hosted, closest Heroku clone, git push dokku main works day one), Railway (managed, closest to the old Heroku UX), Fly.io (a documented Heroku migration path where Procfile process types map to fly.toml [processes]).
• Converting a Procfile to a Dockerfile is a 15-25 line job: a base image matching the buildpack-detected runtime, one dependency-install layer, and one start command per process type. pack build --builder heroku/builder:24 produces an OCI image straight from a buildpack app, so you can do the conversion without hand-writing anything.
• If you want Heroku's git-push workflow but the infrastructure in your own name, Qovery deploys into your own AWS, GCP, Azure, or Scaleway account - or an existing Kubernetes cluster you already run. Each Procfile process becomes a Qovery application or worker, and the cloud bill plus any committed-use discounts stay yours.
• Heroku removed its free product tiers on 28 November 2022, which is what started most of these migrations. Price the real workload (1 web + 1 worker + 1 Postgres) on every destination first, because add-ons, not dynos, are usually the bigger half of a Heroku bill.

A five-person team cannot afford a three-month migration, so the only question worth asking is how small the diff can be. If you want your Procfile and buildpacks to keep working untouched, go to Dokku, Railway, or Fly.io. If you will spend one afternoon writing a Dockerfile and want a destination that survives the next platform switch too, go to Render, Northflank, or Qovery. That is the whole decision. Everything below is how to make it with your eyes open, with real prices checked in October 2026 and every number linked to the page it came from.

I have watched a lot of teams treat leaving Heroku like a rewrite. It almost never is. A Heroku app is four separable things, and only two of them cost you real work.

What actually breaks when you leave Heroku, and what doesn't?

A Heroku deployment is four pieces: the Procfile, the buildpack, your config vars, and your add-ons. The first three are portable. The add-ons and the release phase are the only parts that take real effort.

The Procfile is just a list of process types, so it is portable as a concept anywhere. Buildpacks are portable to anything that runs Cloud Native Buildpacks, because Heroku itself now ships CNB builder images: the heroku/builder:24 and heroku/builder:26 tags cover .NET, Go, Java, Node.js, PHP, Python, Ruby, and Scala (heroku/cnb-builder-images). When another platform advertises "buildpack support" in 2026, it almost always means CNB support, not Heroku's classic slug compiler. Config vars are trivially portable, and I will give you the one command for that in a second.

Procfile process types map cleanly onto every destination. web, worker, release, clock, and any arbitrary named type become Dokku process types, Railway services, Fly.io fly.toml [processes], Render services in render.yaml, Kubernetes Deployments, or Qovery applications and workers. The concept survives. The plumbing changes.

The real work is the add-ons: replacing managed Postgres and Redis, re-creating Heroku Scheduler jobs, wiring the release phase into a pre-deploy hook, re-pointing log drains, and rebuilding review apps. The release phase is the one everyone forgets, and it bites hard, because on Heroku a failed release blocks the deploy and keeps your migrations honest. Reproduce that behaviour or you will ship a broken schema.

Before you touch anything, run this:

heroku config -s > .env

That one line is the most underrated step in the whole migration. It dumps every config var in a format you can import straight into the next platform.

One trap nobody expects: Heroku restarts your dynos roughly once every 24 hours (the docs say once every 24 hours plus up to 216 random minutes). That daily restart quietly masks memory leaks. Teams discover the leak the week after they migrate, when their process runs for three days straight and falls over. Load-test for a few days before you cut DNS.

Which Heroku alternatives still run Procfiles and buildpacks natively in 2026?

Three platforms let a Procfile plus buildpacks keep working with essentially no code change: Dokku, Railway, and Fly.io. The rest want a Dockerfile.

Dokku calls itself "an open source PaaS alternative to Heroku," and it means it. You push Heroku-compatible apps over Git to your own single host. It defaults to herokuish buildpacks and also supports Cloud Native Buildpacks, it respects your Procfile, and Postgres and Redis come from official plugins. At around 32,000 GitHub stars it is a mature, battle-tested project. It really is the closest thing to Heroku that exists.

Railway is the easiest managed landing spot. Its default builder, Railpack (the successor to Nixpacks), detects a Procfile in your repo root and uses it for the start command, and its per-service model feels like the old Heroku dashboard.

Fly.io publishes an actual Migrate from Heroku guide, and it is genuinely good. flyctl can build with buildpacks, and your Procfile process types map directly to fly.toml [processes]. Machines billing and global placement make it the pick for latency-sensitive or multi-region apps.

Render, DigitalOcean App Platform, Northflank, and Qovery want a Dockerfile or a prebuilt image. Render runs native language runtimes and does not read a Procfile at all; you declare services in render.yaml. DigitalOcean App Platform supports Cloud Native Buildpacks for a documented language list but still turns each process into its own component. Northflank and Qovery are Kubernetes-native and aimed at teams that want to own the runtime and the cloud account.

Capability matrix checked against each vendor's docs, October 2026.

What is the fastest migration path if you want to change almost nothing?

If minimal diff is the hard requirement, Dokku and Railway both take your Procfile as-is and build with buildpacks, so a small app moves in an afternoon, not a quarter.

Dokku, in order: provision a VM on any cloud, install Dokku, run dokku apps:create, add the git remote, push, install the Postgres plugin and link it, then import your config with dokku config:set fed from that .env file. Railway, in order: connect the repo, let Railpack detect the stack, paste your config vars, add Postgres, create one service per Procfile line, and give the worker its own start command. Fly.io, in order: run fly launch, review the generated fly.toml, declare [processes] from the Procfile, attach a database, and load secrets with fly secrets import.

Here is the honest trade-off. Dokku means you now own patching, backups, and a single point of failure. That box is yours at 3 a.m. Railway and Fly.io keep you on someone else's infrastructure, which means someone else's pricing and someone else's outages, but also someone else's pager. Pick Dokku for cost control and full control, Railway when you just want Heroku back, and Fly.io when latency or multi-region actually matters to your product.

When should you convert your Procfile and buildpacks to a Dockerfile instead?

Convert to a Dockerfile the moment you want a destination that outlives the platform you pick next. A Dockerfile runs identically on Render, Northflank, Qovery, ECS, and any Kubernetes cluster, while buildpack support is platform-specific and can be deprecated out from under you.

The mapping is mechanical. The buildpack-detected runtime becomes your base image, dependency install becomes a RUN layer, each Procfile line becomes a start command for one service, and release: becomes a pre-deploy job or an init container.

# web:     bundle exec puma -p $PORT
# worker:  bundle exec sidekiq
# release: bundle exec rake db:migrate

FROM ruby:3.3-slim
WORKDIR /app
COPY Gemfile Gemfile.lock ./
RUN bundle install
COPY . .
EXPOSE 8080
CMD ["bundle", "exec", "puma", "-p", "8080"]

# Per-service start commands on the new platform:
#   web:     bundle exec puma -p $PORT
#   worker:  bundle exec sidekiq
#   release: run `bundle exec rake db:migrate` as a pre-deploy hook

You do not have to hand-write that, though. This is the single most useful tip in the piece:

pack build --builder heroku/builder:24 turns a buildpack app straight into an OCI image, zero Dockerfile required (confirm the current tag against heroku/cnb-builder-images; :26 is now the recommended builder). That is the genuine halfway house: you keep buildpack convenience and walk away with a portable image.

Watch the pitfalls that bite: bind to the $PORT env var (Heroku injects it, most alternatives do too but not identically), run as a non-root user, remember you lose Heroku's slug build cache, swap .slugignore for .dockerignore, and wire release-phase migrations into an explicit pre-deploy hook. Pay this cost once and the next platform move takes hours instead of weeks.

What does each Heroku alternative cost for a web process, a worker, and a Postgres database?

Price the same reference workload everywhere, because a Heroku bill is rarely just dynos. My reference: 1 web process (around 512 MB to 1 GB), 1 background worker, and roughly 10 GB of Postgres. There are three cost models: vendor-priced compute (Heroku, Render, Railway, Fly.io, DigitalOcean), your own cloud bill plus a platform fee (Qovery, self-managed Kubernetes), and raw infra plus your engineering time (Dokku).

Reference workload: 1 web + 1 worker + ~10 GB Postgres. Prices from each vendor's public pricing page, checked October 2026. Where a vendor sells no fixed 10 GB plan (Render, Northflank), the figure is compute tier plus per-GB storage. Railway and Fly managed Postgres are usage- or plan-dependent; see the pricing page.

Two things that table does not show. First, the hidden costs: egress, the markup managed databases carry over raw RDS or Cloud SQL, and the engineer-hours Dokku quietly eats every month. Second, non-production waste. Small teams recover the most money by auto-stopping staging and preview environments outside working hours, which almost nobody does on Heroku.

Notice the Qovery row looks expensive at this size, and it is, because a $299 platform fee on top of a $28 workload makes no sense for one tiny app. That math flips when you are running many services across many environments and can put your compute on AWS Compute Savings Plans (up to 66%) or GCP committed-use discounts (up to 70% on some series). My rule of thumb: move from a vendor-priced PaaS to your own cloud account when your compute spend crosses roughly a thousand dollars a month, when data residency or a customer security review forces your hand, or when committed-use discounts would pay for the switch on their own.

How does Qovery fit for a team that wants Heroku's workflow on its own cloud account?

Qovery gives you the git-push workflow and the per-service process model you had on Heroku, but deploys into your own AWS, GCP, Azure, or Scaleway account, or an existing Kubernetes cluster you already run. The infrastructure, the data, and any cloud discounts stay in your name.

The Heroku model maps over one piece at a time. Each Procfile process type becomes a Qovery application or worker. Config vars become environment variables with per-environment scoping. Heroku Postgres becomes a database backed by a managed cloud service in your account. The build input is a Dockerfile or a prebuilt image, which is exactly why the Dockerfile conversion two sections up is the entry ticket. Qovery does not ingest Heroku buildpacks natively, so do the pack build step first.

What a five-person team actually gets: git-push deployments, preview environments per pull request, and per-environment RBAC, with Qovery operating the Kubernetes layer so you are not hand-patching nodes.

Now the fair part. Qovery is not the zero-thought option. You need a cloud account, and there is Kubernetes underneath even though Qovery runs it for you. If you never want to open a cloud console, Railway or Render is the better answer, full stop. Where Qovery beats Dokku for the same team is everything past the single box: no VM to babysit, no manual patching, and a real multi-environment workflow instead of one host that becomes a liability the day it fills up.

What migration checklist should a five-person team follow, and how long does it take?

Run it in this order: export config, reproduce the build, stand up the new environment, move the database last, and keep Heroku warm until DNS has been cut over for a full business week. For a typical small app this is days of work, not months.

The checklist: inventory every Procfile process and add-on; run heroku config -s > .env; reproduce the build locally with pack build or a Dockerfile; stand up staging on the new platform first; replicate scheduled jobs; dry-run the database move; cut DNS with a low TTL; and leave Heroku running so you can roll back in minutes.

For the database, you have two options. pg_dump and pg_restore give you a short maintenance window and are simplest. Logical replication gives you near-zero downtime but more moving parts. Either way, test the restore twice before the real cutover, because the backup you never restored is not a backup.

What teams forget every single time: the release phase, log drains, SSL certificates, scheduled jobs, the heroku run one-off equivalents, and review apps. Write those on the whiteboard first.

Assign owners. On a five-person team, one person runs the build conversion, one owns the database cutover, and one owns DNS and rollback, all on the same afternoon. The one condition that should make you postpone: an active release crunch. Do not migrate your platform and ship a feature deadline in the same week.

Can I keep using my Procfile after leaving Heroku?

Yes, on some destinations. Dokku, Railway, and Fly.io all understand Procfile process types, either natively or by mapping them into their own config. Dokku and Railway read the Procfile directly, while Fly.io translates its entries into fly.toml [processes] during migration. Render, DigitalOcean App Platform, Northflank, and Qovery do not read a Procfile and expect a Dockerfile or prebuilt image instead.

Which Heroku alternatives support buildpacks natively in 2026?

Dokku supports both herokuish (Heroku-style) buildpacks and Cloud Native Buildpacks. Railway builds with Railpack, which succeeded Nixpacks and detects your Procfile. Fly.io and DigitalOcean App Platform both support Cloud Native Buildpacks through their build tooling. Render uses native language runtimes rather than buildpacks, and Qovery uses a Dockerfile or image.

Do I have to convert my Heroku app to a Dockerfile to migrate off Heroku?

No, not if you pick Dokku, Railway, or Fly.io, which keep your buildpack workflow. You only need a Dockerfile for destinations like Render, Northflank, or Qovery. Converting is worthwhile anyway if you want portability, because a Dockerfile runs the same on any container platform while buildpack support is platform-specific.

How do I convert a Procfile and buildpacks into a Dockerfile?

Map the buildpack-detected runtime to a base image, put dependency installation in a RUN layer, turn each Procfile line into a start command for one service, and move the release step into a pre-deploy hook. The fastest route is pack build --builder heroku/builder:24, which produces an OCI image straight from your buildpack app with no hand-written Dockerfile. Remember to bind to $PORT and run as a non-root user.

Is Dokku a realistic Heroku replacement for a five-person team?

Yes, if someone on the team is comfortable owning a server. Dokku is the closest open-source clone of Heroku, it accepts your Procfile and buildpacks, and git push just works. The trade-off is that you now own patching, backups, and a single point of failure, so it fits teams that want cost and control over hands-off convenience.

How do I migrate a Heroku Postgres database with minimal downtime?

For a short maintenance window, use pg_dump and pg_restore into the new managed database. For near-zero downtime, set up logical replication from Heroku Postgres to the target and cut over once it has caught up. Test the restore at least twice before the real cutover, and keep the Heroku database available for rollback until the new one has run cleanly for a week.

What is the cheapest Heroku alternative for a web process, a worker, and a database?

For the reference workload of one web process, one worker, and about 10 GB of Postgres, Dokku on a single small VM is the cheapest at roughly $12 to $24 a month plus your time, since the database runs on the same box. Among managed options, Heroku's own Basic dynos plus Essential-1 Postgres come to around $23, with Fly.io's self-run Postgres and DigitalOcean App Platform close behind. Always price your real workload on the vendor's current pricing page, because add-ons usually cost more than compute.

Leaving Heroku is not a rewrite. It is an afternoon of moving four known pieces, and the only real decision is whether you keep your buildpacks or trade one afternoon for a Dockerfile that outlives your next platform too. Pick the smallest diff that gets your infrastructure where you want it to live.