If you were feeling adventurous you could also queue up requests with nginx and a little bit of Lua scripting to achieve zero downtime deploys. That's what Basecamp did 11 years ago with: https://github.com/basecamp/intermission
In practice I find zero downtime deploys with request queuing can get tricky. For example, it's not just your web app that gets deployed. There's also your background worker and action cable process that runs in its own containers and isn't proxied with the same health check as your web container. I haven't used Kamal yet but how does it deal with your action cable process and background worker becoming healthy with v2 of your app while the web app is still serving v1 of your code or vice versa?
Isn't this the same problem you'd have deploying your updated code to any number of servers larger than one? There's no way to shift over all the traffic at the exact same time, so all database changes have to be forwards compatible e.g. you can add columns before using them, all code changes have to be cross compatible (e.g. if there are unknown job names or arguments, they get automatically retried)