Kamal: hot deployment tool to watch—or a total game changer?

Editor’s note: this article has been reviewed for 2024, with relevant changes. At the time of writing, we’re still watching and waiting.

TL;DR: If you want to know the results of our analysis, which projects will benefit the most from starting or moving to Kamal, who should switch to Kamal, and who should not—click here. Otherwise, read on!

To kick things off, a brief survey and history: Docker 1.0 turned 10 in 2023, and it initially addressed many issues crucial for shipping applications: portability, consistency and isolation. Yet, we still lacked a solution to manage Docker containers at scale. Thus, new instruments started to appear: Kubernetes was born and became the “planet scale” open source solution in the room. Meanwhile, popular cloud providers fought for users with their own services like Amazon ECS and Google Cloud Run. And the Ansible, Chef, and Puppet communities published a number of public roles and recipes of different quality and complexity which allowed deploying containers on a number of servers. Others, like Nomad and Docker Swarm, turned out to be a bit niche, but are still mature, alive, and kicking.

But all these tools have their limitations (more on those later), and, well, there’s always room for a shining new star in the sky. And here it is: Kamal.

Enter Kamal

Kamal aims to make container deployment as seamless and easy to a newcomer as possible. The underlying concept behind this tool is heavily indebted to old school Capistrano, a fact which its author highlights:

Kamal marries the procedural simplicity of Capistrano with the advantages of modern containerization techniques.

---

Kamal was specifically designed to be an imperative tool, which doesn’t hide complex logic under the hood. Accordingly, it’s easier to adopt Kamal from scratch, rather than, say, a declarative container orchestrator with state reconciliation logic. Thus, you’re required to read less documentation and write less configuration to kick off an app’s first deployment.

But, before we dive deep into the benefits of Kamal, we have to ask: do we really need another deployment tool? Perhaps one of the best ways to explore that question is by pointing out some of the gaps in preexisting solutions.

A deployment tool “vibe check”

So, on that note, let’s examine the various deployment tools and platforms, many of which you might already be familiar with, as well as the situations where they might hit some snags.

First, Heroku, Fly.io, and Render are excellent platforms that offer a pleasant developer experience. In fact, we generally do recommend these options instead of anything else because you can save a lot of time and effort upon initial project release (and for quite a lot of startups, they might be fine for years and years). But, as your project grows, your costs can start to skyrocket, or its technical requirements and limitations can begin to evolve beyond the platform.

Up next, Kubernetes (K8s). It’s the Evil Martian SRE team’s go-to recommendation for larger-scale projects which don’t fit the above solutions. It’s a brilliant container orchestration platform with a huge community and ecosystem around it. To make things even better, all the popular cloud providers (including AWS or Google Cloud, but also Digital Ocean and many others) have a managed K8s solution. Still it must be said, this is a complex system which can’t just be learned overnight. (Which is a point for Kamal and its simplicity, for sure!)

Nomad is also more suitable for experienced teams: it’s still a bit too complex and has a small community.

Mesos has a significantly steeper learning curve than even Kubernetes and this is coupled with a limited ecosystem.

Ansible, Chef, and Puppet are universal configuration management tools, and thus, are not tailored specifically for building and deploying containers.

In terms of complexity, Docker Swarm is simpler than many of the other contenders, but it’s not even close to offering the configurability of the other full-scale container orchestrators, it still has to be managed itself , doesn’t have a robust community, nor mass adoption in public clouds. Ultimately, it’s a niche solution.

And, last but not least, Amazon ECS and Google Cloud Run are popular options heavily promoted by their respective vendors. That said, they feature strict vendor-locks, necessitate vendor-locked knowledge, require additional (and complex or expensive) tooling and they aren’t very affordable either.

The benefits of Kamal

And that brings us back to Kamal and its benefits.

It’s simple and minimalistic. Kamal’s current attractiveness emerged mostly as a result of its simplicity. This single-purpose tool doesn’t require vast knowledge—a couple of virtual servers (Digital Ocean, AWS EC2, Linode, etc.) and a load balancer from your favorite cloud provider, and you’re set. There’s no need to manage the tool itself, and a lower threshold for beginning experts in infrastructure management to start containerized deployments means a lot for the evolution of the industry in general.

There’s no vendor lock. Kamal is a standalone CLI tool. You can easily run it from anywhere: a Docker container, your local machine or a CI/CD workflow. It basically has one strict requirement: we must provide it with the servers it will use to deploy.

It’s a Ruby gem. Since Kamal was written in Ruby, you can easily fork and customize it at your convenience.

