Comment by throwaway77384 | Hacker News Reader

Comment by throwaway77384 | Hacker News Reader

How does this compare to Dokku?

Been using Dokku for a year now, and it is quite a joy.

Admittedly, I'm not in the 1000s of requests per second space that many other people operate in (I'm in the internet equivalent of the Mom & Pop website hoster space). I've found Dokku does everything Heroku does, but I get to control it all, which is really nice.

Never tried Caprover or the other container solutions, because I'm not big enough to even exceed single-instance sizes at Hetzner.

My main worries nowadays are:

- What if popularity shot up? How far does my solution scale?

- Hackerzzz. Who is out there just trying to damage something. Not sure it's as bad as the media will have you believe it is, but I still want some relatively strong opsec.

- Disaster recovery. I want to control as much of my stack as possible, so I can fix things when they go wrong, but I just can't seem to shake that eternal worry of 'what have I missed?' in the production DB

I find it quite hard to strike a balance between over engineering things (boy do I wish I had a load balancer that automatically detected an issue with a node somewhere and then did some sort of seamless failover without losing whatever transaction was in progress at the time lol) and just trusting that the thing will work when it has to.

The promise of platforms like Heroku is undeniably less hassle, or a worry-free life, but I don't know whether black-box models can ever truly provide that.

I've been using Dokku for years, and I have only positive words for it. Here is my experience regarding your questions:

- Scaling: Dokku can scale your application (via "dokku ps:scale" command) on the same machine. If you are concerned with spikes, put Cloudflare (free tier) in front, it will solve most of the problems.

- Hacking: Dokku will expose Nginx and proxy requests to your application from the public. Assuming the rest of the system is behind firewall (eg. iptables with exposed only ssh/https/http ports) and the system is regularly updated, maybe the only critical part is how your application is secure (eg. XSS or SQL injection attacks). If you are using a sound framework and don't abuse it too much, things should be sufficient. Again, if you are behind Cloudflare, it can help a bit here.

- Recovery: All your code is on git and you can easily replicate it on the new Dokku instance. If you happen to use a database as storage, frequent database dumps are advised (eg. daily cron job that will send dumps to Hetzner backup storage).

- Load balancing: Because Dokku is using Nginx in front of your application, starting two (or more) application instances ("ps:scale") will be good enough. Notice however that this will be done on one machine only. If you want to spread it over 2 machines for example, install Dokku on both, git deploy on both (make or shell script will help) and put Cloudflare load balancer in front of it ($5/mo for two origins). Or you can use DNS instead; look for DNS load balancing.

This is extremely useful information, thank you very much. You have helped me feel more confident about my setup.

Cloudflare free in front: Check

Regularly updated system behind firewall, sound framework: Check

Regular cron-job DB-dumps + daily Hetzner backup + code etc on git: Check

Load balancing: This is a new one to me. Excellent! I had wondered about how to do some kind of two-machine load-balancing and eventually, failover. Still finding it tricky to wrap my head around how I'll keep my DB consistent between the two systems, etc, but so far I'm nowhere near the size where this is needed from a performance perspective. This is about redundancy only, so far.

Very helpful, thank you!

Hey,

author of apollo here.

Unfortunately I've never used Dokku or Heroku myself, but from what I know of them, apollo is different in that it doesn't provide any platform services developers can consume (like DBs, Caches, S3, ...). apollo is explicitly made for production use which is why the focus is on operations and infrastructure and we leave the tooling in the hands of the developer (hence we support native docker-compose/docker stack deployments without custom logic).

It's a very DevOps-y platform that can grow with your needs and supplies a good toolchain that helps with operations. Focus is clearly not on "abstracting as much as possible away from the end-user" but more on "trusting that the thing will work when it has to".

Besides, apollo is a great platform to build upon that you can simply leave without reinventing the wheel. Since you don't need special manifests to deploy but build with standard "docker" components like stacks and services, you can deploy your stuff elsewhere in a minute and don't risk vendor-lock in.

Ah, thank you for the additional info.

For the time being I am probably not doing anything complex enough to warrant switching away from Dokku.

As a single-person operation, I have to keep a pretty fragile balance between effort-of-setup (I can deal with a bit more effort than Heroku) / control-over-setup (I need Dokku's finer-grained control, with more effort).

One day I may outgrow those requirements, however. Who knows. I will keep Apollo in mind for that :)

Reply on news.ycombinator.com