The New Launch

Hi! We’ve been reworking the fly launch experience for a while.
It’s been in a public preview state for a little bit, but it finally got released to everyone as of flyctl v0.1.123.

The main change here is how you specify what you want from your app.
In the old fly launch, it would ask you a bunch of questions one-after-the-other, with no indication of how much more you’d have to configure. It’s a natural evolution of improvements and more features to the platform, but it’s gotten unwieldy. Even with all these questions, there are still a fair few cases where the app doesn’t work out of the box, which means there isn’t enough configuration!

Our primary solution to this is to come up with really good defaults. We’ll name the app after the parent directory, give you a good default machine, try to detect whether your app uses any of the databases we can run, etc. If we get it right, you just confirm that, and it’ll deploy everything. If not, you’re thrown into a web page that exposes the same configuration options from the launch you’re used to, and a little bit more.

Please note that as soon as you confirm your settings on the Launch UI, it’ll launch and deploy your application. If you don’t want to immediately deploy, you can pass --no-deploy to the launch command.

If you’re running flyctl in an automated way, such as with CI, it should work just as it has before (aside from --reuse-app, which was removed). Any deviation from that is a bug, and we’d really appreciate a bug report so we could make that work for you. This is a complete rewrite of the launch command, so even with extensive testing, I expect there could be a couple things lurking around that don’t behave exactly as they did before.

We’re hoping this makes launching new apps on Fly easier and less error-prone. If you have any issues or feedback for this change, I’d love to hear it. Thanks!

There’s a slight bug in name generation that came from the chaos of getting all this merged. It doesn’t currently pull names from the working directory, and it lies about how it derived the app name it’s using. This will be fixed in v0.1.125


Hi, I’ve noticed that before I could launch an app with the same name as an existing one in my organization, but now if I try to do it, the new app name changes auto. Also it now defaults to 1GB RAM, which I assume is out of the Free allowance group?

1 Like

I am experiencing a bug, running version fly v0.1.131 darwin/arm64 Commit: b530c016ec97c797ed68a9842796034eb157b883-dirty BuildDate: 2023-12-01T20:01:40Z

When creating a new NodeJS app, it assumes that I want to create an app on my personal account instead of within the organization that I primarily work in. So I indicate that I want to change the default settings, I get the web UI (whyyyy? why the web? what was wrong with the cli???), I change to the organization, and I disable the Postgres db option.

Even though I disabled Postgres, it goes ahead and creates a new db app and links it to my new project :man_shrugging:

I am honestly so perplexed why you would introduce a web browser window as the default for changing settings when launching an app. Fly was always cli first and that’s what made me fall in love with it. I can do everything from the cli, easily and without looking up documentation.

Well, I could… now I have to switch to the browser just to modify the defaults.

And honestly, guessing if I want to make the new project personal or part of an organization is really nonsensical. At least that should have been left as a choice when running fly launch.

Sigh… I’m so frustrated with the new experience :frowning:

1 Like

If you run fly launch with -o <ORG_SLUG> does the problem still occur?

The org slug can be found with fly orgs list; it’s typically the org name in lower case with spaces changed to dashes.

Sorry the experience has been a bit lackluster for you.

First thing’s first: are you trying to deploy an app written with a framework we recognize and have special handling for (e.g. rails)? This will help me debug the postgres issue, that definitely shouldn’t be happening!

Our rationale for moving to a web-based Launch UI is that the existing setup process was getting to be a bit cumbersome. You get this huge list of questions you have to answer, with no indication of how many are remaining, and if you mess something up you have to restart from scratch. We could make some of this better from the command line, but honestly, it’s an uphill battle making the interactive UX good here. That’s the thinking that led us to the web form here: love it or hate it, the web’s pretty optimized for data entry (and validation, and accessibility).

And honestly, guessing if I want to make the new project personal or part of an organization is really nonsensical. At least that should have been left as a choice when running fly launch.

Hmm, we can probably make this better, but we’ll have to see if it impedes the flow of the average launch. Thanks for the feedback!

Please do note that you can still launch an app entirely from the command line. It’s doesn’t ask you questions, but if you run fly launch --help you get every configuration option you could ever want! In this case, fly launch --org <orgname> will specify the organization.

You can also enable shell completion to allow tab-completion of these parameters.