First impressions with and and Gleam

Hi everyone! Yesterday I launched my first application with 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.


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 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.


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 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

  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!


  • 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 launch could 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 detect when an application isn’t listening on the desired port?


Overall I really liked, I think I’m going to use it a bunch in future. Thanks!

1 Like

Thank you for the detailed feedback! This is great.

We present you with a credit card form and an explanation on why we need it right after creating your account. Did you see that? If not we might have a bug that didn’t redirect you correctly. Regardless, this ux is horrible and we’re working on improving it until we ultimately remove the up-front credit card requirement.

Listening on the wrong port or address is a common pitfall. We’ll look through your suggestions and see how we can improve this.

Thanks again!


Hi Michael!

I didn’t notice that, I think I was sent to this page after sign up: Welcome to the Fly Global Application Platform

1 Like

Ah that’s probably the issue. We’ll take a look and see what happened.

1 Like