[davidsgk]

> Dokku is great, but historically it didn't really handle resilience.

Would you mind elaborating a bit on this? I'm exploring some serverless options right now and this would be useful info. Do you mean it's not really designed out of the box for resilience, or that it fails certain assumptions?

[ffsm8]

I'm not the person you're responding to, but I believe I can answer that question as well.

Dokku essentially just started a container. If your server goes down, so did this container because it's just a single process, basically.

Other PaaS providers usually combine it with some sort of clustering like k3s or docker-swarm, this provides them with fail over and scaling capabilities (which dokku historically lacked). Haven't tried this k3s integration either myself, so can't talk about how it is nowadays.

[mdasen]

Yea, this. Dokku was basically a single-server thing. If that box dies, your site goes down until you launch it on a new box. That might not be a huge deal for smaller sites. If my blog is down for a day, it's not a big deal.

With a cluster, if a server goes down, it can reschedule your apps on one of the other servers in the cluster (assuming that there's RAM/CPU available on another server). If you have a cluster of 3 or 5 boxes, maybe you lose one and your capacity is slightly diminished, but your apps still run. If your database is replicated between servers, another box in the cluster can be promoted to the primary and another box can spin up a new replica instance.

Dokku without a cluster makes deploys easy, but it doesn't help you handle the failure of a box.

[josegonzalez]

Yeah the k3s scheduler is basically "we integrate with k3s or BYO kubernetes and then deploy to that". It was sponsored by a user that was migrating away from Heroku actually. If you've used k3s/k8s, you basically get the same workflow as Dokku has always provided but now with added resilience.

Note: I am the Dokku maintainer.

[davidsgk]

Ah gotcha, thanks for the insight!