I saw that too -- I think it's a typo in the OP, that the code is what they intended to recommend, and the comment is wrong.
Standard heroku Rails deploy instructions are to turn on `RAILS_SERVE_STATIC_FILES` but also to put a CDN in front of it.
My guess is this is what fly.io is meaning to recommend too. But... yeah, they oughta fix this! A flaw in an otherwise very well-written and well-edited article, how'd it slip through copy editing?
Open a PR! This will fix the problem if its a bug/oversight or if its intended to be that way, force somebody to comment on it for a future person who is puzzled by this choice.
It's intended. Yes serving static files from Ruby is slower than from nginx or whatever, but you'd need to embed nginx in the image and run both processes etc.
The assumption here is that there is a caching proxy in front of the container, so Rails will only serve each assets once, so performance isn't critical.
I am not sure which they intended, but the problem is that the comment doesn't match the code:
> RAILS_SERVE_STATIC_FILES="true"
> RAILS_SERVE_STATIC_FILES - This instructs Rails to not serve static files
That is not what it does when you put `="true"`, nope.
In fact both, settings are common. On heroku you typically use `RAILS_SERVE_STATIC_FILES="true"` but put a CDN in front. But other people do false and have eg nginx serving them. If this is what fly.io means you to do... where is the nginx, not mentioned in the tutorial?
Whichever they intend to do, their code does not match their narrative of what it does.
...but... it's set to True....