Skip to main content

Segmentation and priority controls for public worker pools (parity with private pools)

Feature RequestsWorkersStacksSpaces

Public workers today are a single shared account-wide pool with no segmentation or priority controls. Private worker pools, by contrast, support multiple named pools, per-stack routing via labels, and priority ordering: the primitives we rely on to isolate workloads, manage concurrency, and protect critical paths. As we scale, teams that want those organizational controls have only one option: stand up private pools, which means owning the infrastructure, autoscaling, runner cost, and lifecycle. Given that public and private workers are priced the same per worker, we'd love to see public pools reach feature parity: named public pools, stack-to-pool routing via labels, and priority ordering. That would let teams get the segmentation controls they need without absorbing the operational lift of self-managed runners, and it would also open a fairer conversation about whether the pricing model should reflect the operational burden customers take on when they choose private purely for reasons other than segmentation.

Workaround
Problem
Status: ⬆️ Gathering votes3 comments

Log in to comment and vote

Comments3

  • Jonah Kowall

    Team•

    Sep 19

    Thanks Donovan, this is a clear ask and the “we’re on private mainly for controls, not because we want to run infra” framing is something I hear sometimes.


    You’re right that today named pools, label routing, and priority are private-only. Public is one shared account-wide queue by design. We’re reviewing whether public should get a slice of that (and how that interacts with pricing), vs keeping those controls on private.

    Leaving this In Review while we dig in. Happy to take more detail on which of the three (named pools / label routing / priority) hurts most if you can only pick one.

    • Rose Beaver

      •

      Sep 24

      For us it’s the “priority ordering” that we really need for public workers. We had a feature request for this here, but unfortunately that is marked closed now despite this feature not available on public worker.

      Imagine you have to urgently apply a fix or rollback a change and your stack run is stuck behind a bunch of other stack runs. Right now we need to manually discard all other queued runs to get this single time-critical run to the top of the queue and then re-trigger all discarded stacks. It’s painful for such a simple missing feature. I want to be able to just drag my important stack run to the top of the queue.

      • Jonah Kowall

        Team•

        Sep 24

        I understand your need and this feature request remains open. One of the advantages for private workers is you do not have contention. With public workers you could have some. This is shared infrastructure versus dedicated.