Introducing RunsOn Fleet

Today we’re launching RunsOn Fleet, a new mode for teams that want their GitHub Actions runners published as an org-wide or enterprise-wide catalog instead of picked label-by-label in each workflow.

Fleet is in early access from today. It runs alongside RunsOn Flex, which is the product you have been using all along, now with a name.

Why Fleet exists

A few things Flex is not, and can’t easily become:

• strategy.max-parallel-aware. Flex launches one ephemeral runner per job, triggered by a GitHub webhook. There is no central queue for GitHub to throttle against. Scale sets give you that queue, so strategy.max-parallel actually works.
• Webhook-free. Flex needs a public ingress endpoint for GitHub to push to. For some customers, “GitHub can reach into my AWS account” is the dealbreaker. Fleet polls GitHub from inside your account instead.
• Platform-team-owned. Flex hands the runner choice to workflow authors. That’s the right answer when the team knows what it needs. It’s the wrong answer when a CI platform team supports dozens of repos and wants the runner catalog to be a reviewed, fixed surface in Terraform.
• Enterprise-scoped. Flex registers runners into one organization. Fleet can register into an enterprise-owned runner group that serves many orgs from one stack.

Those are the patterns that pushed us toward a second product instead of stretching Flex.

What Fleet looks like

A platform team publishes a small catalog of runner fleets in Terraform:

runners = {
  small-x64 = {
    cpu    = [2]
    ram    = [4, 8]
    extras = ["s3-cache"]
    family = ["t3", "m7"]
    image  = "ubuntu24-full-x64"
  }
}

fleets = {
  linux-small = { # fleet name
    runner       = "small-x64"
    runner_group = "runs-on-ci" # GitHub runner group name
    timezone     = "UTC"
    schedule = [
      {
        name    = "default"
        hot     = 1
        stopped = 3
      },
    ]
  }
}

Repository workflows pick from it with a stable label:

runs-on: runs-on/fleet=linux-small/env=production

The Fleet control plane polls GitHub for assigned jobs and launches matching EC2 runners in your AWS account. Workflows cannot override the runner shape, image, networking, or capacity. Those choices live in the runner fleet entry, reviewed where you review Terraform.

And RunsOn Flex?

Flex is the per-job runner mode you already know. A workflow asks for the runner it needs with a runs-on: label, RunsOn launches a matching ephemeral EC2 instance in your AWS account, and the runner terminates after the job.

Nothing about Flex changes with this release. Same install path, same labels, same docs, same control plane. The product is renamed; that is the only thing different. The name matters because Fleet now exists alongside it and the two need to be distinguishable.

How to pick between them

Fleet main use case is two-fold:

• easily support multi-org runners, by registering in enterprise runner groups (flex is single-org only).
• let platform teams publish non-mutable runner fleets that workflows just target by name, without giving workflow authors the ability to override the runner shape, image, networking, or capacity.

If one of those use cases fits your team, pick that product. Otherwise, Flex is probably what you want. If you’re not sure, have a look at Flex vs Fleet.

Start here

• If you’re on Flex today, nothing changes for you. Your labels and stack keep working.
• Install Fleet: Terraform module, single-org or enterprise.
• Flex vs Fleet: compare the two products.

We’re also moving to tier-based pricing alongside this launch. One license covers both products: details here.