Heroku alternatives for Rails projects: Deploying my shit to fly.io

I like to develop production projects and side projects as deployment-driven as possible. Over the years I had tons of projects on Heroku and I'm grateful for the experience 🙏 But if tons of projects are to come again, I don't see a point in paying 7$ bucks per side-project.

Luckily Heroku seems to be coming up with a 5$ bucks plan that gives you 1000 hours across multiple Dynos, so I won't migrate my existing projects away for now and pay the 5 bucks, no questions asked.

But for my new side projects, I'm checking out alternatives cause after the 1k hours I would need to pay 7$ per project monthly just for my own enjoyment...

Enter new project

So I had a very simple app set up locally in a state that was workable for me as an admin and for my 0.5 users, it's now online here:

It had 1 public controller, and 2 resources with admin controllers hidden behind basic auth, so just an app for someone to manage some data.

It was time to deploy (actually it was already pretty late, I would have deployed earlier, but I knew that this would be the project where I'll play around with an alternative).

I already heard colleagues mentioning fly.io and when deploy was due for my new shiny app I did another round of Reddit research. And again, lots of fly.io so here we are.

Things I wasn't sure about initially:

how much time will this be?

I ran into a couple of issues, all in all it took me around an hour. Overall, it's just a couple of commands for a really fresh Rails app, all configuration is taken care of.

"shit I need to dive into Docker"

$ fly launch sets up a Docker file, so no additional digging needed here. Not sure if that stays like this in the longterm when your app is growing...

The command creates:

Dockerfile
fly.toml
.dockerignore

So I guess you can configure your own freestyle from there.

Things I'm still not sure about:

how free is it really?

Didn't find it anywhere, but someone on Reddit mentioned a 5$ cap, which should be plenty for hobby apps. fly.io says, "you can keep it free as long as you want", whatever that means.

automating CI and CD?

For Continous Deployment/Delivery: Heroku was built with just that in mind, you change your mainline in the heroku repo, i. e. push your code, which updates the code and the project package on your production machine automatically. So sweet.

Heroku had also "pipelines" for Continuous Integration stuff.

For fly.io this will need additional configuration, like configuring GitHub actions with the fly.io CLI (which is really nice to work with by the way).

monitoring capabilities?

In Heroku, if you want to know anything about your app (apart from logs) you need to Pay for a higher plan than the free plan.

The fly.io dashboard has monitoring, metrics, and logging, all in one place. You'll also get some advanced Grafana metrics out-of-the-box

Issues I ran into with the first deploy

I think it's natural for every new PaaS tool to have a bit of a learning curve. Here are a couple of things I needed to understand to get my newest goo code to fly.

Error 1 - Error Failed attaching db to the Postgres cluster - no such host

When setting up the app, I got an error at the end:

$ fly launch

... lots of output ...

Error Failed attaching developer-pursuit-db to the Postgres cluster developer-pursuit: Get "http://developer-pursuit-db.internal:5500/commands/databases/developer_pursuit": dial: lookup developer-pursuit-db.internal. on fdaa:0:c09a::3: no such host.\nTry attaching manually with 'fly postgres attach --app developer-pursuit developer-pursuit-db'

This seems to be a transient fly.io issue from what I've read on their forum. It can be fixed with the terminal command that's suggested in the error message:

$ fly postgres attach --app developer-pursuit developer-pursuit-db

Error 2 - Failed due to unhealthy allocations

$ fly deploy

... lots of output ...

--> v1 failed - Failed due to unhealthy allocations - no stable job version to auto revert to and deploying as v2 

That was a nasty one. There's a bit of a cryptic error when your app fails after booting.

The fly.io docs first point to PORT issues, but checking the env configs, port looked just fine:

$ fly configs

Environment variables
NAME VALUE 
PORT 8080  

After a bit of despair, I reached for the $ fly logs command and saw the actual stack trace of the Rails app which pointed to an unset ENV variables that I was using for... 🥁 ... Basic auth 🎉

I've set the variables with the $ fly secrets utility and the app ran just fine.

Conclusion

The overall experience is very good. It sucks to run into cryptic errors when you first try things out, but this was all reasonable and solvable with a bit of thinking and research.

The command line feels very nice and similar to heroku so far.

Configs are served for you automagically and you are in full control of the deploy, but if you don't automate it via GitHub actions or similar, you will mess things up eventually. But that's additional work...

I'll probably stick for my old projects with Heroku for the 5$ bucks per 1k hours and generally fallback to fly.io for new projects.

If you have any comments or questions:

Other stuff? Just tweet it out to me!