So having been distracted by other things I completely missed that Fly are deprecating their previous offering (now known as Fly Apps v1). An automated migration happened while I was no wiser and it was only when a database connection broke down that I found out what was happening. It was a bit frustrating but one of the good things about Fly is the fact that I’m currently paying zero dollars for my apps just like my old Heroku setup which makes it perfect for hobby experimentation.

The basics of migrating are not complicated, the configuration file for deployment is slightly different and you now need to associate a Fly Machine (a virtual machine) to the application. Running the migration command flyctl migrate-to-v2 successfully did that for me with all my applications.

The use of Machines is a little different from other Platform as a Service (PaaS) that I’ve used before. They are lightweight virtual machines that use the Firecracker system that is used in AWS Lambda and also later Fargate. You need to assign at least one machine to your application for it to run and Fly recommends at least two.

Since your app is already virtualised in a Docker container normally you leave the scheduling of the machines to the service based on the demand you have but this setup gives you a lot more control of the resources that are available for the app to run over. The basics of the technology are already proven on Lambdas.

One of the nice features about Fly Apps v1 is that they were “always on” at no extra cost. Now you need to think a bit more about how you want to allocate the Machines to the application. Fortunately for most hobby projects it is straight-forward, you can set the auto-stop-start configuration and you probably can just use one machine as you’re never really going to need to fallback to another instance. I’ve set a few of my apps to have two machines and kept the others at the default migrated value of one (because that was what you’re running before).

For the cost conscious hobbyist one of the nice aspects of Firecracker VMs is that they are relatively quick to start on demand so while 99% of the time you’re not using anything when you do want to use the app the spinup time for the single machine apps is about that you’d experience with something like a cold AWS Lambda, the two machine apps seem to be quicker to start but that might be a subjective coincidence.

New applications are now configured with two machines by default plus all the logic to leave managing the machine time to the service. I haven’t had enough time with the new default to say whether its better or worse than the previous setup but it does seem better than other spin-down free tiers like Render’s.

Moving to Fly had it’s ups and downs but now I’ve gotten over the learning curve Fly provides everything I wanted from Heroku and also feels like it could be a platform you could grow with if you wanted to do something more serious with.

V2 has also brought some changes to the deployment configuration file, mostly to simplify it for the common case of HTTP-based apps, which seems a good call. You also control whether the new autoscaling functionality applies to your application from the config, this defaults to the most cost-effective options, which seems right to me. However one oddity is that while you can specify the minimum number of machines you want active I’m not sure you can specify a maximum. Instead you need to apply that configuration via the command-line.

This seems a bit inconsistent but there are a ton of other options to allow scaling across regions so maybe the possibilities are not easy to boil down to a simple configuration format. Again though, the common hobbyist’s case is probably can be catered too with more sophisticated setups being configured via the CLI or Terraform.

Having gotten through the migration now I remain happy with the service and I think when spinning up new projects there is more to understand that there was before but the overall service is probably now better and less magical.