Heroku Is in Sustaining-Engineering Mode. Dokku Is the Obvious Exit — Here's What It Actually Gets You (and What It Doesn't)

On February 6, 2026, Heroku published a short post titled "An Update on Heroku" that did more to reshape PaaS migration planning than any pricing change in the platform's history. The announcement — 525 points and 352 comments on Hacker News within a day — said Heroku is moving to a "sustaining engineering" model focused on "stability, security, reliability, and support," and that it will no longer sign new Enterprise Account contracts. Nobody's app was shut off. No sunset date was named. And yet, within weeks, teams that had run on Heroku for a decade started planning their exit.

For a lot of those teams, the shortest-looking path out is Dokku: the 13-year-old open-source project that was built, from its very first commit in 2013, to be a Heroku you run yourself. The pitch is real — your buildpacks work, your Procfile works, git push still deploys — and this post gives you the grounded version of it: a concept-by-concept map of what Dokku hands you, an honest list of what it doesn't, the actual migration command sequence, and the point at which Dokku's one-box architecture stops being a feature and starts being a ceiling.

What Actually Changed at Heroku on February 6​

The announcement itself, authored by Heroku CPO Nitin T Bhat, is carefully reassuring. "There is no change for customers using Heroku today," it says: pricing, billing, apps, pipelines, and add-ons all continue as before. Existing Enterprise subscriptions "will continue to be fully honored and may renew as usual." The change is directional: engineering investment shifts to keeping the platform stable rather than extending it, with Salesforce pointing its product energy at "enterprise-grade AI" instead.

The aftermath was messier than the announcement. Through March, Heroku kept shipping real improvements — larger slug sizes, CLI rebuilds, SSL fixes — which prompted Judoscale, a long-time Heroku ecosystem vendor, to publish an open letter in April titled "Dear Heroku: Uhh, What's Going On?" Their complaint wasn't that Heroku was dying; it was that "sustaining engineering" is corporate language that nobody can plan against, and they urged Heroku to publish a roadmap even if the roadmap is "do nothing." More telling was their field report: at a Ruby conference that spring, every team they spoke with was planning a migration.

Not everyone read the announcement as a death notice. Richard Schneeman — a former Heroku engineer and author of the Rust Cloud Native Buildpack — argued in "How to Sustain Heroku" that sustaining engineering is a legitimate strategy of focus: deciding what not to do, and investing in predictability instead of novelty. He's right that maintenance mode is not a shutdown. But platform decisions are made on roadmap risk, not on today's uptime. A platform that has publicly stopped selling to new enterprise customers is a platform whose future feature set, pricing leverage, and staffing you can no longer extrapolate. That is why teams with no immediate operational problem are migrating anyway.

What Dokku Actually Hands You: a Heroku-to-Dokku Concept Map​

Dokku describes itself as "the smallest PaaS implementation you've ever seen," and its core promise is compatibility: "you can push Heroku-compatible applications to it via Git. They'll build using Heroku buildpacks and then run in isolated containers." That is not marketing gloss — Dokku's default build path runs your app through the same buildpack model Heroku uses (via herokuish), which means a Rails or Node app that deploys to Heroku today usually deploys to Dokku with no code changes at all.

Here is the concept-by-concept mapping for the workflow you already know:

The project behind that table is unusually durable for a self-hosting tool. Dokku has been maintained continuously since 2013, sits at roughly 32,000 GitHub stars, and is currently shipping v0.38.x releases. The install is a single bootstrap script that takes 5–10 minutes on a supported OS (Ubuntu 22.04/24.04 or Debian 11+, AMD64 or arm64), and the documented minimum for the Docker scheduler is 1 GB of RAM. This is the entire platform footprint: one Linux box, Docker, an SSH key, and a wildcard DNS record.

It's fair to ask why Dokku over the rest of the 2026 self-hosted PaaS field — Coolify, CapRover, Kamal, or simply moving to Render. The honest answer is migration delta. Coolify and CapRover are good platforms with web UIs and their own deployment models; Kamal is a Docker deploy tool that expects you to bring a Dockerfile and think in containers. Dokku is the only one whose native contract is Heroku's contract — buildpacks, Procfile, config vars, git push — so a Heroku app moves with close to zero conceptual translation. If your goal is "get off Heroku with the least change to how we ship," that compatibility is the whole argument. If your goal is broader than that, keep reading, because the trade-offs are just as concrete.

What You Don't Get​

Dokku's documentation is refreshingly direct about what it is: "an extensible, open source Platform as a Service that runs on a single server of your choice." Every limit below follows from that sentence, and none of them is hidden — but a migrating team should price them in before the first git push.

