5 ms·

It's funny how people are different, after using CapRover for years I tried Coolify but it felt like so much functionality was missing that I would not use it o

by zapt02 4y ago

It's funny how people are different, after using CapRover for years I tried Coolify but it felt like so much functionality was missing that I would not use it over CapRover in its current state. All the things you mentioned (GitHub webhooks, custom domains, SSL certs, reverse proxying) are supported by Cap. It also supports Docker Swarm.

satvikpendem 4y ago
When I looked at CapRover recently, the GitHub integration in the docs required manually setting up a GitHub Actions integration and I couldn't exactly figure out what parts I needed to change since the example was for a NodeJS app, and I'm assuming it needed to be added or changed for each repo you want to track git pushes from. In contrast, with Coolify, you simply login with your GitHub account and it installs a (one-time setup) GitHub app onto your account that automatically sets up the webhooks and I didn't need to do any configuration after that, it just worked for all subsequent apps. That level of ease of use is the experience I had with Heroku and I do not understand why more self-hosted PaaS don't seem to replicate that as well. Also I like the Coolify GUI over the CapRover one, dark mode plus modern non-Bootstrap design is nice.
- zapt02 4y ago
  There are a bunch of ways to deploy via GitHub, I would check out this action, it's the easiest and most straightforward. There should be no need to adapt it based on different frameworks: https://github.com/marketplace/actions/caprover-deploy https://github.com/marketplace/actions/caprover-deploy You can also use the built-in webhook from inside CapRover control panel but it requires you to log in via your GitHub account in Cap (I created a secondary CI account for this). Installing a GitHub app comes with challenges, it basically gives Coolify access to your account should they want it, since they control the app and not you. This is bad from a privacy perspective. CapRover has dark mode. :-) But yes the design is more utilitarian in Cap and not as nice to look at.
  - Aeolun 4y ago
    > Installing a GitHub app comes with challenges, it basically gives Coolify access to your account should they want it Depending on the permissions they ask for, this may be limited to modifying webhooks in the repositories you specify.
    - zapt02 4y ago
      It will be at least full repo download access, because how else would Coolify download the repository?
      - satvikpendem 4y ago
        That's fine by me, because I want it to clone, build, and run my apps anyway.
- archeroe 4y ago
  Why would someone care about the look of a GUI dashboard for a PAAS and somehow base his choice on that ? Bootstrap, MUI, made by a designer, why should I care when there are dozens of more important points ? And UX wise both have done a pretty good job at being plenty sufficient.
conradfr 4y ago
I use CapRover and my main criticism is the non-zero downtime deployment. Also when I update docker some apps don't restart properly, but that may just be my (basic Ubuntu dedicated) server though.
- zapt02 4y ago
  Non-zero downtime deployment is supported for apps without mounted volumes: https://github.com/caprover/caprover/issues/661#issuecomment-619548552 https://github.com/caprover/caprover/issues/661#issuecomment... Tangentially I was looking at Render.com the other day and they also don't support zero downtime deployments if you have a mounted volume, so it's not very uncommon even on cloud platforms. As for restarts, I didn't have that problem yet, I believe CapRover adds `restart: always` to all the running containers so they should automatically boot. You might want to check out the logs of the containers that don't restart or just always hard restart the server after a Docker update.
  - conradfr 4y ago
    I guess most of my apps have persistent data.
    - smt88 4y ago
      Every useful app has persistent data. It sounds like you have a design problem, though. If you're treating application servers like cattle, then none of them should have persistent data (except caching that's disposable). There are fire-drill days that require deployments, so downtime incurred when updating your application code is unacceptable. To solve this, put your persistent data on a separate server and store it in a proper database (Postgres, for example). Postgres never needs emergency updates, so the downtime for those (infrequent) updates can be pushed to non-peak hours.
      - conradfr 4y ago
        I would maybe do all that if it was for more than side-projects that can tolerate 5-10 seconds of downtime when deployed :)
andrasbacsai 4y ago
Hey, the founder of Coolify here. I'm constantly adding new features to Coolify. Which ones are you missing (except Docker Swarm)?
- zapt02 4y ago
  CapRover has a huge collection of "One Click Apps" that will deploy hundreds of fully functioning applications for you including dependencies (so for example for WordPress it will spin up both a web and a database container): https://caprover.com/docs/one-click-apps.html https://caprover.com/docs/one-click-apps.html Also I think the way you create different kinds of resources are confusing in Coolify, like what is a "Git Source" or "Destination", all I want is to run my container. It's very different from Herokus/Caps interface and not in a good way. Also why can't I just deploy from an image? In CapRover I often spin up a container, like `redis-commander` or `wordpress` and then just configure its env vars and volume mounts. In Coolify it seems you have to connect a GitHub repo which is not a desirable workflow for me.
  - andrasbacsai 4y ago
    I saw CapRover's one-click-apps and I'm thinking of using a similar solution in case of Coolify. Resources are defined in this way, because you can connect a lot of things to Coolify, GitHub, GitLab, hosted or self-hosted, later on Gitea and other git sources, and also different destinations, local docker engine, remote docker engine and later on Kubernetes. I will improve the onboarding experience to not feel the first use as a burden. :) Git based deployment is only required, if you would like to deploy a custom thing, that is currently not supported by Coolify. I'm working on a solution where you can use Docker Hub to deploy images (https://feedback.coolify.io/posts/6/deploy-from-docker-hub https://feedback.coolify.io/posts/6/deploy-from-docker-hub).
- Aeolun 4y ago
  The one thing I’m missing in Caprover, and that would make me switch instantly, is I want to be able to feed it a docker-compose file to run a whole stack. Now if a service has only a docker-compose file I have to pull it apart and start every service individually.

by zapt02 4y ago

satvikpendem 4y ago

When I looked at CapRover recently, the GitHub integration in the docs required manually setting up a GitHub Actions integration and I couldn't exactly figure out what parts I needed to change since the example was for a NodeJS app, and I'm assuming it needed to be added or changed for each repo you want to track git pushes from. In contrast, with Coolify, you simply login with your GitHub account and it installs a (one-time setup) GitHub app onto your account that automatically sets up the webhooks and I didn't need to do any configuration after that, it just worked for all subsequent apps. That level of ease of use is the experience I had with Heroku and I do not understand why more self-hosted PaaS don't seem to replicate that as well. Also I like the Coolify GUI over the CapRover one, dark mode plus modern non-Bootstrap design is nice.

zapt02 4y ago
There are a bunch of ways to deploy via GitHub, I would check out this action, it's the easiest and most straightforward. There should be no need to adapt it based on different frameworks: https://github.com/marketplace/actions/caprover-deploy https://github.com/marketplace/actions/caprover-deploy You can also use the built-in webhook from inside CapRover control panel but it requires you to log in via your GitHub account in Cap (I created a secondary CI account for this). Installing a GitHub app comes with challenges, it basically gives Coolify access to your account should they want it, since they control the app and not you. This is bad from a privacy perspective. CapRover has dark mode. :-) But yes the design is more utilitarian in Cap and not as nice to look at.
- Aeolun 4y ago
  > Installing a GitHub app comes with challenges, it basically gives Coolify access to your account should they want it Depending on the permissions they ask for, this may be limited to modifying webhooks in the repositories you specify.
  - zapt02 4y ago
    It will be at least full repo download access, because how else would Coolify download the repository?
    - satvikpendem 4y ago
      That's fine by me, because I want it to clone, build, and run my apps anyway.
archeroe 4y ago
Why would someone care about the look of a GUI dashboard for a PAAS and somehow base his choice on that ? Bootstrap, MUI, made by a designer, why should I care when there are dozens of more important points ? And UX wise both have done a pretty good job at being plenty sufficient.

conradfr 4y ago

I use CapRover and my main criticism is the non-zero downtime deployment. Also when I update docker some apps don't restart properly, but that may just be my (basic Ubuntu dedicated) server though.

zapt02 4y ago
Non-zero downtime deployment is supported for apps without mounted volumes: https://github.com/caprover/caprover/issues/661#issuecomment-619548552 https://github.com/caprover/caprover/issues/661#issuecomment... Tangentially I was looking at Render.com the other day and they also don't support zero downtime deployments if you have a mounted volume, so it's not very uncommon even on cloud platforms. As for restarts, I didn't have that problem yet, I believe CapRover adds `restart: always` to all the running containers so they should automatically boot. You might want to check out the logs of the containers that don't restart or just always hard restart the server after a Docker update.
- conradfr 4y ago
  I guess most of my apps have persistent data.
  - smt88 4y ago
    Every useful app has persistent data. It sounds like you have a design problem, though. If you're treating application servers like cattle, then none of them should have persistent data (except caching that's disposable). There are fire-drill days that require deployments, so downtime incurred when updating your application code is unacceptable. To solve this, put your persistent data on a separate server and store it in a proper database (Postgres, for example). Postgres never needs emergency updates, so the downtime for those (infrequent) updates can be pushed to non-peak hours.
    - conradfr 4y ago
      I would maybe do all that if it was for more than side-projects that can tolerate 5-10 seconds of downtime when deployed :)

andrasbacsai 4y ago

Hey, the founder of Coolify here. I'm constantly adding new features to Coolify. Which ones are you missing (except Docker Swarm)?

zapt02 4y ago
CapRover has a huge collection of "One Click Apps" that will deploy hundreds of fully functioning applications for you including dependencies (so for example for WordPress it will spin up both a web and a database container): https://caprover.com/docs/one-click-apps.html https://caprover.com/docs/one-click-apps.html Also I think the way you create different kinds of resources are confusing in Coolify, like what is a "Git Source" or "Destination", all I want is to run my container. It's very different from Herokus/Caps interface and not in a good way. Also why can't I just deploy from an image? In CapRover I often spin up a container, like `redis-commander` or `wordpress` and then just configure its env vars and volume mounts. In Coolify it seems you have to connect a GitHub repo which is not a desirable workflow for me.
- andrasbacsai 4y ago
  I saw CapRover's one-click-apps and I'm thinking of using a similar solution in case of Coolify. Resources are defined in this way, because you can connect a lot of things to Coolify, GitHub, GitLab, hosted or self-hosted, later on Gitea and other git sources, and also different destinations, local docker engine, remote docker engine and later on Kubernetes. I will improve the onboarding experience to not feel the first use as a burden. :) Git based deployment is only required, if you would like to deploy a custom thing, that is currently not supported by Coolify. I'm working on a solution where you can use Docker Hub to deploy images (https://feedback.coolify.io/posts/6/deploy-from-docker-hub https://feedback.coolify.io/posts/6/deploy-from-docker-hub).
Aeolun 4y ago
The one thing I’m missing in Caprover, and that would make me switch instantly, is I want to be able to feed it a docker-compose file to run a whole stack. Now if a service has only a docker-compose file I have to pull it apart and start every service individually.