I’m trying my hand at Ruby-on-Rails for the first time. I have an app that is working in my local Docker. Based on the Rails ‘getting-started’ guide I did fly launch and kept the default settings, changing only the fly.toml to point at a separate Dockerfile (uses production rather than development env). You should be able to see the code here.
The error that I’m seeing appears to be
2025-10-14T18:01:49.136 app[286061ae9d7308] ord [info] * Listening on http://127.0.0.1:8080
2025-10-14T18:01:49.136 app[286061ae9d7308] ord [info] * Listening on http://[::1]:8080
2025-10-14T18:01:49.144 app[286061ae9d7308] ord [info] Use Ctrl-C to stop
2025-10-14T18:01:49.179 app[286061ae9d7308] ord [info] time=2025-10-14T18:01:49.179Z level=WARN msg="init: cannot determine last wal position, clearing generation" db=/data/production.sqlite3 error="primary wal header: EOF"
2025-10-14T18:01:49.181 app[286061ae9d7308] ord [info] time=2025-10-14T18:01:49.181Z level=INFO msg="sync: new generation" db=/data/production.sqlite3 generation=6bf49366bda33333 reason="no generation exists"
2025-10-14T18:01:49.298 app[286061ae9d7308] ord [info] time=2025-10-14T18:01:49.298Z level=INFO msg="write snapshot" db=/data/production.sqlite3 replica=s3 position=6bf49366bda33333/00000000:4152
2025-10-14T18:01:49.369 app[286061ae9d7308] ord [info] time=2025-10-14T18:01:49.368Z level=INFO msg="snapshot written" db=/data/production.sqlite3 replica=s3 position=6bf49366bda33333/00000000:4152 elapsed=70.420439ms sz=2101
2025-10-14T18:01:49.435 app[286061ae9d7308] ord [info] time=2025-10-14T18:01:49.434Z level=INFO msg="write wal segment" db=/data/production.sqlite3 replica=s3 position=6bf49366bda33333/00000000:0
2025-10-14T18:01:49.475 app[286061ae9d7308] ord [info] time=2025-10-14T18:01:49.475Z level=INFO msg="wal segment written" db=/data/production.sqlite3 replica=s3 position=6bf49366bda33333/00000000:0 elapsed=41.179181ms sz=4152
I also tried following the ‘getting-started’ guide with a new empty app and got a “MissingRegionError”, closely matching this old topic, although I don’t have a users.rb so I don’t think I have the same root error as them. My worry is that even if I solve the first issue I’m going to see that one.
Hm… This looks like it might be the machinery that streams SQLite backups, which is a middle-ground for app reliability that fly launch started setting up by default early this year. That’s optional, though, so you might try opting out, as mentioned in @rubys’s announcement post, if all you need is a throwaway database for testing/experimentation.
[Basically, you will lose all that data at some point, when the underlying hardware (inevitably) fails, .]
Also, it might be a good idea to add the sqlite and litestream tags to the present forum thread, since the local Litestream experts don’t necessarily read the Rails side.
These show as WARN and INFO for me, so that could be why they don’t show up as errors in your log. That said that could also mean these aren’t actually the root cause of my problem. Is there anything I can do on my end that would get you more information?
I mentioned in the first time that I had been getting an error when I made a smoke test app per the ‘getting started’ guide. I fly-launched it again after having deleted the app and fly.toml to confirm what Rubys and mayailurus suggested about the logs being normal and the listening host being wrong and found that this time everything was working.
It didn’t work quite that simply with my actual app, I ended up creating a whole new Rails app and then copying over my controllers and models and whatnot. This time when I fly launched it, it worked fine. It appears that the fix was a very complicated version of “have you tried turning it off and on again?”
For anyone curious this PR represents the total non-fly changes. A few version bumps and changes to tabbing from the copy/paste that I didn’t bother to change (and that, based on what I’ve seen in other repos, is more in line with Ruby best practices anyway). It’s not clear to me what would have caused Ruby to change what host it listens on, although based on what now appears in the logs that was the problem. I didn’t keep the original fly-deploy branch, so if there was a relevant change there it’s not going to be available by looking at a git diff.