Why I left Fly.io for Heroku

Fly.io seemed like a promising way to save some cash getting my hobby-level Rails app deployed. What’s so complicated about getting a full stack application deployed all over the world in just a few clicks? Why would Heroku charge $17 a month just to get something simple out there?! When they got rid of their free tier, a hole opened up in the market big enough for seemingly dozens of alternatives to attempt to capitalize on. I grew tired of having to look into yet-another-heroku-alternative that someone posted about. Well, when I actually sat down to get rememberjournal.app deployed, I was looking at some of these price comparisons and loved the idea of paying under $5 a month with something like fly.io.

I decided to invest the time in learning a new platform. I probably invested around 10 hours in understanding enough about how Fly works to get my app deployed and iron out most of the kinks. There were several little things that I had to get used to. Fly was docker based so their deployment actions and config was different and more involved for me. Their server logging was not as nice. Their metrics seemed really buggy. All around it didn’t feel like a very mature solution.

The most confusing thing was needing to deploy a separate Fly app to run my postgres instance. Fly does not manage postgres for you. They provide some rudimentary backups, but its nothing compared to the managed postgres you get with Heroku. Fly is currently working on a managed postgres integration with a third party since they now have a user base of Heroku refugees, but it’s looking like their lowest tier will be $38/month!

So, if I don’t want to pay for their managed postgres, I’m stuck with the unmanaged version, which means if my postgres instance blows up, I’m in charge of getting it up and running again. It means if I want more than 5 days of backups, I need to manually manage that as well. This isn’t an appealing option for me since my side project is going to contain years of precious journal entries. I want lots of insurance that my data is safe.

The other thing that really pushed me over the edge with the postgres instance was a strange bug I was seeing where my server would blow up upon its first request in a while. I think the problem was caused by the fact that the postgres fly app was falling asleep but the web app was always running. I researched it for a while but there was no clear answer on how to get the two Fly applications more synchronized in their config. I’m sure there is a simple answer to this mystery, but this one small issue demonstrates the crux of the problem for me: I don’t want to have to manage my database. I don’t want to be in charge of making sure my database is talking to my web app correctly. The reason I don’t want to be in charge of that is because there are great platforms out there that will do it for me—like Heroku.

So, if I want to have a managed database, it’s looking like Fly is going to be costing me quite a bit more than Heroku (when they finalize their solution), at least at the hobby level. If cost is the main reason I used Fly in the first place, now I’ll just have the worst of both worlds. So, it’s time to go back home. Sometimes the industry standard is that for a reason.