Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

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

apollo is being developed and professionally supported by my company and runs in production for many of our customers (ranging from single-node spaces to 5+ node Webhosting clusters, mostly Docker Swarm, a few on k3s).

While I put a lot of my personal wishes for "good IT systems" into apollo, it has originally been built as an open platform (open as in "no vendor lock-in, no custom tooling we can't leave behind later, industry-standard, best-practice, easy to grasp, don't stand in the way, integrate with everything") for a customer that decided to let my company open-source the product afterwards and build a team around ongoing development. Which we have done and it's a self-sustaining business since day 1.

What I try to say here is: we are a serious company, building this for other serious people with a similar understanding of "open" to use. It's also explicitly built to be customized to anyone's needs. We're betting on the software. Our clients can bet on us.

I understand that it might not be a popular choice on the market, it might not even become one. But it's free for everyone to build something with it, no questions asked. I guess that's at least something!

author of apollo here. Thanks for the feedback and questions, I'll try my best to shed a little light here.

- Yes, you can run apollo even on nodes with only 512MB RAM and 1 core. There's no programmatically imposed limit - it's just an advice to bring beefy infrastructure to production setups as metric-collection/logging consumes quite a lot of memory. You can just use apollo with a 2GB HETZNER node (2,98€/m) and you're good to go. Additionally, you can switch of metrics, logs and analytics in your Spacefile.yml - these are the main memory-hogs. Without them, you still have a nice docker swarm or k3s.

- apollo spaces are totally meant to be checked into version control for collaboration and CI/CD. Once created, just enter you space directory and hook it up to any git-repo like you would to with any other code (`git init` etc). We're planning to implement this workflow into the CLI for 2.1.0 to improve UX, but basically apollo config lives in a directory which you can do with as you please in terms of git.

- The infrastructure templates aren't required. As my company is not using other providers than hcloud/digitalocean, we have no ready-made templates for them. But you can provide your own Terraform code to spin up infrastructure. You only need to work in the `output.tf` code that saves a special formatted Nodesfile.yml as an artifact of your TF code. Additionally, you can of course write up your Nodesfile.yml manually.

Hope this helps :)

I think conceptually apollo and cap rover are pretty similar in that both try to deliver some degree of abstraction to the developer when it comes to application deployments.

Where I see a great difference is that apollo doesn't imply a special deployment or release workflow. You just use plain docker tooling (or helm for k8s). We also don't provide DBs or other platform-services. With apollo, you're required to take care of your stack's needs (if you need a database, create a service in compose and add a volume).

apollo's focus is on stable day-2-operations and giving great insights to what's under the hood (like direct access to metrics and central logs). We also don't invest time in writing custom code for web-interfaces and alike. apollo includes portainer (or rancher on k3s) which you can use to manage your containers; and grafana for analytics.

Another thing we focus on is to simply support industry-standard tooling and workflows (apollo can has a CI/CD workflow based on SemVer you can use to continuously validate and deploy your clusters) - we want to avoid vendor-lock-in as much as possible.

apollo is meant to be used in production and can replace the need for a full-blown DevOps team if used correctly. Not sure if Caprover does that.