Scaling Fly for All

Want to know a Fly secret? We’ve got a lot of things in our platform that we’re steadily rolling out to users. One of those things is global scaling - we’ve been using it internally and with selected customers, but now, it’s available for all.

When you create an application on Fly, it uses our default region plan. This places the application in the best available region for access from the Fly edge network. When an application is created, it is put in the default region, which for most applications will be the closest region to where the application was created.

When an instance hits its connections limit, by default between 20-25, a new instance added and Fly’s autopilot scaling will decide the optimal location for that new instance. It’s a very effective default plan.

Scaling over regions

We are moving on though and the first thing to do is to empower you. Specifically with power to control where your data center instances are and the minimum nuber of instances that are available there. Say hello to the flyctl scale commands.

With scale regions you can see what your current scaling is set to or you can set which regions your app is running in and minimum number of app instances you want running in each one. Let’s start by seeing what the default region looks like:

flyctl scale regions

Autoscaling
  Enabled         = true
  Balance Regions = true

And that’s it. There are no regions set and no instance counts displayed so this application runs in the default region.

Let’s use the example of scaling from our front page:

flyctl scale regions ams=1 hkg=1 sjc=1

Updating autoscaling config...
Autoscaling
  Enabled         = true
  Balance Regions = true

Regions
  REGION   MIN COUNT   WEIGHT
  ams      1           100
  hkg      1           100
  sjc      1           100

The application will now run at least one instance in ams (Amsterdam), hkg (Hong Kong) and sjc (Sunnyvale, California). We’ll discuss weight at another time - it controls the Fly’s preference for where new instances are created. When you do use a scale regions command, the Fly platform generates a new version of the deployed app and redeploys to match the new scaling.

Regions and Fly

If you aren’t sure about what regions there are, you can look regions up in the documentation or use the flyctl platform regions command:

 flyctl platform regions

  CODE   NAME
  ams    Amsterdam, Netherlands
  atl    Atlanta, Georgia (US)
  dfw    Dallas 2, Texas (US)
  ewr    Parsippany, NJ (US)
  fra    Frankfurt, Germany
  hkg    Hong Kong
  iad    Ashburn, Virginia (US)
  lax    Los Angeles, California (US)
  mrs    Marseille, France
  nrt    Tokyo, Japan
  ord    Chicago, Illinois (US)
  sea    Seattle, Washington (US)
  sin    Singapore
  sjc    Sunnyvale, California (US)
  syd    Sydney, Australia
  yyz    Toronto, Canada

Scaling VMs

Scaling out over regions is one of the scaling options. Another option is to scale the instances themselves. By default, applications are allocated a micro-VM (micro-2x) with 512MB of memory and a quarter share of a vCPU cores. It’s small but pretty mighty.

Running flyctl platform vm-sizes will display this table with the current per second and per month pricing for each VM size. That information is also available on the pricing page.

Setting a VM Size

The VM size for an application applies to all instances currently deployed and deployed in the future. Just run flyctl scale vm <sizename> to set the size and, like the region scaling, a new version of the app will be created and all the instances will be redeployed.

So, you now know enough commands to get scaling today and configure your Fly app to the size that suits you.

For more on Scaling, check out our Scaling documentation where you can learn about the other scale commands, what the “Autoscaling” in the output is about and more.