josegonzalez

Dokku maintainer here.

I'm sure bash will outlast me. I do hope to work on Dokku for another 10/20/40 years, but if there's a better project out there, I'd be happy to help users migrate and bow out of the deployment space.

I maintain Dokku for the folks that don't want to build and maintain a bespoke deployment process around docker, and the k3s implementation uses helm at its core, so users can eject when Dokku has run its course. I think there is value in that - maybe not for everyone, but at least for folks busy with building product on a budget.

That said, I'm happy to see folks continue to build new tools and iterate on ideas in this space. Definitely cool to see how everyone improves on stuff I - and others - been working on for the last two decades.

Dokku maintainer here. Happy to help you debug why this is happening on our discord/slack. Links here: https://dokku.com/docs/getting-started/where-to-get-help/

Dokku Maintainer here:

Dokku supports Kubernetes as a scheduler, utilizing k3s in the background. You don't need to think about Kubernetes other than if you want a custom chart or something on the cluster.

There are also plugins available that allow acl-based access, and Dokku Pro supports keys (and folks have built their own alternatives that do similar).

That said, disco seems neat. Always love seeing tools in the PaaS space :)

For better or worse, folks _really_ like a free UI. Dokku doesn't offer that (Dokku Pro is paid). With AI increasingly making that sort of thing easier to build - and Dokku being very easy to integrate via MCP but also good for building tools on top of - I'm not actually sure how to proceed with Dokku Pro.

Whether it's a worthy mention or not, I'm not sure. I'd like to think its worthy :)

Disclaimer: I am the maintainer.

Single Board Computing.

This plus a block-based editor like editorjs would be a great addition to any custom cms.

I am gonna be that guy and say it would be nice to share the actual code vs using images to display what the code looks like. It's not great for screenreaders and anyone who want to quickly try out the functionality.

There are just a ton of features that evolved separately from the core project. Plugins allow folks to do things in the project that the maintainers didn't envision or have time to maintain - that's actually how the datastores came to be. I think being extensible has made some things more difficult - particularly maintenance of the main project - but also made it have longevity for folks as they can mold the system to work as they'd like (the plethora of community plugins speak to that). It's a bit like how programming languages have modules or packages you can install/import into your app.

The datastore plugins were initially external as there was a ton of movement in maintaining them and it was at a different pace from the main project, though I'm now working on ways to bring them back into the core as they've stabilized quite a bit over the past decade.

Dokku maintainer here.

This is pretty neat. I think using the compose yaml file to document what should be running is pretty powerful at smaller scales (though I'm hesitant to place data in docker volumes as people tend to delete things at will and then are shocked that their data is gone).

I once spoke with the manager of the Compose project and it was news to them that folks used it in production for deploys. The lack of tooling around zero-downtime restarts makes that frustrating, so it's exciting to see projects that introduce that in some fashion.

Cool stuff!

Its not like they change CEOs every year - Tim Cook has been CEO since 2011.

Lots of these companies are YC companies, and they tend to use other YC products. For those that aren't, its easier to just use what other big names are using, and having YC as a backing name is quite useful in that regard.

Dokku Maintainer here.

Would love to hear about what you think is "light" about Dokku if you have some time for feedback.

Regardless, hope you find a tool you're happy with :)

Dokku is multi node. It supports docker-local (single node) and k3s (multi-node) as schedulers, with most features implemented as expected when deploying to k3s.

Dokku maintainer here.

Dokku supports distributed compute via our k3s scheduler plugin. This can setup its own k3s cluster or connect to an existing Kubernetes cluster and deploys helm charts on this clusters for your app.

We have an official action that does exactly what you're asking for.

https://github.com/dokku/github-action

This is great. Dokku (of which I am the maintainer) has a hokey solution for this with our letsencrypt plugin, but thats caused a slew of random issues for users. Nginx sometimes gets "stuck" reloading and then can't find the endpoint for some reason. The fewer moving knobs, the better.

That said, its going to take quite some time for this to land in stable repositories for Ubuntu and Debian, and it doesn't (yet?) have DNS challenge support - meaning no wildcards - so I don't think it'll be useful for Dokku in the short-term at least.

It's multiple host via our k3s integration.

Dokku maintainer here. What about Dokku is not as mature as Coolify? Would love to hear your thoughts on how the project falls flat for your use case.

Dokku uses heroku buildpacks by default and supports cloud native buildpacks by changing the builder to pack via builder:set.

Dokku runs on multiple servers by abstracting other schedulers (kubernetes, nomad). You don't really need to deal with the scheduler side (other than setting it up on the new servers in your cluster, which is a single command we document).

Disclaimer: I am the Dokku maintainer

What a genius the original maintainer of this software is

My understanding is that they are focused on the local development loop at the moment, especially with the acquisition of Tilt. That said, I don't work there so take this all with a grain of salt.

I really hate adding knobs - it increases the amount of work I need to do to maintain and support the project.

Long term, I'd like to port the ansible modules over to being maintained internally by the dokku/omakase project, and then maybe that could be a plugin that folks could run from within their deploy.

Dokku maintainer here.

You may wish to look into a message processing system in your language of choice and run that as a daemon in Dokku. We have plugins for various datastores, and commonly I see folks just connect their worker processes to that. It's much lighter weight than spawning new containers for each workload.

Yep, you can set a single property for the kubeconfig and it'll respect that.

Dokku maintainer here. If you have more detailed feedback, I'd love to hear it! Happy you've found something that works for you though :)

I see compose in production all the time - especially from folks that want compose support _in_ Dokku. I bought this up with the compose project manager a few months back. It seems like an interesting use case but it didn't seem like the Docker folks were... aware that this was how folks used docker compose? There is a project out there - Wowu/docker-rollout - that sort of provides this but it has some rough edges.

Disclaimer: I am the Dokku maintainer.

Dokku's multi-server offering is based on k3s. We interact with k3s but offload any actual clustering to k3s itself as it does the job better than Dokku could :) You can also just tie Dokku into an existing K8s cluster on your favorite cloud provider instead.

Disclaimer: I am the Dokku maintainer.

We've supported multiple servers for a few years and have had official k3s support since the beginning of the year, so not just one server anymore. We even support managing the servers associated in a k3s-based cluster.

Disclaimer: I am the Dokku maintainer.

I love this! Did you add this to our plugins page by any chance? I can't recall and not at my personal laptop to check.

Disclaimer: I am the Dokku maintainer.