HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dokku
dokku
Shell2013–2026
dokku / dokku

dokku

A docker-powered PaaS that helps you build and manage the lifecycle of applications

100Distinct people
122Mentions
3Explicit recommenders
32.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A docker-powered PaaS that helps you build and manage the lifecycle of applications

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I totally love fish, it's the first shell that made me replace bash as my default shell (zsh was "just not enough" to justify losing compatibility, for me). But is this project…

oelmekki used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year122 dated mentions

Observed mentions: 2013-06-10 07:34:27 UTC to 2026-02-07 09:15:58 UTC.

051015202013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 16 mentions; 3 submissions, 13 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 17 mentions; 1 submissions, 16 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 18 mentions; 0 submissions, 18 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 13 mentions; 2 submissions, 11 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC16313
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC17116
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC18018
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC12012
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC808
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC909
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC404
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC13211
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC12111
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC606
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

What Hacker News says

122 sources
I think there's a couple decent alternatives out there: https://alternativeto.net/software/heroku/ There are also a lot of cool "self-hosted Heroku" alternatives - Coolify (PHP) (2020) https://github.com/coollabsio/coolify - Dokku (Go) (2013) https://github.com/dokku/dokku - Dokploy (TypeScript) (2024) https://github.com/Dokploy/dokploy - CapRover (TypeScript) (2017) https://github.com/caprover/caprover - Komodo (Rust) (2022) https://github.com/moghtech/komodo
In An Update on Heroku
I was also looking at alternatives - K8S-based - https://github.com/cozystack/cozystack https://github.com/kubero-dev/kubero https://github.com/pluralsh/plural DCR-based - https://github.com/coollabsio/coolify https://github.com/dokku/dokku/ https://github.com/Dokploy/dokploy https://github.com/swiftwave-org/swiftwave Most of these projects are maintained by a single maintainer; for business critical apps look elsewhere.
In Coolify: Open-source and self-hostable Heroku / Netlify / Vercel alternative
I don't think that's true. I opened https://github.com/dokku/dokku/issues/5008 a while back and Jose didn't seem to disagree. Addressing your argument directly though: you know that if you spin up a Postgres database for your app, you need to dump the database to disk to back it up (or if you wanna get fancy, you can do a delta from the last backup + a full backup periodically). Anytime a Postgres database exists, you know the steps you need to take to backup that service. Same with persistent file storage on disk: if you have a directory of files, you need a snapshot of all of those files. Each _service_ can know how to back itself up. If you tell a Dokku _app_ to back itself up, what you really mean is that each _service_ attached to that app should do whatever it needs to do to create a backup. Then, dokku only needs to collate all of
Read the rest
the various backup outputs, include a copy of the git repository that drives the app, tar/zstd it, and write it to disk. As you pointed out, the user should probably be able to control the backup cadence, where those backups are shipped off to, the retention period, whether or not they are encrypted, etc, but the actual mechanics of performing a backup aren't exactly rocket science. All of the user configurable values can have reasonable defaults too -- they can/should Just Work (tm). There's value in having that work OOTB even if the backups are just being written to disk on the actual Dokku machine somewhere.
In Show HN: A CLI tool I made to self-host any app with two commands on a VPS
Yeah there are a bunch of selfhostable things: Caprover (https://caprover.com/) Dokku (https://github.com/dokku/dokku) But people still choose Netlify and Vercel for ease of use I think. Maybe we need something that's just Netlify. The closest I've seen to the "right" UX is Ness: https://ness.sh Though of course it's a tui so some people will get turned off of that (especially people who are willing to spend).
In Netlify just sent me a $104k bill for a simple static site
Dokku maintainer here. Dokku is still chugging along, and has 3-4 big releases a year, with patch releases every so often. We also have partial support for Kubernetes and Nomad, and our Kubernetes integration in particular is in use in a variety of Fortune 500 companies. Some folks are interested in Swarm support[1] as well. I also recently released a "pro" version[2] for folks that want/need extra functionality that doesn't quite make sense for the typical "I have a single server and its just me using it" situation All that said, we're here to stay, and I don't think we're losing any steam :) - [1] https://github.com/dokku/dokku/issues/4486 - [2] https://pro.dokku.com/
In Show HN: Coolify v2 – Open-source and self-hostable Heroku/Netlify alternative
One approach that has worked for me so far is: 1) find out if the runtime/framework is supported but Heroku or if there are any buildpacks available. 2) spin up a Dokku instance using Vagrant for local development and testing 3) deploy to a live Dokku server If/when I encounter any issues I add Heroku or Dokku to my search query and 9 times out of 10 I’ll find an answer to my issue. Else I just dig into the Dokku docs and GitHub issues and figure it out. So for instance googling for deploying a Phoenix app with Dokku results in a few hits such as this one [0]. There's also a lovely UI for Dokku being actively developed: Ledokku [1] The only drawback currently is when you want to horizontally scale your deployment. You can use their kubernetes or nomad schedulers but I think those are an overkill in terms of complexity. You could also use
Read the rest
a load balancer in front of multiple Dokku instances but you then lose the ease of deployment, configuration, etc… Which is why I think their docker swarm scheduler [2] will be one of the most important feature they could add. It’s currently on the roadmap but I’m sure with a bit of sponsorship and a few pull/merge requests it will become a reality. [0] https://nithinbekal.com/posts/dokku-phoenix-deploy/ [1] https://github.com/ledokku/ledokku [2] https://github.com/dokku/dokku/projects/1#card-59170273
In How to rapidly improve at any programming language (2016)
I really wish Dokku would embrace docker swarm like caprover. Currently they have a scheduler for kubernetes but the docker swarm scheduler is indefinitely delayed [0]. It’s like the missing piece to making Dokku a real power tool for small teams. Currently, if you want to scale Dokku horizontally and aren’t ready to take the kubernetes plunge, you have to put a load balancer in front of your multiple VMs running Dokku and that comes with it’s own headaches. [0] https://github.com/dokku/dokku/projects/1#card-59170273
In Harbormaster: Anti-Kubernetes for your personal server

Showing the 15 most recent of 122 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.