So far, all our applications have found their production finale on a dedicated server from the OVH offer or on the excellent service mikr.us created by the well-known Jakub Mrugalski.
This solution had one undeniable plus — we were “self-hosted,” without bothering ourselves with unclear price lists and cost estimates. Unfortunately, this solution implied many drawbacks. Above all, we had to take care of the hardware’s security, system updates on the server, and firewall rules. Moreover, passing knowledge within the team about how to administer the system and how the infrastructure was built also became cumbersome.
We made the decision to move to the cloud! The tedious search for the right solution for us began. After reviewing the offerings of giants, Fly.io remained on the battlefield.
Fly.io is an American cloud solutions provider centralized around the Developer experience. Here, we won’t encounter complicated services with unknown names or unclear pricing.
So far, our deployment process relied on Docker containers built through Github Actions. Initially, our environments were represented by appropriate docker-compose files. Unfortunately, this approach proved impossible to implement in the case of Fly. We began devising a plan on how to migrate our applications.
We split our docker-compose files into individual applications in separate repositories. Then, according to the documentation, each application received a dedicated fly.toml file, where we define the application’s name, watchdog rules, and related services.
app = "backend"
[[services]]
internal_port = 5000
protocol = "tcp"
[services.concurrency]
hard_limit = 25
soft_limit = 20
[[services.ports]]
handlers = ["http"]
port = "80"
[[services.ports]]
handlers = ["tls", "http"]
port = "443"
[[services.tcp_checks]]
interval = 10000
timeout = 2000
[mounts]
source="files_volume"
destination="/files"
The next step was to modify the Github Actions pipeline for deployment.
Sample Github flow:
name: Fly Deploy
on:
push:
branches:
- main
env:
FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
jobs:
deploy:
name: Deploy app
runs-on: self-hosted
steps:
- uses: actions/checkout@v3
- uses: superfly/flyctl-actions/setup-flyctl@master
- run: flyctl deploy --remote-only
And that’s it!
Really, that’s it :) Fly will take care of finding the Dockerfile, building the image, and then running it on the swap slot. Simple, isn’t it?
Another aspect we fell in love with at Fly. Right after deploying the application, we get access to Grafana, where we can view basic metrics such as response time or network traffic. Additionally, we can push our own metrics through Prometheus.
The interface available through the browser provides minimalist impressions — there’s not much we can do. Claws will only appear when we explore the console interface - flyctl.
Thanks to it, interaction with the cloud takes place; we can, among other things, restart the application or scale it up or down. However, what won our hearts was the ability to redirect any port of our application to the local computer, practically the same as in Docker.
The command line will also allow us to immerse ourselves in the container via SSH or view logs using the flyctl logs command.
We also get a free secret storage service. It’s not as extensive as, for example, Azure Vault, but it does its job. Secrets are injected into the application container as environment variables, which can be used in our application.
A definite Gamechanger!
All our projects using a relational database have Postgres under the hood.
And here, too, Fly.io comes to our aid, providing a PostgreSQL cluster that we can manage in any way. Among other things, we can dynamically scale the amount of resources and nodes. Additionally, we have the option to run TimescaleDB.
Definitely yes! Despite the initial difficulties associated with changing the architecture, we achieved a scalable and stable environment, without worrying about infrastructure and costs (which are relatively low for a cloud solution). Of course, in this honey jar, there is a spoon of tar. Fly.io is not a solution that excels in good support from the manufacturer. Fortunately, in return, we get very good documentation and a community forum.
Fly.io is definitely a good alternative if we are looking for a cloud that won’t overwhelm us with a multitude of features and a complicated price list based on estimates. In return, however, we must be convinced to manage from the command line and the lack of technical support other than the community.
