samruby

be the change you want to see in the world

Follow up: https://intertwingly.net/blog/2025/10/17/Frozen-String-Liter...

> I felt bad

Don't. I can honestly say that I didn't write this post targeting HN. I'll go further... this post wasn't meant for people who are unlikely to use https://github.com/fly-apps/dockerfile-rails#overview. I recently added some features to that gem whose usage may not be intuitively obvious. I wrote this post to explain some of the motivation for those features.

I don't know how to mark posts as not intended for HN (and truth be told, if there was such a feature, I'd be inclined to overuse it). I don't know where else I should have posted this content, but I'm not sure I would be inclined to move it. In any case, this post, as written, serves a purpose for me. Somebody not you and not me felt it belonged here. We can both second guess that decision. Either way, there is no reason for either of us to feel bad.

The short answer is that litefs uses a single primary node (see: https://fly.io/docs/litefs/proxy/). I work with Ben so I imagine that over time we'll find a configuration that works with multiple databases each with their own primary node, but until then, this works for now.

Author here, and fly.io employee. I have an app that allows dance studios to schedule "heats" for competitions. Multiple dance studios, in separate locations, use this app with separate databases. I merely blogged some techniques that I found useful for my app. Most apps won't need any of this, but in the future when somebody has a related problem, I wanted something I could point to to show some techniques that might be helpful.

At the moment Rails is focused on simplicity/readability. I've got a gem that I'm proposing (and DHH is evaluating) that adds caching as an option: https://github.com/rubys/dockerfile-rails#overview