Deploying JustDjango on render.com
Recently we changed our hosting technologies. After a year of self-hosting using Caprover, I decided to move to Render
Caprover is one of the hosting solutions I recommend the most for people on a budget. In this post, I will explain why I moved JustDjango off of Caprover and also why specifically I chose to host it on Render.
Caprover vs Heroku
Caprover is an open source PaaS. In fact, Caprover was invented because of how expensive Heroku is.
Heroku is a very popular PaaS and is very commonly used in the Django community. However, it's also one of the more expensive options. Deploying on Heroku is really simple. Within a few clicks you can have your Django app hosted and running. Caprover took the best part of Heroku - the simplicity of deploying - and made it free.
For those who don't know, the JustDjango website is built with Django. Isn't that surprising? 🤔
Just like everyone else I was trying to minimise the costs of the JustDjango deployment. After evaluating the costs of the hosting services, it became a no-brainer to deploy on Caprover.
Architecture of Caprover
It's important to understand that Caprover is not a server. It is a software that you install on your server.
This means you still need to use a hosting service. Digital Ocean is always my go-to solution because it's only $5/month to have your own server. To make things even better, there's a Caprover app on Digital Ocean's marketplace. So if you want to use Caprover you just select their app and the server will be preconfigured with Caprover installed. You'll still need to follow the rest of the installation process but overall it's very simple to get started.
Once you've got Caprover setup, you can immediately start adding your own apps. Under the hood, Caprover's apps are actually Docker containers. I encourage you to read through their documentation as there's quite a few ways to deploy your app. You can use a DockerFile, or even upload a tar file. However, the best way to deploy is without a doubt connecting your Github repository. It does require a little bit of work to setup the webhook but once that's setup all you have to do is push to Github and your app will be deployed.
Downsides of Caprover
There are very few downsides of Caprover. In my experience these are the three that kept surfacing:
Deployments cause down-time
If you're running an internal app that doesn't need to be accessible via the web, then chances are this is not a problem for you. But if you have users trying to access the app then, of course, this is a problem, especially as the number of users increases.
It's worth noting that this downtime is not a bug of Caprover. Technically, the latest container is started before the old container is killed. But because Django has to run migrations, static-file collection and only then the runserver command, it doesn't finish the processes before the old container is killed. Hence there's a small down-time. Either way, this becomes more and more of a problem as the user-base increases.
Storage issues
Caprover is limited by the storage on the actual server. Every time there is a deployment Caprover stores the previous container so it can be used for rollbacks. It's also recommended to clean up the old containers after every 20 deployments.
The problem with this is that if you forget to remove old deployments, your site crashes due to a storage issue. If you're unfamiliar with Caprover this can be a tricky thing to debug as there isn't a clear error message telling you that storage has run out. If you're trying to automate processes this will definitely be frustrating for you. Hence I tried to deploy as infrequently as possible, and always checked how much old storage there was after each deployment.
Complexity issues
This is something I haven't quite figured out yet. As an example I tried to deploy an app of a relatively complex DockerFile. It required a lot of system dependencies and the build process easily took 10 minutes before caching. Once the build process ran into an unknown issue and froze. It was so bad that it took down not only itself but all of the other Caprover apps. This can be quite frustrating because the whole point is to have the apps isolated from each other.
That being said, using Caprover helped me level-up my skills as as developer. I learned a lot about deployment, Docker and fullstack development in general. The Caprover source code isn't that big so I encourage you to go through it to learn how about how technologies like React, Docker and LetsEncrypt were combined to create Caprover.
Moving to Render
With all of that said, I decided to deploy the JustDjango web app on Render.
The reason for choosing render was because I had come across it on Indiehackers. After reading about render and testing out a deployment with them, I was blown away by how easy it was. It's definitely the easiest deployment process I've gone through. All you do is select a Github repository and then define the build command and start command. Their system is smart enough to tell that your app is a Django app and they even recommend a configuration for you.
Something worth noting here is that when you deploy with Heroku or even Caprover, you need to add a configuration file to your repository. With render, you don't. You can configure everything inside their web app. Of course, if you want to define it with configuration files you still can.
Lastly, renders pricing is very competitive. Web services, private services and databases start at $7/month each.
Ultimately, the two main reasons for going withhttp://render.comRender were price and ease-of-use.