Apollo – An Extensible Docker-Based Platform as a Service (PaaS)(gitlab.com)
gitlab.com
Apollo – An Extensible Docker-Based Platform as a Service (PaaS)
https://gitlab.com/p3r.one/apollo
60 comments
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!
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.
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.
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.
Considering how many choices this guy has made that are identical to mine, trying to build very different applications, I’d say he’s onto something.
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:
https://imgur.com/E8tWj3P
https://imgur.com/E8tWj3P
Lots of things you use are probably single-person maintained ;)
What are other docker/k8s based PaaS you've tried?
What about Google App Engine Flex, Google Cloud Run and Amazon Fargate?
In my company we have been using App Engine Flex in production successfully for a few years already.
In my company we have been using App Engine Flex in production successfully for a few years already.
Disclaimer: I work on Cloud Run.
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.
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.
This looks incredible! Has some serious offerings against the current Self-Hosted PaaS scene, hope I can check it out over the weekend.
I have used Dokku[0] in production, and played with CapRover[1] on hobby projects. Flynn was like a better Dokku, before development died.[2]
CapRover is a great experience, and it's not a toy IMO. It nails the role of "I want to press a button and have a self-hosted Heroku, with a nice dashboard, auto-provisioned HTTPS domains, and be able to deploy a bunch of Docker images or Buildpack apps." A single-node $10 box can run a good number of services.
This looks well-positioned and closer to something like Nomad, but going through the readme I had a few questions:
And final question (sorry if this is dumb):
[0] https://github.com/dokku/dokku
[1] https://github.com/caprover/caprover
[2] https://github.com/flynn/flynn
I have used Dokku[0] in production, and played with CapRover[1] on hobby projects. Flynn was like a better Dokku, before development died.[2]
CapRover is a great experience, and it's not a toy IMO. It nails the role of "I want to press a button and have a self-hosted Heroku, with a nice dashboard, auto-provisioned HTTPS domains, and be able to deploy a bunch of Docker images or Buildpack apps." A single-node $10 box can run a good number of services.
This looks well-positioned and closer to something like Nomad, but going through the readme I had a few questions:
"Apollo requires a manager- or control-node. We call this manager-0. This node runs the entire controlplane and monitoring stack for a cluster and should be sized appropriately (8GB Memory, 2-4 vCPUs)."
"Your space has been created. Now let's cd to its directory: cd $HOME/.apollo/.spaces/demo-1.space"
And final question (sorry if this is dumb):
Automated infrastructure (currently only DigitalOcean and HETZNER Cloud supported)
[0] https://github.com/dokku/dokku
[1] https://github.com/caprover/caprover
[2] https://github.com/flynn/flynn
Hey,
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 :)
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 :)
Thank you, that does answer everything! I also see now after going through the readme again "Single-node clusters are possible and can be scaled up", so apologies for that question.
Dokku user and now CapRover user. I have to say it's my favorite for spinning up a new project. I don't know if I'd use CapRover for anything production just yet but I love it for development. For me it's the perfect "stick this server, client, DB combo on a server, add HTTPS, and don't make me think about it".
I feel confident that anything I throw on CapRover I could move to "more production-level" setup easily if I wanted; using managed db's, containers, block storage etc on AWS/Google/etc. Like, if I can get it working in CapRover I know I can run it anywhere and CapRover makes it super easy to get my idea hosted and running "in the cloud" quickly. I don't know why but seeing my project run full-time, verses just when I'm developing locally, is a huge motivator for me so CapRover is perfect for me in the same way I use Caddy for my local services. I want fast, safe, and easy with the knowledge I can scale up with some work in the future but I don't need it for day 1.
I feel confident that anything I throw on CapRover I could move to "more production-level" setup easily if I wanted; using managed db's, containers, block storage etc on AWS/Google/etc. Like, if I can get it working in CapRover I know I can run it anywhere and CapRover makes it super easy to get my idea hosted and running "in the cloud" quickly. I don't know why but seeing my project run full-time, verses just when I'm developing locally, is a huge motivator for me so CapRover is perfect for me in the same way I use Caddy for my local services. I want fast, safe, and easy with the knowledge I can scale up with some work in the future but I don't need it for day 1.
Agreed with all of this. The other option I would mention, although it has a wonky pricing structure is Cloudron [1].
I use CapRover on a spare droplet and it’s a really good solution. This looks like a compelling option too.
[1]: https://www.cloudron.io/
I use CapRover on a spare droplet and it’s a really good solution. This looks like a compelling option too.
[1]: https://www.cloudron.io/
Author of apollo here. Using multiple Cloudron instances for production stuff and am still heavily inspired by the operational stability and ease of app-onboarding the Cloudron team has managed to maintain. apollo strives to deliver a Cloudron-like experience (in terms of stability) over time.
This is awesome to here! I’m really looking forward to testing Apollo out!
How would you compare Caprover to Dokku? I use dokku a lot, and really love some of the plugins (like postgres with the automatic backups and such).
Is there any reason why you wouldn't use Caprover in production? (other than you haven't needed to)
Is there any reason why you wouldn't use Caprover in production? (other than you haven't needed to)
I was kind of forced into using Dokku in production. I inherited a 4-year old Rails codebase previously running on AWS EC2 and that was how the infra was set up.
But given the timeline, I think it was probably the best available option at the time. Flynn, CapRover, etc weren't really a thing, so Dokku was innovative in this space.
I would say that there's absolutely nothing wrong with Dokku, but experience-wise CapRover is miles ahead.
> Is there any reason why you wouldn't use Caprover in production? (other than you haven't needed to)
If you use the Docker Swarm setup multi-node, I feel like it's a solid choice for a small company. If you get big/complex enough, you'll probably eventually wind up needing k8s/Nomad but as far as tradeoffs for development velocity vs stability, I feel good with CapRover.
Going to try Apollo out soon though. It appears to address things like multiple environments better than CapRover. And as mentioned, the docker-compose.yaml integration is a huge one for me.
But given the timeline, I think it was probably the best available option at the time. Flynn, CapRover, etc weren't really a thing, so Dokku was innovative in this space.
I would say that there's absolutely nothing wrong with Dokku, but experience-wise CapRover is miles ahead.
> Is there any reason why you wouldn't use Caprover in production? (other than you haven't needed to)
If you use the Docker Swarm setup multi-node, I feel like it's a solid choice for a small company. If you get big/complex enough, you'll probably eventually wind up needing k8s/Nomad but as far as tradeoffs for development velocity vs stability, I feel good with CapRover.
Going to try Apollo out soon though. It appears to address things like multiple environments better than CapRover. And as mentioned, the docker-compose.yaml integration is a huge one for me.
Name is a little similar to https://www.apollographql.com/
Not sure which is more overloaded: "apollo" or "spark".
Yeah sorry for naming. Did 0 research upfront. My dog is named "Apollo, I'm a not-so-creative guy, things just evolved and now here we are!
Also: https://github.com/ApolloAuto/apollo
It’s a contested open source project name, for sure.
It’s a contested open source project name, for sure.
And let’s not forget the well-liked iOS Reddit client as well.
Or the Greek god
Or the moon missions.
Or Counter Culture’s Light Roast beans.
Basically the name is a bit tired and few actually have a reason to call it that. (Apollo the Reddit client to browse the world of Reddit which has an alien as it’s avatar almost makes sense.)
Or the Greek god
Or the moon missions.
Or Counter Culture’s Light Roast beans.
Basically the name is a bit tired and few actually have a reason to call it that. (Apollo the Reddit client to browse the world of Reddit which has an alien as it’s avatar almost makes sense.)
Amazon engineers will also recognize Apollo as something else
https://www.allthingsdistributed.com/2014/11/apollo-amazon-d...
https://www.allthingsdistributed.com/2014/11/apollo-amazon-d...
As will old NASA astronauts.
or the premium workstation of the 80s.
Or the publicly traded private equity / credit investor?
Or the parent company of University of Phoenix Online?
PS the private equity firm actually owns the education company since 2016... think about that confusion
Or the parent company of University of Phoenix Online?
PS the private equity firm actually owns the education company since 2016... think about that confusion
Or Adama from BSG?
Or the short track olympic skater from US?
Or Apollo.io for structured sales data?
Or are we talking about Adaptive Patient-Oriented Longitudinal Learning and Optimization?
Or the short track olympic skater from US?
Or Apollo.io for structured sales data?
Or are we talking about Adaptive Patient-Oriented Longitudinal Learning and Optimization?
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.
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.
- 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!
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.
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 :)
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 :)
This seems very similar in concept to https://caprover.com/
Looks like the main difference is docker compose compatibility but admittedly I have more reading to do. Still tho that is a good difference! I have multiple caprover nodes in prod for hobby stuff so absolutely not knocking it.
author of apollo here.
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.
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.
CapRover does support docker-compose. Maybe not as streamlined as some other platforms but you can use it.
https://caprover.com/docs/docker-compose.html
I know the docs make it look like it does, but it doesn't really.
What it actually supports is copy + pasting sections of Docker Compose for prebuilt images.
So let's say you have a docker-compose.yaml where one of your services uses "build"/"context" and points to a local Dockerfile. You cannot deploy this to CapRover (in this way, through docker-compose.yaml).
The docker-compose support is more geared towards the "one-click" apps they have when you want to deploy something like pgAdmin or MySQL which uses a prebuilt image.
Because of this, it means you can't really deploy your existing setup. From the instructions:
The "Alternative Approach" is to connect to your instance and upload the source + manually run "docker-compose up" with it wired to the overlay network. This is not a good or scalable solution IMO.
What it actually supports is copy + pasting sections of Docker Compose for prebuilt images.
So let's say you have a docker-compose.yaml where one of your services uses "build"/"context" and points to a local Dockerfile. You cannot deploy this to CapRover (in this way, through docker-compose.yaml).
The docker-compose support is more geared towards the "one-click" apps they have when you want to deploy something like pgAdmin or MySQL which uses a prebuilt image.
Because of this, it means you can't really deploy your existing setup. From the instructions:
1. Navigate to Apps
2. Click on "One Click Apps/Databases"
3. Navigate to the very bottom of the list, and click on the last item, called >> TEMPLATE <<
The "Alternative Approach" is to connect to your instance and upload the source + manually run "docker-compose up" with it wired to the overlay network. This is not a good or scalable solution IMO.
Yeah that seems like the main difference. Like you, I use CapRover for hobby stuff and love it.
But Docker compose could make this really compelling too.
But Docker compose could make this really compelling too.
Docker Compose compatibility is major. I just want a seamless Heroku like experience but with Docker Compose. Is that too much to ask?
Making this all the more confusing, the deployment tool most used inside Amazon is an internal tool called "Apollo". (We mostly hate it.)
I checked - the primary author of this tool has never worked there.
I checked - the primary author of this tool has never worked there.
It's painful. Many a day I thought of purchasing a box of oranges to pelt at the moon. In futility? Yes. Just like Apollo.
Our team awaited the promised tangerines with hope. And yet they never arrived.
Our team awaited the promised tangerines with hope. And yet they never arrived.
I've been wanting to build something like this for a long time, very neat. I haven't had a chance to use it yet but looking through the readme this is a very comprehensive project.
Thanks for the kind words. Hopefully you'll find the time to verify if it would fit your needs!
For Hobby projects I'm loving Lambda proxy from AWS Labs. I'm able to use native Golang frameworks like gin/echo without changing anything much and deploying to Lambda + API gateway. This runs for basically free, and is easy to port out.
Is this solving the same problem as CloudFoundary for K8s? https://github.com/cloudfoundry/cf-for-k8s
Is this the first self-hosted PaaS solution also running on Kubernetes? As far as I know neither Dokku nor CapRover do, which always deterred me from these applicationsas I'm running K3s at home.
Dokku can run against a Kubernetes cluster: https://github.com/dokku/dokku-scheduler-kubernetes
I assumed that Knative [1] is the canonical self-hosted PaaS for Kubernetes. It is branded as Cloud Run [2] by Google. I'm not sure how it compares feature-by-feature with Dokku nor a 12-Factor App PaaS like Heroku.
[1] https://cloud.google.com/knative
[2] https://cloud.google.com/run
[1] https://cloud.google.com/knative
[2] https://cloud.google.com/run
This is pedantic, but Knative and Cloud Run aren't quite the same thing.
Knative is the "serverless" (bit a weird term in this context) eventing/serving framework, and Cloud Run is a managed Knative service.
You can self-host/install Knative to your k8s cluster and the experience you end up with is pretty PaaS-ey.
Less known is this space is Rio by Rancher Labs, which is also great + similar:
https://rio.io/
Knative is the "serverless" (bit a weird term in this context) eventing/serving framework, and Cloud Run is a managed Knative service.
You can self-host/install Knative to your k8s cluster and the experience you end up with is pretty PaaS-ey.
Less known is this space is Rio by Rancher Labs, which is also great + similar:
https://rio.io/
Isn't Knative for functions & serverless only? That's not my main scenario at home.
If Knative is more self-hosted FaaS than PaaS, that explains the core use case for Apollo; a traditional 12-Factor App PaaS for Kubernetes/Docker-Swarm. Knative supports a Serving Spec for routing (like AWS API Gateway) but doesn't seem to have buildpacks for 12-Factor App frameworks, as far as I can see.
Apex Up [1] deploys web apps on top of AWS Lambda using Amazon's API Gateway as the RESTful routing proxy. Maybe something like Apex Up is required to transform Knative into a PaaS for historical 12-Factor App frameworks. ZEIT Now 2.0 did the same thing for Serverless (Cloudflare Workers only?) but the company has been renamed Vercel and has pivoted around Next.js.
[1] https://github.com/apex/up
Apex Up [1] deploys web apps on top of AWS Lambda using Amazon's API Gateway as the RESTful routing proxy. Maybe something like Apex Up is required to transform Knative into a PaaS for historical 12-Factor App frameworks. ZEIT Now 2.0 did the same thing for Serverless (Cloudflare Workers only?) but the company has been renamed Vercel and has pivoted around Next.js.
[1] https://github.com/apex/up
AWS now also provides native support for deploying 'regular' web apps using lambda + API gateway. I've been using this for my hobby projects - https://github.com/awslabs/aws-lambda-go-api-proxy
CapRover uses Docker Swarm internally, even if you're only running one node, which really sucks because it invokes the docker userspace proxy, killing the L3 source IP for connections in to your containers.
This looks a bit like portainer https://github.com/portainer/portainer
Looks a tiny bit like: https://github.com/capgemini/apollo
Never heard of that software but yeah, seems apollo is a good name for all things infrastructure and platform :D
can similar run in digital ocean? Or is Docker image be published in a DO droplet and update or overwrite remotely to minimise hacking risk.