More runtimes to our GitHub Launch UI!

Fresh Produce
1

We recently announced that We are building a GitHub Launch UI in public but with the caveat that the first supported runtime was only NodeJS. That changes today. We just added support for:

  • Phoenix with Elixir 1.16/1.17 (and compatible repos)
  • Laravel repos
  • Django repos
  • Python repos
  • Golang repos
  • Repos with an existing Dockerfile

Want to use it right now? Go to https://fly.io/dashboard/personal/new.

This is just a small improvement and we are working torwards supporting even more of those, our goal is to support 100% of fly launch supported runtimes in our UI too asap.

The nerdy details (feel free to skip)

Internally we just had to make sure we installed the right dependencies for the right things. When you run flyctl launch locally we can assume you use the correct runtime version you need to run your project. What happens when we don’t know that? We just have to figure it out for you!

Our Elixir flyctl scanner is kinda odd because it immediately runs mix commands as soon as we detect Phoenix to generate a Dockerfile. We don’t generate Phoenix Dockerfiles for you, Phoenix does it using mix phx.gen.release --dockerfile. In our deployer image we did a small trick to check which version of elixir works: mix compile with elixir 1.17 and if it fails fallback to 1.16 and that works surprisingly well.

We like not having to ask much questions and you can just feel the magic but we are not opposed to, in the future, adding a select on our form so you can choose your desired runtime. Elixir and Erlang OTP combinations will make that slightly hard because there’s tons of combinations to be handled so we will eventually have to figure those! We also have other ideas on how to handle it better in the future.

Rails is one of the things on our radar now. Later versions seem close to just work but we found out some shenanigans such as repo bundler version having to be matching the installed bundler’s version. Thankfully in our team we have folks who understand ruby a whole lot better than I and are figuring this one out.

The other runtimes were just boring in a good way: they just worked. Some of our flyctl scanners have reasonable default for just adding some files like .dockerignore and template files like Dockerfile in case you don’t have one already.

I hope y’all liked this update. We are trying to be as detailed in the updates so you can follow what our team is going through. We have more updates incoming anytime soon too so stay tuned.

6 Likes
2

This is super cool! Is automatic deploys when the repo gets new commits on the roadmap?

1 Like
3

You didn’t hear it from me: yes :shushing_face:

4 Likes
4

Possible bug (or, at least, some room for an UX improvement):

If we try to link a GitHub account using a different email address, then it breaks the link flow. For example:

  1. Go to https://fly.io/dashboard/MYORG/new
  2. Click on the “Connect to GitHub” button
  3. Use a GitHub account with a different email address from your Fly account

Current behavior

  1. Displays an “organization not found error”.
  2. Logs out from your Fly account and logs in to an account with your GitHub email address (maybe created a new account? not really sure)

Expected behavior

Ideally, it should allow to link a GitHub account with a different email address but, in case that’s not possible, I think it should display an error like “use the same email address as your Fly account” instead of creating a new Fly account with our GitHub email address.

EDIT: I’ve tried adding the same email address I have on Fly to my GitHub account (and set it as the primary address) but Fly is still using the other email address and logging me out from my main account.

1 Like
5

Thanks for sharing that, we will have to take a close look on this one because what you described is indeed a very confusing UX for anyone who just wants to ship and app!

Spoiler about our current work: We are also considering making the flow to connect apps to repos independent from SSO identities so perhaps we are gonna fix this by not fixing this and doing something else instead too! We’ll have to see.

1 Like
6

Is it possible for an app delivered as a GitHub repo for use by this Launch UI to specify that it needs certain resources like:

  • A Tigris bucket
  • A Supabase database
  • An Upstash Redis database

If so, are there docs available for how to do this?

7

For Laravel repos, does the Launch UI use GitHub - fly-apps/dockerfile-laravel, and if so, is there a way for the GitHub repo to specify flags to pass to that, such as to use an Octane flavor (-o)?

8

It would be great to have an option to set env/secrets keys, so the user can fill the values during the lunch.

1 Like
9

Hi @Alex21 and @gcv thanks for the feedback

Suggesting extensions during launch

One of the improvements we aim to ship this week is using flyctl to scan your repo before you see the form so we know beforehand that you might need a database and possibly more extensions. We haven’t released it yet though!

@Alex21 if I understood that correctly you’d want a simple way to send a person to the Launch UI with some required (or at least highlughted) field for those extensions right? Perhaps adding something to the URL like ?repo=foo/bar&trigris=true? Mind if I ask what’s your use case so we can brainstorm things together too?

Flags to dockerfile-* repos

This is something on our radar but we haven’t added to our roadmap yet but you might just have pushed that conversation into our next team meeting :laughing:.

Envs and secrets during launch

At the very bottom of the launch UI there’s an UI to set secrets and also see already-staged secrets too! @gcv we don’t have an UI for regular envs tho which we might look into later.

10

Secrets are okay. It would be great to have a way to pre-define those secret keys. I have a project that needs three secrets, and even I sometimes forget to add them.

A suggestion could be on the fly.toml something like:

[[launch.secret]]
key = "WHATEVER_KEY"
description = "..."
required = true
2 Likes
11

My use case is I want to create an open source app that people can deploy on their own Fly account. I’m thinking something along the lines of I create a template GitHub repo, and then people can clone that repo and use Fly’s Launch UI to deploy that cloned repo. The app includes CRUD functionality, including uploading files, so needs a database and an S3 bucket. I think what would be most straightforward from my perspective is if it were possible for fly.toml to specify that the app needs a Supabase db and a Tigris bucket, and then when someone uses the Launch UI to launch from a repo whose fly.toml specifies that it needs those resources, then for the Launch UI to provision them along with the Machine(s) and set any required secrets accordingly. That way, from the perspective of the person using the Launch UI, they don’t have to provision a bunch of things themselves, all they need to do is launch the app.

If adding Supabase, Tigris, etc. resources to fly.toml isn’t on the roadmap anytime soon, your URL idea would also be a perfectly fine option.

Thanks again for creating the Launch UI and continuing to improve it. You’re getting closer and closer to 1-click installs that anyone can create and share, which is awesome!

2 Likes
12

Thanks for putting your time on explaining that and having this sort of 1-click deployment kind of thing is a great to have. Our current roadmap focuses on continuous deployment for now but we will keep those closely in mind as its a long requested feature and we are closer now to it with the launch UI.

13

Thanks, @lubien. It makes sense to prioritize the CD use case ahead of the 1-click install use case. Even the 1-click install use case needs CD in order to keep the deployed app secure (e.g., the cloned repo in my example would include Dependabot configuration).

1 Like