I’m working on a small project right now. Nothing revolutionary, but it works, it’s fun, and it has some interesting features.
Most of my career has been on the frontend, but I’ve also worked with Django, FastAPI, and sometimes Rails.
Rails has a very particular approach based on “magic.”
And I don’t mean “magic” only in a good way. I mean the kind of magic where things work… but you don’t fully understand why they work, because the framework hides a lot of complexity. This happens with many tools. jQuery was the first “don’t worry, I’ll handle it for you” library I used early in my career.
Hiding complexity is great, but it also requires skepticism, testing, and validation—things you don’t need as much when you build everything from scratch.
A Practical Example: Deploying With Kamal
For deployment, I used Kamal. Kamal handles a lot for you: server setup, deploy configuration, even SSL certificates. It’s a sweet deal—but you need to learn Kamal and trust Kamal.
Here’s a simple example of the configuration it requires:
service: retro
# Name of the container image.
image: registryUser/retro # <-- your docker username/project name
servers:
web:
- 0.0.0.0 # <-- your server IP
proxy:
ssl: true
host: retro.ponopo.site
registry:
server: localhost:5555
username: myusername # <-- your docker username
env:
secret:
- RAILS_MASTER_KEY
volumes:
- "db_storage:/root/storage"
Just a few lines, and Kamal will SSH into your server and set everything up. Magic!
When the Magic Breaks
Then I discovered a big bug in my production configuration.
So I had to slowly “unpack” the magic and understand what was really happening.
That led me to learn how to run Rails in production mode locally.
Here are the commands I used:
Create the production database
RAILS_ENV=production rails db:create
Run migrations
RAILS_ENV=production rails db:migrate
Precompile assets
RAILS_ENV=production rails assets:precompile
Start the server in production mode
RAILS_ENV=production rails s
Thanks and see y'all soon