Hi everyone! Yesterday I launched my first application with Fly.io. It was really impressed with the experience overall, but I hit a few UX snags that I thought could be improved a little, so I thought I’d share my experience.
Context
I’m an experienced programmer and web app deployment type person with professional experience with lots of different deployment tech.
The application I’m deployed is a tiny example web app written in Gleam, a language for which Fly.io doesn’t have any built-in support.
I dived straight in and followed the “get started” link on the homepage and then doing the “speedrun” guide to try and get the app live as quickly as possible.
Best bits
I really liked the flow from the home page, installing the CLI, signing up, and then to the deployment guides. It’s really nice how it keeps you focused on getting something online and didn’t dump you to an empty dashboard unlike most platforms.
I really liked how there were multiple paths you could take depending on how much context you had or how much reading about the platform you wanted to do before deploying.
The CLI is really slick, and it’s fab how quickly the build->deploy cycle is for docker. I didn’t test the other runtimes.
Snag 1: Payment requirement UX
After installing flyctl and authenticating I ran flyctl launch. I was getting quite excited putting in the app name and region, but then I rather suddenly got a bold red error message in my console saying this:
ERROR We need your payment information to continue!
This is a perfectly reasonable requirement, but having it then and with big red ERROR text was rather jarring, it didn’t feel very good, especially as it wasn’t mentioned in the speedrun documentation at all.
Suggestion
I think this could feel a lot nicer if it was presented with a more friendly tone as a normal step in the process, rather than an abrupt halt with a message labelled ERROR.
Snag 2: Deployment hanging
After successfully running flyctl launch my image built and I was shown the deployment UI as it waited for my instance to be detected as healthy. Not knowing how long Fly.io takes I waited several minutes before assuming that either flyctl had frozen or my deployment had failed.
ctrl-cing the launch terminal command I guessed that flyctl logs might show the logs (which it did, nice UX there) and I was able to see that my application had printed that it was online.
My first thought was that it’s probably listening on the wrong port, so I decided to check the documentation for information on what port to use. I couldn’t find any documentation on OCI container based apps so I opted to read the documentation for Go (as Go is very simple).
The Go source code on the page in question seemed very promising:
func main() {
port := os.Getenv("PORT") // <-- This must be what I need
if port == "" {
port = "8080"
}
// ... snip
log.Fatal(http.ListenAndServe(":"+port, nil))
}
My application doesn’t check the PORT variable, but the Go example does. I think that must be the issue so I make the application check the variable and re-run the launch command. Unfortunately it doesn’t work.
I wander around the documentation, not entirely sure what I’m looking for. After a few minutes I open up the generated fly.toml and notice this
[[services]]
http_checks = []
internal_port = 8080 # <-- Aha!
processes = ["app"]
protocol = "tcp"
script_checks = []
Once edited to match the port my application defaults to then everything worked, fab!
Suggestions
- Some indicator that something may be awry when a deployment takes a long time could be useful as newbies don’t know if it should take 1 minute or 15 to deploy.
- Perhaps
flyctl launchcould ask which port your application listens on rather than defaulting to 8080. - A “Run a dockerised app” section in the docs could be helpful for people to go-to first when not using one of the first-class languages.
- Could Fly.io detect when an application isn’t listening on the desired port?
Fin
Overall I really liked Fly.io, I think I’m going to use it a bunch in future. Thanks!