We are building a GitHub Launch UI in public

Fresh Produce
,
1

tl;dr:

  • We are working on a dashboard UI to ship customer’s GitHub repos
  • It is a work in progress at very early stage, currently supporting only NodeJS repos.
  • We will post updates here, in Fresh Produce.

One of the most common things folks ask is about launching apps using our dashboard. We are excited to share, that’s something we’re actively building right now!

This is still waaay early in its development life so right now, we only support deploying NodeJS apps from the dashboard!

How to use it RIGHT NOW?

If you’re eager to test it you can go to https://fly.io/dashboard/personal/new to launch a NodeJS app from your GitHub repo. We are actively working on this, and you can expect support for more runtimes/frameworks soon (it’s worth mentioning our NextJS/NuxtJS are separate from the regular NodeJS one).

If you don’t have a NodeJS app, you can also try out deploying fly-apps/ollama-open-webui, which will deploy Ollama’s web UI to Fly.io for you.

If you don’t have a GitHub account linked to your Fly account you can press a button to link them together immediately. We currently only show this UI to customers with GitHub identity attached, but we plan on adding support to customers without GH SSO on the future.

Why start with NodeJS?

Quite simple, because I understand a lot of NodeJS Fly :heart: NodeJS so our @flydotio/dockerfile generator does a lot of the heavy lifting therefore we could focus on the UI and the behind scenes stuff for the first version.

How does this work (feel free to skip if you don’t like nerdy details)

tl;dr: Machines API, really!

When you press “Deploy” we create a machine with a Deployer Docker Image we built around flyctl that receives some envs such as DEPLOY_APP_NAME and DEPLOY_APP_PORT . Then we run fly launch and fly deploy. We are literally doing what you’d otherwise do in your computer but inside a Fly Machine.

  1. Create [deployer app] in a private network that only this app has access to.
  2. Set secrets to [deployer app]
  3. Create [deployer machine] inside [deployer app] using auto_destroy feature.
  4. Our Elixir app Listen to logs from QuickWit via Oban to get the current state of the deployment.
  5. When [deployer machine] exits we check if the exit code was 0 or 1 to declare a success or failure.

As step [4] mentions, we keep listening to logs via QuickWit (our extension partner) to get the most up to date state of the deployment. That works very well for us.

What’s next for us?

Currently, our Deployer Docker Image comes along with support for NodeJS. Before this is generally available for more apps we need to add support to more runtimes such as Elixir, Ruby, Laravel etc.

Also you will be a huge part of the deciding factor on how this project goes. Your feedback will help shape this since we are very early into it, we’d love to hear from you!

15 Likes
2

Nice. Seems like I’ll retire https://flycd.dev/ soon :sunglasses:

5 Likes
3

Hi @pmbanugo

I realize this might feel bad since it we are indeed moving in that direction of making a CD inside our platform (as you guessed) and you already built yours. We would love your feedback with the upcoming fresh produces if possible, the approach you took (looking at the Loom demo) has a very nice UX!

1 Like
4

Awesome feature!

Hopefully for the self hosters Gitlab support in the future?

2 Likes
5

And cloud bitbucket too)

6

Please can you also add support for the cross platform .net runtime as well :pray:

7

@Giovanni @lotarbo we definitely want to support more Git providers. For now we are focusing on GitHub up to a point were we can say we are comfortable with all the details so its gonna be simpler to add more providers so lets see how that goes!

@solrevdev duly noted, in the feature we want all-the-things to work flawlessly on our UI launcher.

1 Like
8

Thank you @lubien :pray:t3:

Lack of talent aside if I can help let me know.

Cheers
John

9

There’s actually a good way you can help. Let us know some public repo you have that is .net based so we can add to our reference repos when we start adding support to it :pray:

1 Like
10

@lubien Will do.

For now, I only have an old example of hosting a Blazor WebAssembly frontend on Vercel and the .NET backend on Fly.io, but it’s outdated. I’ll update it when I have time.

I’ll definitely create some .NET 8 (the LTS version) examples on GitHub for you.

I’ll reply with links once done…

11

Suggestion: start a new thread. I can help.

In order for us to provide basic support, all we need is to know how best to detect a Blazor app, and what a Dockerfile would look like that would deploy it.

Full support would be working through relational database, object storage, and websocket issues.

12

Can I just add that should support more than just blazor.

While that was my mentioned initial repo .net is also mvc based web apps, razor pages and minimal api endpoints for example.

All .net projects have a .csproj file and often a .sln file for multi .csproj projects and it would be nice to support .net natively without a docker file as in my original example

Thanks :pray:
John

1 Like
13

Is the deployer repo public? Maybe the docker image or dockerfile set up?

14

It is! It’s just flyctl + a script

We are working on this branch and eventually we will figure merging into main

1 Like
15

No way to deploy using the Dockerfile that already exists in the repo?

16

It will use it.

If you’re referring to the dockerfile I posted before it’s just the image of the machine that deploys your app (our inner infra thing) but when you use our launch UI to deploy your repo we run fly launch which will use your dockerfile properly.

Does this help?

17

hm. when I select a repo that has a Dockerfile, and I click on “Deploy repository”, it detects a Rails application and installs RVM and a bunch of other stuff that shouldn’t be required to deploy a Docker container.

18

I’ve just made changes to the deployer to skip installing Ruby and other dependencies if the Rails app already has a Dockerfile. Thanks for your feedback!

19

That’s not working for the Laravel app. Do I need some configuration?