I predict Kamal will stop being a default in future versions of Rails. It’s way too complicated: x.com/dhh/status/184…
- You now need a container registry. With Capistrano I just need my GitHub repo
- Private container registries cost money. If you want to keep your projects code private, that’s an extra $5-$20 a month just for the container registry; transfer charges apply. You’re moving ~half a gigabyte across the internet for every change you make to the code
- No good container registry option: I ended up having to set up AWS ECR as my container registry (and I’m moving off the cloud!) Why? You can’t deploy without a container registry; ECR is ~free and private and just works out of the box with the aws cli, ghcr was extremely cumbersome to set up: I had to figure out github fine-grained tokens, I had install the Bitwarden CLI and configure it to manage the GitHub token, I had to figure out what Kamal was expecting to fetch from my Bitwarden vault, all of this while leaking my main Bitwarden access email in the process because you need to commit it in plaintext to git, etc. I also tried DO, Docher Hub et al but every option was more complex than the previous one because you need to figure out each service pricing, limits, overcharges, etc. All of a sudden ALL your business and operations depend on this new third party and its limits
- If you want your own container registry to avoid this third party mess, that’s another server you need to set up and maintain, yet another moving piece in this puzzle
- You need to keep your local Docker install up to date: you should always be running the latest Docker version, it eats up resources like crazy and over time fills up your disk with gigabytes of old images; it's yet another moving piece to take care of
- Kamal relies on other Docker dependencies to build the Docker images (like moby/buildkit, which currently has critical security vulnerabilities) it's yet another moving piece that you rely on and that someone needs to maintain
- If your machine is not powerful enough or if it gets filled with the GBs upon GBs of Docker images you’ll end up generating, you now need a remote machine just for builds, yet another moving piece; you need to pay for that too, you need to set it up and maintain it over time
- Kamal is full of things that kinda work but not really: my M1 can’t compile for x86_64 arch for some reason (it just stalls), but compiles just fine for arm, the internal Docker image bundler version needs to match your dev Gemfile.lock "bundled with" or otherwise it’ll build the entire image anew each time, it's just full of undocumented things you need to figure out after errors pop up, etc.
- You need to manually configure a Postgres container accessory if you wanna run Postgres. You would imagine it came preconfigured by default after running `rails new --database=postgresql` but it doesn't. You need to figure that out too (which Docker image to use, how to not expose the DB port to the internet, config files, DB env secrets...) At which point why don’t you just configure your own DB servers from scratch
- Even with all of the above solved, I’d still need solutions to problems I currently solve easily with a simple Nginx setup file, like extracting real IPs from Cloudflare proxied traffic
- Kamal setup claims to take a clean Ubuntu server and leave it production-ready, but in reality it only installs Docker: you still need to disable password login, harden the server, configure ufw, do all server admin work yourself. This is roughly as much work as setting up a prod server for Capistrano
- Deploy times are longer than Capistrano: you need to build the image, get auth to the container registry, upload it to the container registry, connect to the instance, pull the image from the container registry, deploy it, wait for every image in your deployment to go up…
- In general, Docker just adds another layer between you and the code: can’t just ssh and rails c, now you need to know your way around Docker containers and access their logs etc; everything becomes slightly more obfuscated
- You can't easily live edit files in prod / staging to test small config changes. I sometimes just nano some files and live edit files in production to quickly test config options or debug prod stuff. Takes a second to edit a file and see the results. It's only once I figure out the right config that I write the proper code, commit it to git, and actually deploy the thing. If I wanted to do this with Kamal, I'd need to build a new image after each change, wait for it to be built, uploaded, downloaded, deployed, etc. Which is a big flow stopper, your concentration breaks while waiting, you switch contexts, lose track of what you were doing... live code editing in production gets 10x more difficult
Kamal solves nothing for me but adds a gigantic list of new problems that I now have to worry about
I spent 4h last night trying to deploy a clean Rails 8 app. I failed miserably. Couldn't get anything deployed
And I'm fairly experienced with Rails, I've also been using Docker on and off for some years (e.g.: I have exp building Python cog containers for Replicate) – I know my way around Linux too
And still after 4h I couldn't get it to work
I don't know how this would be any easier for less experienced developers
I LOVE Rails and dhh, but I would have never expected a thing like Kamal from a project that advocates so loudly for no-builds. It literally introduces an unnecessary build step to your Rails workflow. It even forced me to go back to AWS just to test things out!
I'd like to be proven wrong but IMHO Kamal will be the webpacker of the 2020s. Gone from Rails in 5 years I think
- You now need a container registry. With Capistrano I just need my GitHub repo
- Private container registries cost money. If you want to keep your projects code private, that’s an extra $5-$20 a month just for the container registry; transfer charges apply. You’re moving ~half a gigabyte across the internet for every change you make to the code
- No good container registry option: I ended up having to set up AWS ECR as my container registry (and I’m moving off the cloud!) Why? You can’t deploy without a container registry; ECR is ~free and private and just works out of the box with the aws cli, ghcr was extremely cumbersome to set up: I had to figure out github fine-grained tokens, I had install the Bitwarden CLI and configure it to manage the GitHub token, I had to figure out what Kamal was expecting to fetch from my Bitwarden vault, all of this while leaking my main Bitwarden access email in the process because you need to commit it in plaintext to git, etc. I also tried DO, Docher Hub et al but every option was more complex than the previous one because you need to figure out each service pricing, limits, overcharges, etc. All of a sudden ALL your business and operations depend on this new third party and its limits
- If you want your own container registry to avoid this third party mess, that’s another server you need to set up and maintain, yet another moving piece in this puzzle
- You need to keep your local Docker install up to date: you should always be running the latest Docker version, it eats up resources like crazy and over time fills up your disk with gigabytes of old images; it's yet another moving piece to take care of
- Kamal relies on other Docker dependencies to build the Docker images (like moby/buildkit, which currently has critical security vulnerabilities) it's yet another moving piece that you rely on and that someone needs to maintain
- If your machine is not powerful enough or if it gets filled with the GBs upon GBs of Docker images you’ll end up generating, you now need a remote machine just for builds, yet another moving piece; you need to pay for that too, you need to set it up and maintain it over time
- Kamal is full of things that kinda work but not really: my M1 can’t compile for x86_64 arch for some reason (it just stalls), but compiles just fine for arm, the internal Docker image bundler version needs to match your dev Gemfile.lock "bundled with" or otherwise it’ll build the entire image anew each time, it's just full of undocumented things you need to figure out after errors pop up, etc.
- You need to manually configure a Postgres container accessory if you wanna run Postgres. You would imagine it came preconfigured by default after running `rails new --database=postgresql` but it doesn't. You need to figure that out too (which Docker image to use, how to not expose the DB port to the internet, config files, DB env secrets...) At which point why don’t you just configure your own DB servers from scratch
- Even with all of the above solved, I’d still need solutions to problems I currently solve easily with a simple Nginx setup file, like extracting real IPs from Cloudflare proxied traffic
- Kamal setup claims to take a clean Ubuntu server and leave it production-ready, but in reality it only installs Docker: you still need to disable password login, harden the server, configure ufw, do all server admin work yourself. This is roughly as much work as setting up a prod server for Capistrano
- Deploy times are longer than Capistrano: you need to build the image, get auth to the container registry, upload it to the container registry, connect to the instance, pull the image from the container registry, deploy it, wait for every image in your deployment to go up…
- In general, Docker just adds another layer between you and the code: can’t just ssh and rails c, now you need to know your way around Docker containers and access their logs etc; everything becomes slightly more obfuscated
- You can't easily live edit files in prod / staging to test small config changes. I sometimes just nano some files and live edit files in production to quickly test config options or debug prod stuff. Takes a second to edit a file and see the results. It's only once I figure out the right config that I write the proper code, commit it to git, and actually deploy the thing. If I wanted to do this with Kamal, I'd need to build a new image after each change, wait for it to be built, uploaded, downloaded, deployed, etc. Which is a big flow stopper, your concentration breaks while waiting, you switch contexts, lose track of what you were doing... live code editing in production gets 10x more difficult
Kamal solves nothing for me but adds a gigantic list of new problems that I now have to worry about
I spent 4h last night trying to deploy a clean Rails 8 app. I failed miserably. Couldn't get anything deployed
And I'm fairly experienced with Rails, I've also been using Docker on and off for some years (e.g.: I have exp building Python cog containers for Replicate) – I know my way around Linux too
And still after 4h I couldn't get it to work
I don't know how this would be any easier for less experienced developers
I LOVE Rails and dhh, but I would have never expected a thing like Kamal from a project that advocates so loudly for no-builds. It literally introduces an unnecessary build step to your Rails workflow. It even forced me to go back to AWS just to test things out!
I'd like to be proven wrong but IMHO Kamal will be the webpacker of the 2020s. Gone from Rails in 5 years I think
just for the record: for this I created a clean new project using Rails 8.0.0.rc1 (just a few hours after it was released) and Ruby 3.3.5 (latest); Kamal 2.2.2 (latest too)
my goal was to get familiar with the new Rails omakase and get ready to upgrade all my Rails projects
I was hoping Kamal 2 would be a significant improvement over Kamal 1 (which I tried earlier this year, thought it was too early of a release, and that v2 would solve a lot of things) but it seems I was wrong
my goal was to get familiar with the new Rails omakase and get ready to upgrade all my Rails projects
I was hoping Kamal 2 would be a significant improvement over Kamal 1 (which I tried earlier this year, thought it was too early of a release, and that v2 would solve a lot of things) but it seems I was wrong
• • •
Missing some Tweet in this thread? You can try to
force a refresh
