Fly Apps on machine prerelease

Instructions that involve fly machine ... commands are temporary. What’s going away are these commands. They, or something similar, will come back when we figure out the right UX:

  • fly scale count
  • fly regions ...
  • fly autoscale

These cause endless pain, because they don’t behave the way people expect. fly machine clone doesn’t surprise people, and is a decent stand in for now.


Thank you for paying attention. I am glad to hear it.

i’d argue againt deprecating it, I love these commands, add a region, increase the scale count and autoscale ratio. The main reason I came to fly was because of these commands, you get a hang of it after tinkering with the comands for a while.

Absolutely loath the fly machine commands!

I would be fine with something like fly apps scale count [number] [region] that simply does fly machine clone under the hood for me as we have plenty of apps that are ephemeral and don’t care which VMs get created / deleted.

It would be a negative experience to take away fly scale count and have no replacement for it as it’s quite useful for quickly scaling by running a single command. Having to run multiple commands many times in order to get the same functionality is, in my opinion, a step back in developer experience.

Yeah this is roughly what we’re after. The awkward part is multi process apps. Right now we have:

fly scale count web=3 worker=10

We can probably make that work just by checking the region of existing machines. If they’re all the same, we can infer that’s the right region.

Does this make sense to do when we can’t infer the region?

fly scale count web=2 worker=10 --region=syd

@ignoramous when’s the last time you had a lease issue? Are you doing deploys that take longer than 30m? This stuff has all basically been rewritten since December, so pre December behavior has changed.

We’re planning to make fly machine stop <name> work, but not until we get this first release out. Machine IDs actually include routing information, so we know exactly which hardware to send a stop command to. Using names is going to take a little bit of infrastructure work.

1 Like

That makes sense, though inferring the region will have to work consistently otherwise it could be a jarring experience. I can’t speak too much for multi process apps as we don’t use them (mainly due to limitations around things like internal DNS).

Maybe the distribution of vms across regions could be a config. By default it’s even distribution across all specified regions (e.g. regions: [syd, sin, nrt] and region_placement: balanced results in a scale count of 9 placing 3 vms in each region) but there’s also the option of having per region (e.g. regions: [syd, sin, nrt] and region_placement: per_region results in being able to set the scale count to 5 for syd, 3 for sin, and 1 for nrt.

The last time I tried rolling was in Sep/Oct, 2022. Haven’t tried after.

Thanks for the heads-up. I’ll try again with the latest flyctl and the default strat (rolling) once the builders are up (having trouble deploying right now).

Error failed to fetch an image or build from source: error connecting to docker: You hit a Fly API error with request ID: 01GRDQDGTJMF9QFPXXFNH3EQ61-maa

Gotcha. I was wondering if flyctl can loop through machine names and substitute them for IDs. Back when I was looked at the code last year, it seemed do-able; but the flyctl code base has been through a lot since then.

Update: Kurt, the rewrite has made things better! rolling deploy works just fine for an app with 30+ machines using flyctl-0.0.451.

Waaaait a minute…

So you’re saying…

I can finally have an app with 8 shared cores and 2GB of RAM?


1 Like

So I created a new app from scratch using fly launch and presumably this should have created a v2 app?

Then tried to add 8 shared cores via the dashboard but got this error:

I contacted yesterday but didn’t get a response.

So I tried with the CLI but fly machines list says No machines are available on this app so I can’t use fly machines update. Although from the first post on this thread using fly launch should have created a new machine?

Yesterday I used fly v0.0.464 to create the app. I’ve just updated to fly v0.0.473 and will try again.


Same result with fly v0.0.473.


So I RTFM and tried fly launch --force-machines and then even fly deploy --force-machines. Still no machines…

No machines are available on this app
1 Like

You’d still get a Nomad (V1) app as of today, unless you used --force-machines with fly launch (or fly deploy, if you didn’t deploy straight from fly launch).

Right now there’s a manual step to enable you to create dedicated VMs. We’re working on making that a smoother experience while keeping a grip on the amount of compute abuse.


I updated my previous post but I did try with fly launch --force-machines and then fly launch --force-machines.

I still get Platform = nomad.


Maybe it’s because I’m not deploying when launching?

I need to set up some secrets for the app to work. Would be great if I could do that when launching!


It worked now!

I think the only thing I changed was turning off Docker desktop and building with the Fly builder?

:thinking: If you can reproduce, we’d love a bug report on flyctl GitHub - superfly/flyctl: Command line tools for services

I will try to reproduce and file a bug if that’s the case.


The dashboard and fly status don’t show the same info for machines.

4d891159b55987	app    	1      	dfw   	started	1 total, 1 passing	2023-03-01T15:26:36Z

Also, I created the app in QRO but apparently the machine was deployed to DFW. Not sure why since QRO is much closer to me.


So I created a new app with Docker desktop and it worked. Not sure what happened before.

Now the dashboard and the CLI do show the same machine ID but still the machine was deployed to DFW instead of QRO. The app was configured in QRO:

Region Pool:


Regarding the discrepancy between the dashboard and the CLI. I’m an idiot. I was looking at another app. Sorry.


Apps V2 doesn’t use region pool. Machines VMs are tied to hardware, so you specify the region for each one. To note: Apps V2 isn’t fully cooked. Bug reports are welcome for unexpected UX!

1 Like

BTW I have to say that v2 apps are fast! :heart_eyes:

The builder launches super fast, it feels as if I was using Docker desktop. Same with deploying and managing.



With the announcement in Make Apps V2 the default for new apps in your org, is there any capability related to appsv2 that requires the flyctl prerelease, or is everything from this post all now available in the mainline flyctl version?

Hi @Alex21! It’s all in the main flyctl release now. If you’re trying out Apps V2 keep an eye on the latest releases because it’s moving fast. Latest as I type is v0.0.482.


Is there any prediction of when we will have this? Apparently there is no way with nomad to have shared-cpu-2x, shared-cpu-3x, shared-cpu-4x.

1 Like

We’re currently hard at work to get it shipped as soon as possible.