The Heroku page on my open-source alternatives directory lists three repositories. The numbers below come from the 2026-10-08 refresh. Stars, forks, language and license are from saas.json. Release data and open items are from evidence.json, generated at 07:33 UTC that day.
The table
"Open items" is the GitHub API's open issue count, which includes open pull requests.
| Repo | Stars | Forks | Language | License | Latest release | Releases, last 12 mo | Open items |
|---|---|---|---|---|---|---|---|
| coollabsio/coolify | 62,711 | 5,610 | PHP | Apache-2.0 |
v4.4.2, 2026-10-07 |
71 | 740 |
| dokku/dokku | 32,172 | 2,084 | Go | MIT |
v0.38.31, 2026-09-27 |
46 | 32 |
| caprover/caprover | 15,182 | 1,006 | TypeScript | Apache-2.0* |
v1.15.4, 2026-08-30 |
7 | 179 |
*The GitHub API returns NOASSERTION for CapRover. Its LICENSE file was checked by hand on 2026-09-05: it's the Apache License, Version 2.0, copyright BigZee Ventures LLC. The result is stored in license-overrides.json, so the page shows the license instead of a blank.
What the numbers say, and what they don't
All three latest tags name the product itself (v4.4.2, v0.38.31, v1.15.4). That matters because I wrote yesterday about release counts that measure tagging habits instead of shipping, where several repos' newest "release" turned out to be a CLI or a single package. None of that shows up in the newest tags here. My data stores only the latest tag, so I can't confirm all 71 of Coolify's releases name the app, but at least the most recent one does.
Coolify's latest release is dated 2026-10-07, one day before the refresh. It has the most stars, the most releases and the largest backlog of the three. 740 open items on 62,711 stars is a sign of a lot of people using it and filing things, not by itself a sign of neglect. Open items mix bug reports, feature requests and pull requests in one number, so I don't read it as a quality grade.
Dokku is the quiet one in a good way: 46 releases in a year and only 32 open items on 32,172 stars. That's the smallest backlog relative to stars in this set by a wide margin.
CapRover has 7 releases in 12 months, the latest on 2026-08-30, and its last push in my data is 2026-10-06. Seven releases isn't abandonment. It's a slower cadence than the other two, and if you need a fix shipped quickly that's worth knowing up front.
Picking by how close to Heroku you want to stay
The editorial note on my page puts them in this order:
- Coolify comes closest to the Heroku experience on your own VPS: git-push deploys, automatic SSL, and a one-click marketplace of services like Postgres and Redis. Its repo description claims "280+ one-click services" and names Vercel and Netlify alongside Heroku as what it replaces.
-
Dokku is Docker-based and compatible with Heroku buildpacks. If your app already deploys from a
Procfileand a buildpack, this is the shortest conceptual distance. - CapRover runs on Docker Swarm and describes itself as "Heroku on Steroids".
The same note is direct about what none of them replace. Heroku's one-click Postgres with automated backups and HA has no self-hosted equivalent unless you lean on a cloud provider. Review apps, a fresh environment per pull request, aren't reproduced by most of these. And none come near Heroku's Salesforce integration, which matters only if you were using it.
Before you migrate
The page's migration tips, condensed:
- Check whether your app uses Heroku buildpacks. The tips note that Dokku and Coolify both support buildpacks for compatible apps.
- Export Heroku Postgres with
pg:backups:captureand download the backup before you touch anything else. - Audit your add-ons (the tips name SendGrid, Papertrail and New Relic) and set up an equivalent for each one on the new platform.
- Copy every Config Var into the new platform's environment settings.
- Plan the DNS cutover. Lower the TTL ahead of time, then point the domain from Heroku to your server's IP.
The second step is the one I'd do first and verify twice. A self-hosted PaaS makes deploys yours, and it makes the database backups yours too. Stars and release counts won't tell you whether your restore actually works. Only a test restore will. For how I treat the license column when the API can't fill it, see the GitHub API license values my directory can't display verbatim.
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
Top comments (0)