Hi, I’m updating https://sustainable-rails.com for Rails 8 and I want to include a section about Kamal. I haven’t used it, nor am I able to ATM, but I wanted to provide a very brief “here are things to consider about it vs using a PAAS”.
My draft is very short and not intended to be a “hot take” nor intended to be persuasive for or against Kamal—just a basic overview and some considerations. I would love someone knowledgeable to see if I’ve accurately described it. I’ve read through the documentation and am not 100% confident about what it does vs what a developer using it must do.
Reply here or email davec@naildrivin5.com - I’ll give you a physical copy for your trouble (or donate it to the person of your choice)
Ideally, someone who is using it in prod and has also used a PAAS like Heroku.
I would like to support you … I just deployed a very small app (https://www.jochenk.com) on a VPS at hetzner.com trying out kamal 2 because I hat trouble with kamal 1 and traefik. Everything works as expected … maybe I can help you.
I used both Kamal pre v2 and Kamal 2 to deploy to production. What I found was that the documentation is far from perfect, which made it a bit of a pain to set it up with github actions or bitbucket pipelines. It now also has a quite strong dependency on docker buildx which can be a pain in those environments.
In general everything seems pretty straight forward and with automatic ssl certificate generations it has become much more user friendly and usable. However what I found was that with a new rails 8 app everthing might be set up for you, but if you want to deploy a rails 7 app you have to fiddle a lot until everything works. Most of the default config is not documented well enough to reproduce in another stack other than rails 8.
You are right on that. You can run accessory services like redis and Postgres with a simple config and probably also some kind of backup script container to perform regular backups. But in general you have to configure everything yourself.
There‘s a simple command to check the container logs but no log aggregation.
Networking config and block storage needs to be provided. Load balancing as well. The idea is that you deploy to a cloud vm which makes configuration of these things trivial.
You also need a private container registry. GitHub ghcr will work fine.
Think of Kamal as Capistrano for containers and nothing else. It’s a bit like a preconfigured docker compose deployment but with no downtime deploys and easy rollbacks.
We currently use Capistrano, and I prototyped a conversion to Kamal. We happened to have an incident that required a staging server rebuild at the same time.
It exposed to us that with Kamal, we wouldn’t have been fiddling with all of the dependencies on the host OS. We could have just installed the OS, hardened, and deployed. Major win. You still have to manage OS updates, but we would probably do that by reinstalling, not do-release-upgrade or anything.
Log aggregation is problematic. We routinely need logs from last week. Probably our biggest hurdle yet, but I’m sure there’s a drop-in for aggregation?
Networking wasn’t an issue with a Hetzner load balancer setup. It felt like our nginx web head/load balancer would be equally simple, but we didn’t confirm that fully.
We found that migrating from our metal servers to Kamal/Docker would mean we’d have to somehow migrate the metal database into the docker db volume. But you can also run your metal DB while the rest is Kamal/Docker.
Environment variables were quite troublesome - there’s about 3 ways to manage the 5 steps, and two steps are optional. It’s not hard to get them in place, but it was difficult to predict if a given method would cause pain later.
For us, Kamal seemed like it saved 10 time units in one area and cost 8 times units in another. Still worthwhile, but not a “huge win” for our established monolith.
I’m not sure what you mean by “external data sources” and “block storage” other than the general “does Kamal handle this?” I think the answer is no, but it might be “no, and you don’t want it to.”
Happy to discuss more if there’s anything useful in the limited experience I have.
Yeah “external data source” means “running a SQL database” or “running Redis”. Block storage is “managing a disk available to all servers”. Sounds like Kamal would not handle these for you (nor is it intending to)
I would say that Kamal does help you manage SQL and Redis, inasmuch as they set up the containers for each alongside the app as accessories. You can set a custom my.cnf, establish the ENV and such. In many of my cases, that’s good enough that I would consider that Kamal is doing that for me.
But Kamal itself doesn’t do log aggregation, replication/backups, tuning and such. So Kamal doesn’t manage SQL or Redis in the traditional sense.
I know of no way for Kamal to manage block storage. But that’s typically used with VMs, not containers, I believe. Containers use volumes instead. So I’m not sure how one would mix block storage and containerzed apps and accessories.
Kamal is a deployment tool that enables containerized Rails applications to be deployed to your own infrastructure, such as servers managed via Docker and Kubernetes. Unlike a PAAS like Heroku, it requires more hands-on configuration and management for infrastructure, scaling, and monitoring. While Kamal provides flexibility and cost control, it demands more operational expertise compared to the convenience and abstraction of a PAAS. Feedback from someone with production experience in both Kamal and PAAS environments would refine your draft further.
