Dokku supports a variety of proxy implementations - nginx on the host, caddy/haproxy/openresty/traefik from within containers. The latter are managed via compose files, and can be customized to not listen on the host if you _really_ wanted to (and then proxied to from whatever your actual host system is).
While we optimize for the 90% case, I'd definitely be interested in learning more about your needs to see if we can maybe get closer to what you're looking for. On the nginx side, the port mappings are such that port 80 is used by default, but you could swap it to be something else (and also listen on localhost) and then proxy to nginx from your proxy of choice, allowing you to take advantage of Dokku while using whatever you currently use.
Piku is awesome! I've always thought the PaaS space is wide enough for many players in specific niches, and I love the approach of running processes outside of containers. About the only thing I would change is to utilize systemd (or similar) for spawning processes, but otherwise it's super neat. I've used it myself on a raspberry pi zero :)
Hatchbox is pretty cool, but not OSS - also doesn't use Docker IIRC if thats something you were looking for.
There's certainly something to be said about managed services though. For folks that don't mind managing their infra, OSS systems allow customizations and extensions that you wouldn't see from a managed service, but you potentially trade that for reliability guarantees and general maintenance. With Dokku for instance, I see folks go quite a while without upgrading - potentially causing issues when they do, but mostly making it so they miss out on features and bug fixes. For managed services like Hatchbox, you get that for free, but then the system might change underneath at a cadence you're unhappy with.
I think myself - and folks maintaining other open source projects! - would love to hear feedback about what works/what doesn't. Feel free to reach via email (its in my profile) if you want, or our Discord/Slack.
I typically see users struggle with an initial deploy because their app depends on some variable or service running and that wasn't taken into account. This is pretty much the same as for general CI, where one might go through several commits before CI is running as you expect.
Very unfortunately, detecting these pain points requires work from both platform maintainers _as well as_ framework owners. The reason rails apps deployed so nicely across PaaS services in the past is because the Rails developers spent a ton of time ensuring applications _could_ do 12 Factor, while most PaaS services spent a ton of time working towards those constraints. Consequently, deploying other services that don't conform to this standard is a bit more difficult (though usually still possible).
The "scheduler" term here _is_ a bit weird, but I couldn't figure a better term when I was abstracting the concept.
And yeah, the idea here is that the underlying scheduling system shouldn't matter too much to the user of Dokku, but rather that you get the same experience regardless of the scheduling system. That means that as a user, `dokku enter` (for entering a running container) should be the same if its on Docker Local, Kubernetes, or Nomad. Similarly, Dokku should abstract what it means to deploy a workload onto a system - for Kubernetes, we use Helm charts, but the user doesn't need to know about how helm charts work or anything like that.
We've traditionally focused on getting that single-server experience to a high quality, but now that the base is more or less complete, we can start looking at other integrations that help our users scale.
At least to me, both of those imply a key-value storage system, not a secrets manager. `OpenSecrets` maybe implies less security to some, and developers tend to want to give products they work on a creative name.
Dokku itself doesn't run anything in resident (there is a small go binary that listens to the docker event stream and restarts apps as necessary but thats it), so there shouldn't be overhead there.
On the Docker side, there is a _slight_ amount of overhead in cpu/networking, but its so negligible that its sometimes difficult to benchmark. While I can't really make changes to Docker to alleviate issues, I'd be interested in knowing what parts of Docker are heavyweight so we can better surface any such information to Dokku users.
Admittedly I only looked through this briefly but:
- I don't see too much in the way of documentation, so I can't compare that to Dokku's
- Not super clear how cluster management works - Kubernetes based on some of the api responses - but it appears to take a cluster-first approach here. Dokku has cluster support via it's k3s scheduler but thats something you need to configure (not hard, just not default).
- Neither the OSS nor Dokku Pro offering stand up actual servers (thats up to you to do), while this appears to interact with actual cloud providers?
- It's not clear if this is an open source project - seems like a completely managed offering - but doesn't seem to be. If it isn't OSS, then you can't install it on your server, which may or may not be important to you.
- Dokku doesn't provide anything out of the box for cloud storage. You can configure a minio app, but thats about the long and short of it.
- Dokku is plugin-based, so we offer plugins for the major datastores and other functionality, while this seems to be more of a catered experience.
- Dokku only has an official UI via Dokku Pro (there are community offerings as well but I can't speak to those) while Hoy has that built in (presumably because it's a paid service).
- It's not clear how hoy does app building (or if it depends on your CI to do that). Dokku provides a few different ways to build/deploy applications (Heroku Buildpacks, CNB, Nixpacks, AWS Lambda functions, Dockerfile, images).
Seems neat - I like the live demo, and others definitely will too! - but not sure if comparing this to OSS offerings makes sense to be honest. It's probably closer to any of the other paid, managed solutions that allow you to provision clusters to various clouds (on the cloud managed version or otherwise).
Just a note: Dokku has alternative scheduler plugins, the newest of which wraps k3s to give you the same experience you’ve always had with Dokku but across multiple servers.
Dokku supports a variety of proxy implementations - nginx on the host, caddy/haproxy/openresty/traefik from within containers. The latter are managed via compose files, and can be customized to not listen on the host if you _really_ wanted to (and then proxied to from whatever your actual host system is).
While we optimize for the 90% case, I'd definitely be interested in learning more about your needs to see if we can maybe get closer to what you're looking for. On the nginx side, the port mappings are such that port 80 is used by default, but you could swap it to be something else (and also listen on localhost) and then proxy to nginx from your proxy of choice, allowing you to take advantage of Dokku while using whatever you currently use.
Feel free to hit us up via Discord/Slack.