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

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.

WorkaroundSegmentation and priority are the primary reasons teams move from public to private today. Because public workers are one undifferentiated queue, any team that needs workload isolation, per-team quotas, or priority routing has to take on the full operational cost of private infrastructure, even though the per-worker Spacelift rate is identical. We're paying the same price for meaningfully less out-of-the-box utility.
ProblemStand up private worker pools. It solves segmentation and priority, but shifts autoscaling, runner cost, patching, and lifecycle management onto us. Fine as a choice; painful as the only choice.

Please authenticate to join the conversation.

Upvoters
Status

👀 In Review

Board

💡 Feature Requests

Tags

Workers

Date

About 5 hours ago

Subscribe to request

Get notified by email when there are changes.