It offers YAML configuration merging to spin up a copy of your applications with ease. Kamal has this concept of “destinations”. We define the main configuration in one file, and then, can instantly create a number of additional ones, which only need to consist of the differences between those configs and the main setup. This is an excellent way to spin up an instant review app or a full-scale staging environment, migrate to a different place, or just create an additional installation of your project somewhere across the world, in case you need that.

There are app health checks prior to actual app spin up. This is simple, helpful, and ensures you won’t just suddenly end up without a working application. (We personally recall how, previously, a similar Kubernetes feature changed our lives.)

Kamal provides an easy logs grep tool if you don’t have logs aggregation yet. For a loaded production application, a dedicated logs aggregation service is obviously a must, but when you start a small setup it can still be extremely useful.

Fast and easy rollback. Enough said: in general, it’s easy to quickly roll back containers, and this is also the case with Kamal.

ENV files templating. Kamal uses the default Rails credentials tools for environment variables and secret templating.

A deploy lock mechanism. Want to be certain no-one is deploying at the same time as you, or just want to freeze deployments to initiate a maintenance window? With Kamal, you can.

Running additional containers beside the actual app. A typical application may need to rely on additional services, like cache servers, databases, search and indexing services, and more. Kamal has a configuration section called “accessories”, which allows you to deploy those kinds of things, too. They will be deployed to designated servers, and they won’t be restarted each time you run kamal deploy.

Finally, Kamal allows us to easily execute the 4 key application management tasks:

1. On servers, it allows you to run a command on all servers (e.g. to update a package)
2. …or to run a command on the primary server.
3. In interactive sessions you can run commands in a separate container: for example, running a custom Rails task to fix a problem caused by a bug. (In this case, it’s better to get a separate isolated environment, which won’t be affected by the app’s main container restart and/or which won’t interfere with the app process)
4. …or, to run commands in a currently running session (perhaps to catch that one, user-hated and slippery bug that evaded your QAs).

We see an active development of Kamal over the last years. It got its own loyal community and is being actively developed and improved. In the begining, it had a number of pitfalls, which limited its functionality, but more and more of them are being solved as you read this text. Here is the list of examles, we think are the most obvious:

• Better management of zero-downtime deployment process was implemented in version 1.0.0.
• An improvement to run one-time tasks, like database migrations, was made in version 1.1.0
• If you want to run a background job you can now spin it up completely without a Traefik setup. (version 1.3.0)
• Cross architecture local builds (version 1.4.0)

And this list goes on.

The other side: points to consider

There’s no doubt that Kamal is rapidly increasing in popularity (in fact, Evil Martians has already received customer requests to help elevate infrastructures with Kamal). And the tool certainly has a ton of promise and benefits worth considering, but still, like with any new tool, we should do our homework.

37signals and DHH are currently in the process of migrating their applications from public clouds to bare-metal servers using Kamal as their primary container deployment tool; this is a much-hyped development, especially considering how much money they plan to save in the process. They’ve publicized this fact themselves, sharing a ton of articles describing the process and the achievements they’ve made along the way, like the ability to cut down deployment times to a fraction of what they were, implement custom super-fast VM provisioning for their needs with Chef as the main management tool, and to simplify their infrastructure configuration overall. 37signals certainly put forth a lot of effort accomplishing all of this.

Kamal is just one part of their stack, isn’t it, though? We all have unique infrastructures to work with, and we need to think about Kamal in the context of each of our unique projects. We need to be careful not to amalgamate their particular private infrastructure and expertise with Kamal itself. On this note let’s quickly review some points you should consider before making a final decision about using Kamal or another solution.

First of all, any emerging tool needs to be treated with care, as there can be teething troubles involved in the process. Second, Kamal is designed for specific tasks and scenarios, and these may not include your infrastructure, requirement restrictions, or edge cases.

It pays to keep in mind that one of the responsibilities of a good SRE engineer is to meticulously investigate the benefits and downsides of any new tool, and only after due diligence is done, try to fit it to your particular situation—so, let’s do it.

Deployment process times

Kamal doesn’t offer any new secret tools to speed up deployment times; it simply delivers on two key promises:

• You’re always going to deploy to a server (virtual or a bare metal server) that you expect to be up and running.
• Kamal stays out of the way, allowing for a fast deployment process.

Under the hood, it has the same Docker Build process relying on: the speed of the server it’s running on, the structure (and the quality) of your Dockerfile, the size of your app, the Docker layer caching, how fast is the network between the computer where you run kamal deploy, the build server, the docker registry, the app nodes themselves, and the startup speed of your app.

To achieve a faster deployment, you’ll have to pay attention to each of those steps, and these are applicable to any infrastructure configuration you can imagine.

