How does min_machines_running work together with current machines/scale?

1

I am wondering what min_machines_running is permitted to affect.

I had previously assumed that increasing min_machines_running of an existing app to more than the current machine count would trigger fly.io to automatically create a new machine, but this doesn’t seem to be the case. I tried it and nope - the value had absolut zero effect :{.

min_machines_running seems to only affect downscaling rules.

Is this correct?

And if so, when is fly.io allowed to automatically create new machines? (not just wake up existing ones) Never?

Do I always have to create the new machines manually (by for example fly scale count x, or explicitly cloning a machine)?

This confuses me :smiley:

fly config show -a "**********
{
  "app": "**********",
  "primary_region": ""**********",
  ...,
  "http_service": {
    "internal_port": 80,
    ...
    "min_machines_running": 2
  }
}

VM Resources for app: **********
Groups
NAME	COUNT	KIND  	CPUS	MEMORY	REGIONS
app 	1    	shared	1   	256 MB	**********

The app is stateless/has no volumes or such which I could think of preventing auto scale up

2

Hi @gigurra

min_machines_running is only used when auto_stop_machines = true. And if you’re auto stopping Machines, then auto_start_machines should probably also be true. So in that context, I can explain how min_machines_running works.

Machines are not being automatically created or destroyed based on these settings.

One way to think of min_machines_running is as the lower limit number of Machines to run. The upper limit number of Machines to run is the number of Machines you’ve created.

(And you are correct, you create Machines using fly scale count or by cloning. A whole other topic: you can also use the Machines API to create, start, stop, and destroy Machines depending on your use case.)

Because auto start and stop works based on traffic to your app, when you use these settings you should have only the needed number of Machines running at any point in time. Machines are stopped when there’s low demand and then restarted until either all your Machines are running, or until the demand falls. It’s faster to start a stopped Machine, than it is to create and start one on demand.

Also note that min_machines_running only applies in your primary region.

Recommended reading for all the details:

3

Thanks! That confirms my suspicion :slight_smile:

4

Is there an example of how to configure the owner App for machines (including fly.toml if that’s needed to stop the App behavior?) to not scale App instances up/down, but rather just create machines on POST?

I think the weird/unexpected behaviors I’ve seen trying to use machines in this way yesterday:

  1. Getting an existing App (from the target app group for the machine) image machine ID returned instead of a newly created machine ID
  2. (May be mistaken) Auto-scaling down of manually created machine images (was a while ago, not positive this happened but may need a setting to avoid it happening automatically)

Mostly wondering what the set of configuration to make Machines behave without App behavior (something like I imagine how Cloud Run / ECS treat new instance requests). E.g… is the flag fly apps create <your-app-name> --machines needed when creating the app to store the Machines in needed anymore?

Also curious whether the:

"checks": {
        "httpget": {
            "type": "http",
            "port": 8080,
            "method": "GET",
            "path": "/",
            "interval": "15s",
            "timeout": "10s"
        }
    }

in the docs example is required if you’re manually handling start/stop of Machines?

Is there any sort of maximum concurrent connections setting for machines themselves?

5

hi @bcjordan This is a like whole new topic! But I’ll try to answer a few of your questions here.

I think what you’re asking here is how to have an app that just contains individual Machines that you create with the API or flyctl? Where each Machine can have it’s own image and configuration, including autostart and autostop.
You are correct that you can create this kind of app with:
fly apps create my-app-name
(You don’t need the --machines flag.)
When you use fly apps create it creates an empty app with no fly.toml config file.
You can also create a new empty app with a POST request to /apps.

Note: fly.toml is used to manage Machines and services as a group, and is a feature of our Fly Launch product for apps. However, you don’t need Fly Launch or the resulting fly.toml, if you just want to run some individual Machines that you don’t need to deploy/release together.

  1. Could you share the request you made to create a Machine that returned an existing Machine instead? (Suggest creating a new topic for that!)
  2. I’m not sure why this would happen because autostop is false by default for Machines that are created with the API (or with fly machine run).

But to be on the safe side, you can update any Machines with services by adding:

...
    "services": [
      {
        "autostart": false,
        "autostop": false,
...

Checks are just to make sure that the Machine is reachable after startup and are optional.

You can set pretty much anything on individual Machines.

So, again, if you have services, you can add concurrency settings to them like so:

    "services": [
      {
...
        "concurrency": {
          "hard_limit": 25,
          "soft_limit": 20,
          "type": "connections"
       }
...

The settings are described here in the fly.toml reference, but they can be set on Machines using the API as above, or by updating Machine config using flyctl.

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.