I’m migrating everything over from Heroku to Fly (Rails app, Sidekiq, Postgres, Redis…) and I’m realizing how much Heroku was automating certain concerns.
For example, on Fly, do I need to install a service manager to watch and restart Rails if it crashes or takes up too much memory? Will the VM simply crash if OOM happens?
Do I need to manually set up log rotation?
Essentially, I’m unclear how much “magic” Fly is doing for me regarding basic server admin stuff. ?
Welcome!
I’ll answer your specific questions before going into the “magic”.
If Rails crashes, it will crash the VM and the VM will automatically be restarted. If it crashes too much within a certain interval it will be marked as “dead”.
Yes, and will be restarted.
If you’re logging to disk, then you’ll have to manage that. If you’re logging to stdout and stderr, then you don’t have to do anything. We manage a large log cluster.
All you should have to worry about is contained within your own app. We should do enough for you not to care about most things outside of your app.
a service manager to watch and restart Rails if it crashes or takes up too much memory?
You could if you want to, but Fly will restart your app once its entrypoint process crashes (the process started by Fly’s init). You would have to use a ‘service manager’ / supervisor when running multiple processes per Fly app however.
Will the VM simply crash if OOM happens?
Yes.
Do I need to manually set up log rotation?
Fly doesn’t yet have a fully-managed log sink, so you’d have to use an external service like logdna (with fly-log-shipper) for instance, and set up its agents such that they would periodically clean-up logs, for you.
I’m migrating everything over from Heroku to Fly (Rails app, Sidekiq, Postgres, Redis…)
Fly should consider writing Heroku to Fly app guides.
Essentially, I’m unclear how much “magic” Fly is doing for me regarding basic server admin stuff?
If you’re aiming for zero devops, I’d say railway.app is more closer to Heroku than Fly is, at this point in time.