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.
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 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:
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 <<
^^ Because this is happening on your serverside instance, in a web app, it has no context for local files.
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.
Comments
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.
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:
^^ Because this is happening on your serverside instance, in a web app, it has no context for local files.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.
Docker Compose compatibility is major. I just want a seamless Heroku like experience but with Docker Compose. Is that too much to ask?