Hacker News new | past | comments | ask | show | jobs | submit login

Would be great to see a comparison to some better known alternatives like

- Dokku [0]

- CapRover [1]

[0] https://dokku.com/

[1] https://caprover.com/




It seems similar to https://swarmlet.dev as well (I’m the author). I’ve since abandoned the project for different reasons. Currently I’m using Dokku, and have been using it for ~8 years. It’s a lovely project and pretty mature. I would recommend Dokku to anyone who wants to do (cheap) self-hosting!


Same here: I've been hosting two dozen services on Dokku for a side-project in the past few years and it's been working flawlessly! Dokku and a Hetzner server makes hosting very easy


Same. Dokku has worked seamlessly for me for 6+ years now!


I should add one to https://piku.github.io (spoiler - this doesn't use Docker at all)


Dokku Maintainer here:

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 :)


Thanks! systemd would require more coding, because uwsgi does a lot automatically just by watching file creation/modification…



I've been using coolify for all my apps for like 6 months or so now. I gotta say it's pretty impressive how well it works and the dev is quite responsive. I hope he can make it financially viable for himself.

It's still a little rough around the edges but quickly getting polished up.


I'm a bit down the kubernetes rabbit hole right now so I'm biased. Wouldn't it be better to have these solutions as kubernetes packages so that you could have the best of both worlds - flexibility and plug-and-play-ness?

Honestly I'm probably ending up reinventing the wheel a lot while going with kubernetes (on my personal projects) piecing together a lot of what these tools would give me with minimal configuration. And it feels like a lot of what I'm currently trying to work on in my side project is basically what I would get from these paas solutions but with the benefit of understanding and being able to tweak the various components better.


I had the same conclusion after evaluating those open source PaaS tools.

It just doesn't feel right for me. For small scale apps it's enough to spin up one or two VMs and run some containers with docker-compose (or just use Vercel/etc for a few bucks). But if it should scale, there is no alternative to kubernetes in the open source world.


My hypothesis right now is that if you know Kubernetes there's no "good" reason to not choose Kubernetes even if it's "overkill". You get a lot of flexibility this way but it's potentially a huge upfront cost with many options for shooting yourself in the foot. Understanding how to configure it without getting overwhelmed currently takes a lot of experience.

You can run Kubernetes for cheap on a single node and it seems you can configure it so that you only need to care about the configuration when you need flexibility. I think.

I get a similar feeling to how it was to set up a react project before you had create-react-app like tools. There's a lack of plug and play options that works for most use cases.

Then again I might just be sort of rationalising the amount of time I've spent on it on a personal project that doesn't really require it.


Dokku supports k8s as the "scheduler" (the term is weird...).

You can think of it as a much nicer CLI for k8s in that case. But it scales way down to a single machine deployment that is much simpler.


Dokku author here:

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.


unfortunately, many (like me) don't have time for going down k8s rabbit holes, we just want to get back building features.

push heroku, done, get back to other things.


It would be nice if there were a packaging system (or maybe just a github action?) that got you a k8s with ingress to some pods that were just updated on merge to a main branch.


Yeah, I looked a bit now. It seems there are some serious attempts at this.

Like:

- https://www.cloudfoundry.org/technology/korifi/

- https://kubevela.io/

- https://www.crossplane.io/

Not sure if all of them are relevant and on first glance they all seem significantly harder to pick up than something like Heroku.

Found them through this reddit thread: https://www.reddit.com/r/kubernetes/comments/m8r5py/looking_...


Yes, I'm going down the rabbit hole so that I hopefully don't have to muck around so much down there in the future. I would love to find a k8s configuration that allows me to then focus on the application code. Push code to git and trust that my configuration takes care of the rest.


There's Porter, the "Kubernetes powered PaaS that runs in your own cloud".

https://github.com/porter-dev/porter

and Otomi, "self-hosted DevOps PaaS for Kubernetes"

https://github.com/redkubes/otomi-core


I'v tried these two and must say "it works out of the box" is only true maybe 50% of the time you try to deploy on them


Dokku Maintainer here.

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).


I’ve been using Caprover for years, and haven’t experienced anything like your reported rate of failure.


I can vouch for Dokku being equally very reliable and surprise-free to use.



This seems nice but looks like it's closed source?



Dokku Maintainer here:

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.


Also which ones have native support for background workers and cron jobs.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: