Recently I had a discussion with the team about when to use Caprover to deploy the production model, I will share some of my views on when to use and not to use Caprover: English version : https://vinguyen.blog/what-is-advantages-and-disadvantages-of-capover-in-production-deployment/
What is Caprover?
In short: Free and Open Source PaaS! More details: https://capover.com/docs/get-started.html
What are Caprover’s strengths and weaknesses?
- Caprover is a complete opensource PaaS (Heroku like as opensource) built on the basis of docker swarm & production ready: that is, we can use it for similar deployment on Heroku on 1/many self-host servers: Because it is PaaS, it is easy to apply Twelve-Factor in the deployment model
- There are many simple & handy deployment solutions: CLI, Web UI, Git integration
- Deployment model, full roll-out, CI/CD ready to use
- Leverage the power of Docker/Dockerized Application, which is already very popular among programmers today
- One-Click App has many pre-configuration applications available. on-click to deploy
2. The score is not strong
- Persistent data: I consider this to be a major limitation of Caprover, because it only supports persistent data on Disk (Once they get created they get locked down on a specific server (if you have multiple servers).): because with With this limitation, when you want to deploy a service that requires Persistent data, the horizonal scale of the app is suppressed because it can only be used on 1 Server, or the application must be designed to be a stateless app from the beginning and use the following mechanisms. other storage: eg Blockstorage ( S3/MinIO/Storj,…)
- Scaling resources on multiple nodes (need more verification): in some cases while supporting the team to setup scale 1 Caprover cluster, I found that autoscaling & resource balancing on multiple nodes is not really good, some cases need have to manually allocate resources on the server, for me, this point is both the optimal point (because I can calculate myself where to put the service is best) but it also costs too much to setup & monitor, this point the orchestration Other tools like k8s work quite smoothly
- Account management & decentralization on Caprover: CapRover is not an enterprise grade application like Kubernetes. Basically, caprover doesn’t have the goal to become an enterprise grade application, so the mechanisms for users, delegation, and resource sharing will not be developed much, so if you have the desire to use Caprover in a multi-member team, having a decentralized mechanism, or many applications/services belonging to many different products on the same Caprover, it is almost impossible to deploy.
So when is Caprover suitable and inappropriate?
- The team is small, can be trusted and doesn’t need complicated mechanism, the product is in the MVP or early state of the insight product, not large scale, traffic to the backend does not increase or decrease, volatility, …
- The amount of service is not too much, persistent data is designed according to statefull service
- The server has Horizontal and Vertical Scale capabilities.
- Team has experience with docker, dockerized application, want to deploy CI/CD process fast, convenient, compact & ready to use
- Have experience with Nginx, Letsencrypt,…
- Familiar with PaaS model like Heroku
- Complex applications, many services, a lot of traffic, or unusual fluctuations (eg events, e-commerce flash sales)
- The team has many products but wants to deploy on the same Caprover, but has the desire to divide data and resource rights.
- Other possible deployment solutions
- Heroku: it’s good, it’s fine to pay
- Docker, docker-compose on Single server: this solution is just enough for small applications, traffic is not too high, simple, convenient, easy to sync & backup, CI/CD can also be deployed by some simple techniques simple
- Aws Autoscaling Group/Azure VM Scale Set: This solution is better for applications with high load demand, or scaling when there is a need for Kubernetes/K8S: if applicable, good, but cumbersome and costly to maintain , the cost of platform resources is high, so it is only suitable for relatively large applications and the team has strong K8S experience (I will have a post about this later)