I am recommending against Kamal right now, here's why:

[braun2morrow]

A while ago a colleague introduced kamal to me and suggested we might start to use it.
So I've been reviewing it over the last weeks, and am now recommending that we do NOT use kamal.
Here are my findings, roughly in order of importance:

1. Kamal uses sshkit, which uses net-ssh, which is a do-your-own-crypto-in-ruby project and shows all the failings you'd expect from such an endeavor. If e.g. a break against the KEX diffie-hellman-group-exchange-sha256 occurred today, it would no longer be possible to run a sshd that accepts connections from kamal and gets only green scores from ssh-audit, which a good security policy will mandate. (That's far from the scariest thing about net-ssh, but hopefully illustrative.) If you want to do ssh things, call the ssh binary. I've filed should have an openssh backend capistrano/sshkit#563 for that.

2. Kamal hard depends on docker, and does not support other (better, more secure) container managers. So anyone able to deploy an app is implicitly granted anonymous root access to the production servers. There's Docker -> Podman ? #61 and I've made some own experiments with "ln -s /bin/podman /bin/docker", which I'll document there shortly. But kamal really should have a modular backend and be able to drive apptainer/proot/whatever, not just (things that look like) docker.

3. Kamal tries (IMNSHO too) hard to integrate with other things:

• Kamal will try to install docker by running curl -fsSL https://get.docker.com | sh as root
  (Being able to point kamal at root@new-vps-host and getting everything taken care of is nice, but that should be a customizable add-on script, not a dangerous footgun that might compromise otherwiser-managed servers. Especially when you then might have to teach users that "kamal deploy" is bad and never to be used, in favor of "kamal redeploy". Unfortunate UI design there.)
• Docker's default logging setup: Kamal injects --log-opt max-size=10m without checking the server’s logging driver #1709
• git: kamal deploys the current git HEAD, not the filesystem as it finds it.

4. The docs could use some improvement:

• There ought to be an example deploy.yml with all the options kamal understands.
• I haven't been able to find out how shrinking the set of deployment servers is expected to be handled. Just removing them from deploy.yml probably revents kamal from stopping the container (because it no longer knows about the server).
• git integration (see above) is nowhere mentioned. This caused me >1h debugging because I expected kamal to pick up uncommited changes (because why wouldn't it?) And the warning is drowned in several screenfuls of colorful tracing.

5. I've been seeing syslog errors
   dockerd[1064]: time="…" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:34714" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:34714->127.0.0.53:53: i/o timeout" question=";vncdesign.com.vn.\tIN\t AAAA"
   on the server. I don't know why anyone would try to resolve that domain, or expect there to be a DNS server on 127.0.0.53:53. The code I deployed certainly didn't.

6. Occasionally, while "kamal redeploy"ing, the local docker would wedge itself with
   ERROR: failed to build: failed to solve: failed to resolve source metadata for docker.io/docker/dockerfile:1: failed to do request: Head "https://registry-1.docker.io/v2/docker/dockerfile/manifests/1": dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:56230->[::1]:53: read: connection refused
   (There is no DNS resolver on [::1]:53 either.) No amount of kamal redeploy --no-cache, docker system prune -a or searching the net for help would get me a different outcome from then on, only blowing away /var/lib/docker would, and then things would build successfully again, for a while. This is almost certainly a bug in docker, not kamal (and point 5 above likely is), but then we're back to point 2 and the lack of alternative.

7. When setting proxy:run:http_port in deploy.yml, kamal doesn't pass that as parameters to kamal-proxy run as you'd expect from the setting's name, but instead starts kamal-proxy on the privileged port and has docker forward connections by doing docker run … --publish $PORT:80 kamal-proxy run (This turned out to be a problem for my kamal-with-podman experiments, but I think it also indicates that the code should have a better attitude towards separation-of-concerns.)

Kamal is an interesting project, and I would like to have something like this, but due to the above, I think it is not ready for production use yet. Hopefully this feedback helps you to get there in a future version. :-)

[n3ph]

Also the way secrets are injected into Kamal is pretty wonky.
Sub-shell expressions may fail and lead to empty secrets while deployment.

[braun2morrow]

Yes, secret management is on my subjective "things Kamal tries too hard to integrate" list. Fortunately, that part is easy to ignore in favor of rolling your own.