Despite the nice packaging, it appears to be a single-person maintained project. There are quite a few reasons why no opinionated PaaS built on Docker Swarm or Kubernetes (maybe surprisingly) came even close to being a popular choice in the market. Usually, anyone serious who's going to bet on a PaaS that runs their stack will also need a serious corporate entity (i.e. software vendor) supporting the tools in case things go wrong. Similarly, often many serious companies are better own building their own PaaS on top of these platforms as they realize sooner or later, they want a lot of customization and control over the platform. So far I'm adding this to the pile of people who’ve tried to build a PaaS on top of docker/k8s. I'm not seeing a lot of features to make it stand out, what I'm seeing in the features section is more of an opinionated stack.
I remember first time seeing Elastic Search around 2012. Shay Banon was the sole commiter for over two years at the time. Never underestimate determined founders.
While you're right that I am the main maintainer of this project, you might underestimate its traction.
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!
Your competing product's org has a bad track record here of canceling new tools, so from that perspective, the small, neutral, and fully open solution seems safer choice given the two. I'd reconsider barking up this tree.
More objectively: It's new, production architects of "serious" code shouldn't depend on either. However, one of them represents a lot of "boring" stacks, so if a team is comfortable forking vs NIH'ing, this may be closer to "serious" production-worthy.
The idea is pretty cool IMO - we were looking at Replicated years ago, and if they had gone open like this, we would have considered them more seriously.
The fact that it works with an existing docker-compose.yaml and will provision itself on a cloud for you is pretty compelling I think.
I have tried the Docker AWS ECS plugin for deploying your compose stack, and it's buggy.
The AWS ECS CLI would deploy docker-compose files in V1. V2 (now called Copilot) has shifted away from this, and it uses a custom manifest YAML file. Copilot isn't bad.
Most of the platforms I work on have a docker-compose stack with Postgres, a backend API, a frontend, and potentially ancillary services. Anything that integrates well with this is a godsend tbh, because otherwise you need to maintain two sets of configuration and keep them in sync.
It definitely is a single person maintained project (he's responsible for 99% of the code churn)...not that there is anything wrong with that. Here's a breakdown of his contributions:
In my comment I was referring to open source PaaS projects building on Kubernetes/Docker. Those are managed services where you aren’t exposed to the underlying infra (to varying degrees). So they aren’t apples to apples with this project.
