Rails deploy fails with EOF errors

Hi, all, thanks in advance for any help.

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, :cooking:.]

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.

Hope this helps move things forward a little!

1 Like

I actually don’t see an error in the log, just litestream being chatty about the actions it is taking.

2 Likes

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 guess I was unclear. The above does not look like an error to me. On first launch, litestream starts fresh as there was no previous data.

Perhaps the real problem is that Rails is listening only on localhost?

Is there an Nginx server as well, by default? (That used to be commonplace, if I remember the oldentimes correctly…)


Aside: If not, then it would be best to just have Rails listen directly on 0.0.0.0, of course.

1 Like

So…it works now?

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.

1 Like