Again, Kamal stays out of the way, leaving it up to you, for better and for worse.

Migration to bare-metal servers

A lot of hype exists surrounding Kamal about the ability to get off the cloud and to bare metal servers.

Kamal is an excellent tool to untie your hands and allow you to deploy your early-stage app to any kind of server (be it an AWS EC2 instance, Digital Ocean droplet, a dedicated bare metal server you rented, or your Raspberry Pi).

But it isn’t a tool that facilitates migration from cloud to bare-metal servers. It has no additional tooling to aid you with bare-metal server management or solving bare-metal server problems. For that, you need an expert, or a team of experts, for your project.

And that brings us to the next point.

Managing the underlying infastructure

Setting up a fleet of bare metal servers is a non-obvious task which requires specialized knowledge, preparation, and planning and configuration management long before the point where Kamal deploy is run.

Let’s say you wish to simplify things for yourself and choose to use virtual nodes instead. You still need to manage your cloud: provision nodes, configure network rules, and set up load balancers.

Further, a typical project consists of multiple components. It generally requires databases, a backup system, load balancers, access management system, monitoring and log aggregation servers (if New Relic and its rivals are out of the scope), build servers and image registry servers (if you’re aiming for the ultimate deployment time reduction).

In short, managing these all requires relevant experience.

To illustrate, while adding a PostgreSQL container to the accessories in your Kamal config can be an excellent solution for a demo or a review app, you can’t rely on this in production without a significant configuration effort.

Thus, it may still be wise to rely on managed database services modern clouds provide.

Monitoring and log aggregation

Each time you spin up a new infrastructure, simple or complex, you have to continuously ensure its operational status and stability at any given moment. Thus, your team should have a transparent monitoring solution of the entire setup and an easy way to gather and view log files across all instances of your application. Without those, issues can go undetected until they cause significant damage or downtime, which can be costly in terms of lost productivity, revenue, and reputation.

Kamal provides you with a neat log-grepping tool (we wish we had that back in the days of Capistrano!), which may be just enough for starters. But that’s it—so you’ll need a monitoring solution of your own.

For a small team with a limited number of servers, a free New Relic setup is an excellent option. It can cover your monitoring needs, and even provide you with a better log aggregation service. But it can be pricey the moment you step over the free-tier plan. In that case, to save, you may need to consider your own monitoring solution, like Prometheus with Grafana and ELK/Loki.

Were there any improvements to those point over the last year?

Unfortunately, we still see the lack of discussions about those topics in the context of implementing Kamal.

I’ll allow myself a personal touch here. I think it represents the situation is that we live in 2024 and we expect infrastructure to be less complex and way more automated to manage. In other terms: my feeling says we expect to have tools that either are cloud services like Heroku, DataDog, or remind them. Hype around the Kamal and the Basecamp’s migration is perfecly highlights that, to my opinion.

Who will benefit the most from Kamal?

Kamal is being technically promoted as a simple tool which is easy to use and may help less-experienced teams enter the world of container-based infrastructures without relying solely on proprietary services, but nevertheless, beginners should still take care here. On the flip side, for projects with teams who already have enough expertise to face all the technical challenges and tasks we’ve outlined above, it’s possible they could make a weighted, well-calculated decision to move to Kamal.

So, should you switch?

• If you don’t want to go deep into the depths of admin work or deployment, and if Heroku, Fly.io, or Render, or their likes fits your case and you’re happy: stick with that solution.
• If you don’t like public clouds and prefer VPS or bare metal hosting: try Kamal.
• If you already have K8s and it’s comfortable for you, or if you have a very advanced setup: advisable to leave it be for now.
• If your application has regular usage spikes and requires frequent manual or auto-scaling of the infrastructure: consider using Kubernetes, if you’re not already doing so.
• If you don’t like Kubernetes or find it too difficult: definitely investigate Kamal, it may fit your case.

Kamal is a new tool, and it has strong potential to grow into something bigger. That means new features, carving out its own niche, and pushing the community forward by helping “young” projects organize their own containerized infrastructures.

We hope we were able to shed some light on Kamal’s pros and cons—and if you have any infrastructure concerns, Evil Martians’ dedicated SRE team is on standby to help you sort out the various pros and cons that come with each option:

• We can consult on if it’s worth migrating to bare-metal servers, and if so, when and how to do it.
• Our experienced Kubernetes pros are always ready to jump in and assist with any related issues.
• We can also help you understand if Kamal is the right choice for your project.
• If Kamal is the choice for you, our SRE experts will help make it happen.
• And, in general, we’re here to help with any of your project’s needs!

Don’t hesitate, reach out to us for an extraterrestrial consultation!