Review: Deploying apps with Kamal
Almost a year ago I deployed a web application which allows users to view energy certificates for buildings in the Netherlands. (check it out here...)
I used Kamal. A deployment tool created by the developers of Basecamp and Hey.
After spending time with this tool, it is time to reflect on the experience.
What I love
You start small, and you can hack your way into more advanced setups. By default the application builds on your machine and you push the image to the remote system on deployment. This makes it all very easy to get started with.
It is mostly built on Docker commands. The tool logs them nicely in your terminal. So it is easy to understand what is going on.
The source code is compact and for an experienced person easy to understand. Even if you are not very familiar with Ruby.
The documentation is appealing for a modern generation of software developers. With a nice introduction video to start with and not too many pages of low-level documentation.
Once deployed you can just launch a shell into a deployed container. The perfect way to debug something in the deployed environment. This is a huge win over services like Google Cloud Run, which does not have that functionality.
It lacks any complex configuration for the proxy. Making you solve more on the application level. Like non-www to www redirects. I like this because it reuses the application service which you are already familiar with.
Best practices are already implemented
For example:
- Maintenance mode
- Accessories concept to launch components like databases which should keep running when your application deploys
- Secret key management using password managers or cloud services.
- Zero downtime deployment
- Asset bridging
The container and proxy configuration is minimal. They advise putting a CDN like Cloudfront in front of your service if you want to improve performance.
In order to utilize a CDN correctly you need to think about cache headers. This is something that I find important to be aware of early on when developing an application.
The tool is focused and I believe Kamal pushes ourselves into good application development practices earlier.
What I don't like
It is designed to solve the problems of a single company. This means that it does exactly that, but is not providing a feature complete solution for all of us. For example, the cron support is minimal.
Named volumes are part of the application deployment. This means that you might delete your important data when taking down the app.
Secret management relies on external services. I prefer to have a locally encrypted file for personal projects which does not rely on external providers.
Kamal uses two directories: .kamal/ and config/. You get used to this, but the fact that all configuration is not in a single place can be confusing.
Version 1 and 2 documentation can be found easily using search engines. Which made me sometimes look at outdated information.
Health checks are done without the host header. Requiring you to create a custom middleware to handle such requests for Django projects. It can feel both pragmatic and hacky at the same time.
Initial configuration is not much faster than with other tools. When I deployed my first Kubernetes app it took almost as much time as setting up my first Kamal deployment. In one day I was able to deploy my application. It took almost a week to be fully satisfied with the results and to integrate it in my CI/CD setup.
The focus on bare metal deployment also means that monitoring is an unresolved topic. Other managed services like Google Cloud Run or AWS Elastic Container Service come with some monitoring and logging enabled by default. Kamal does not solve this for you.
Kamal lacks a good branding logo. The Docker whale, the Jenkins Butler or the GitHub Octocat all have iconic logos. Kamal also needs something like that. It makes the tool more recognizable and fun to relate to.
Conclusion
I like that I am able to understand what the tool does and that it solves some (web) application specific problems out of the box. It is a big joy to work with for personal projects, but I also see that it is mature enough to be used in commercial context.
However I don't believe the tool is "cheaper" to use in a complex environment. There are just many things remaining which require attention like setting up monitoring, integrating it in the CI/CD pipelines or implementing a backup solution.
Overall, I think Kamal is a valuable addition to the available deployment tooling.