Fly.io has been the quickest, and most efficient platform I’ve used in such a long time. I’ve been around the game for a little while now and have been very used to using a docker workflow both for building applications and, also gaining access to lab environments. At my security job we would do a local ubuntu or local kali linux image to run certain scripts.
I’ve messed around with all the major cloud providers, AWS, GCP, and Azure. I’ve used the serverless framework and messed around with kubernetes a bunch even building a company with kubernetes to begin with.
When I go about building an application and deploying it a lot of my thought goes into how is it being packaged. Do I need a binary, just a zipfile with instructions, etc To that end early on I started using docker since it promised reproducible builds everywhere and that was really appealing.
The Journey
I’d say fly encapsulates the concept of GTFOL perfectly. So often would I be at a hackathon or just making a small little tool for my personal usage and if I wanted to make it available for public usage it was such a pain. I remember distinctly one 24 hour hackathon I did the summer of 2020 where I had spent 20 hours building my app and had it working perfectly on my computer, and my teammates laptop all packaged in a docker container. Now I simply wanted to put that docker container on the cloud and let it be publically accessible. This seems like a natural progression to me especially with small projects and beginnings. From there I wanted to use the free GCP credits we got for the event and put it on their platform. Immediately I was overwhelmed with the huge amount of documentation, and the cumbersome nature of the user interface. 10 minutes into it, I had a ton of different tabs open with documentation and different inceptioned screens on their dashboard. I eventually got it to work, but it felt like I did it wrong, and I wasn’t totally sure I could recreate.
The Kubernetes Rabbithole
Kubernetes was the next behemoth that I undertook. Kubernetes made a lot of sense to me conceptually. I felt like I understood the entire thing a lot more easily than a cloud provider like AWS where there’s a bunch of vendor lock-in terminology. Everything was a pod and that usually translated to a container. You could network the cluster together, add storage, and expose it to the public. Ok, this seems promising, and it’s a fairly quick translation over from Docker images. There were also operators and custom resource definitions, but I didn’t get too far into that side. I ended up starting a company in the fall of 2021, and we structured most of our infrastructure using k8s with an EKS cluster. K8s still has a place in my heart as a system that makes a lot of sense, but it was just too much overhead to manage. There was a decent learning curve for other members of the team who weren’t familiar, and I was spending a lot of the time debugging deployments. At such a small scale it just didn’t make sense to have the overhead. We didn’t need to scale that much, and the time I spent managing the cluster was probably the same I needed to learn the managed services within AWS itself.
The Promised Land
Flashforward to 2023 where I’m working on building an LLM based chatbot on
discord at Plastic Labs. The application was super simple. Just a few python
scripts in a folder. The docker container was simple too just a python
environment that installed the dependencies with pip and ran the entrypoint
script. I got the bot running locally, but couldn’t just keep my laptop running
at all hours, so I wanted to deploy it the cloud. I didn’t want to make the
mistake of setting up a cluster again as most of the team wasn’t technical, and
it was just overkill for one container. I started messing around with AWS’s
Elastic Container Service and going through their documentation, but everything
just felt cumbersome, and I was setting up a bunch of different resources and
IAM idenities all to get a single container running.
I decided to do some research on other platforms and remembered seeing Fly.io. I
had been getting ads for their platform for a few years now and decided to give
it a try to see how well it worked. They advertised themselves as simply running
docker containers as VMs. Okay that seems simple enough for my needs. I created
and account and opened up their documentation. The first thing that struck me
was that they had something called a speedrun
mode. Now years of looking at READMEs and getting started guides made me a
little skeptical, but I was immediately proven wrong. Basically just the fly launch command was all I ran, and I had my app up and running, no fuss. A few
hours of research and trying to get up and running with ECS felt like such a
waste after the 2-minute process of getting a fly vm up and running.
This is what I’ve been looking for! No fancy bells and whistles and weird re-skinnings of open source tools. Just take my docker image and deploy it somewhere publically accessible. The product spoke for itself, and I loved it. Over the last year I’ve become a huge stan for Fly. Their developer blogs are great and even if they aren’t relevant at all to anything I’m working on they, are always fun to read. They released Gossip Glomers which were really fun. The community forum was super welcoming and fast to respond to questions I had. They just felt like they were made for an engineer to use. Not so some sales person could go to an executive at a large corporation who forces the engineers to use a product that they don’t want to use.
Fly was amazing, but then it kept getting better.
- They exposed their logging and made it super easy to ship logs
- They gave us free sentry error tracking for a year
- And now they are integrating with supabase for managed databases.
The Caveats
Although the initial experience with fly is incredible and a great springboard to take your application out of localhost there are some growing pains that come when you have more complicated workloads.
The main complaint I’d have is the lack of some kind of translation layer for multi-container or multi-vm deployments. There’s no way to natively go from a docker-compose.yml to a fly deployment. That being said the fly machines api is quite powerful and there’s definitely room to roll up a custom solution, but something built in would be great.
The other complaint is that there are not many team controls. If I want to add different team members with different levels of permissions there’s not a lot of options. The only thing I was able to get from the community was the option of creating a different organization for different visibility layers, but that wasn’t quite what I was looking for.
Fly is the platform I wanted as a tinkerer in high school and college, and I’m incredibly excited to see where it goes from here.