• One box is the platform. By default there is no fleet, no scheduler placing workloads across machines, no failover. If the server dies, every app on it is down until you restore. Heroku's invisible multi-tenant substrate becomes one very visible VPS with your name on it.
• The multi-server story exists but is young. Since v0.33, Dokku ships a core k3s scheduler that can spread apps across a real Kubernetes cluster — a genuine step beyond one box. Its documented caveats are the tell: it requires an external image registry for artifacts, run:logs and ps:inspect are unimplemented, only one healthcheck each of liveness/readiness/startup is supported, and only the initial Dokku server can accept git pushes. It works, but it is not the declarative multi-machine platform the rest of Dokku's polish might lead you to expect.
• The Postgres plugin is not Heroku Postgres. dokku postgres:create runs a Postgres container on the same box as your app. You get a database in thirty seconds; you do not get automated failover, point-in-time recovery, follower databases, or a team of DBAs watching it. Backups (the plugin can push them to S3-compatible storage) and upgrade planning are now your job.
• Teams and access control live in the paid tier. Open-source Dokku authenticates by SSH key to a single dokku user. Multi-user management, RBAC, and a web UI are Dokku Pro features, not OSS ones.
• There is no platform API to speak of. Heroku's Platform API is what a decade of CI integrations, Terraform providers, and (lately) AI agents automate against. Dokku's automation surface is SSH commands. Scriptable, yes — but there's no first-class declarative API for tooling to target.

The Actual Migration: Ten Commands and One Hard Part​

For a typical Rails or Node app with Postgres, the app-side migration fits on one screen. On a fresh Ubuntu 24.04 box:

# On the server
wget -NP . https://dokku.com/install/v0.38.25/bootstrap.sh
sudo DOKKU_TAG=v0.38.25 bash bootstrap.sh
cat ~/.ssh/authorized_keys | dokku ssh-keys:add admin
dokku apps:create myapp
sudo dokku plugin:install https://github.com/dokku/dokku-postgres.git
dokku postgres:create myapp-db && dokku postgres:link myapp-db myapp
dokku config:set myapp RAILS_MASTER_KEY=... SECRET_KEY_BASE=...
 
# From your laptop, in the app repo
git remote add dokku dokku@your-server:myapp
git push dokku main
dokku domains:set myapp myapp.example.com && dokku letsencrypt:enable myapp

That git push triggers the same buildpack detection Heroku ran, boots the new container, health-checks it, and switches traffic. For most Heroku apps, the application layer really is this boring, and boring is the point.

The hard part is the database, and it's worth being unromantic about it. Your data currently lives in Heroku Postgres; it has to end up in a Postgres you operate, and the move is a full export/import (pg_dump/pg_restore or logical replication) with downtime proportional to your data size and your tolerance for cutover complexity. When Argos migrated a 300 GB PostgreSQL database off Heroku to AWS in early 2026, the database move — not the app — was the project. Budget your migration the same way: the app is an afternoon; the data is the plan. And before cutover, do the capacity math Heroku did for you — your dynos' combined RAM plus Postgres's working set now have to fit on one machine you chose.

When One Box Isn't Enough​

The single-server model is not a flaw; it's a fit test. For a solo developer, a small team, staging environments, or a portfolio of modest apps, one well-sized box running Dokku is arguably the correct amount of platform — it's why the project has stayed relevant for 13 years while flashier PaaS projects came and went.

The ceiling shows up on a schedule you can predict. You'll hit it when uptime requirements exceed what one machine can promise; when one noisy app can starve the others and you need real isolation; when multiple teams need to deploy without sharing a root-equivalent SSH user; or when your automation — CI, IaC, or an AI agent operating your infrastructure — needs a declarative API rather than SSH strings. At that point the choice is either to operate Dokku's k3s mode while accepting its documented gaps, or to move to a platform where multi-machine is the native model rather than the extension.

That second path is where Kubernetes Cluster API-based platforms come in: machines themselves become declarative resources, clusters scale by editing a spec, and the PaaS layer sits on top rather than inside one host. This is the gap Bex.co is built for — an open-source, AI-native Render alternative where git push still gets you a running HTTPS service on hardware you own, but the substrate is a Cluster API-managed fleet with a Render-compatible API, so the same familiar surface survives past the one-box stage and stays scriptable by humans and agents alike.

Migrate on Your Schedule, Not Salesforce's​

Sustaining-engineering eras don't end with a shutdown email; they end with slow decay — a dependency that stops getting updated, a support queue that gets longer, a price sheet with no competitive pressure behind it. Heroku in 2026 is still up, still fine, and still the platform that taught the whole industry what git push deployment should feel like. That's exactly why the right time to plan an exit is now, while nothing is on fire.

Dokku's honest offer is the smallest possible step off: the same buildpacks, the same Procfile, the same push-to-deploy loop, on a $10 box you control — with the single-server ceiling and the DIY database clearly priced in. If your workload fits under that ceiling, it's the lowest-delta migration in the industry. If it doesn't, or won't for long, pick a platform whose multi-machine story is the foundation rather than the newest plugin. Either way, the lesson of February 6 is the same: the deploy workflow you love is portable. The platform underneath it should be yours.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.