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.

The Prometheus exporter (spacelift-io/prometheus-exporter) currently requires an Admin API key because some of the metrics fields it queries are gated behind admin access. This forces us to distribute admin-scoped credentials to every cluster running a private worker pool, purely to expose queue depth, worker counts, and billing usage to Prometheus. Please add a read-only role (or scoped permissions) that grants only what the exporter needs, assignable via IdP group mapping and usable with OIDC API keys the same way other roles are. Reducing the exporter's permission floor to a space-scoped read role would eliminate credential sprawl, align the exporter with least-privilege posture, and make it defensible in regulated environments where admin scope on a metrics collector is a hard audit finding.

In the stack list, each stack shows an aggregate delta badge (~2, +3 −12, or a collapsed "2 deltas"). Today the only way to see which resources changed is to click into the stack and then navigate back. A tooltip or hover popover showing the resource-level breakdown — resource addresses plus change type — would let us triage a list of unconfirmed drift in place. Expanding the collapsed "N deltas" badge on hover would help for the same reason.

The default-card Slack notification (via a NOTIFICATION policy's slack rule) already color-codes its sidebar by run state, e.g. yellow for UNCONFIRMED, red for DISCARDED, blue for CONFIRMED. We'd like control over that mapping, since blue doesn't read as "resolved" the way green would. Ideally either a way to set the color per state ourselves, or at least having Spacelift map CONFIRMED/FINISHED to green instead of blue.

Description: There is currently no way to automate private worker pool key rotation in Spacelift. The only available mechanism is a manual reset via the console (Manage Organization → Worker Pools → Reset), which immediately disconnects all workers and requires a planned maintenance window. Request: Provide an API or automated mechanism to rotate private worker pool keys without requiring full worker disconnection, enabling teams to rotate on a regular cadence (e.g. 90 days) without manual intervention or downtime. Desired outcome: API-driven key rotation support Graceful worker reconnection (no hard disconnect/maintenance window required) Ability to integrate rotation into existing secret management pipelines (e.g. Azure Key Vault)

Add a way, ideally with the spacectl CLI, to create a (renewable?) access token with more restricted permission scope than the user’s full access.My use case is I would like to use spacectl with AI in a sandbox, so it can view the plans made by PRs, and trigger speculative plans. However, I have more elevated spacelift permissions, and I DO NOT want the AI to be able to make actions that I have access to with my spacelift permissions

We have consolidated our modules into one git repo and are using sparse checkout paths. However, our resources are split across separate modules. As an example we have three separate modules: - `terraform-azure-sqlserver` - `terraform-azure-sqlelasticpooldb` - `terraform-azure-sqlserverdb` When I test the `sqlserverdb` module, I need the server and elastic pool modules available. Historically we've referenced the Spacelift registry version of the sister module in the test stack. This worked fine, but now we're doing a big bang azurerm v3 → v5 upgrade and testing fails due to the provider dependency conflict described above.

In the new Slack integration, confirming a run updates the previously posted UNCONFIRMED notification to CONFIRMED. This is very good for Slack ops efficiency - on-call can scan the channel for today and see outstanding actions. I'd like to request the same for FAILED. If a subsequent run from the same commit resolves the stack into FINISHED, the associated Slack notification should also resolve into an OK/green state. This would help with transient errors: retrying a run, or invalid operator decisions - an operator rejected a run flagged by policies, but the run should actually have been approved.

Summary The new high/normal/low run priority levels work well day to day. What's missing is a way to set priority automatically based on how wide a change's blast radius is, so that a commit triggering hundreds of stacks doesn't queue ahead of targeted, single-stack changes. Problem During normal operations, built-in prioritization keeps plans moving quickly. Even large volumes of drift detection runs don't cause meaningful delays. The problem shows up when a PR or merge touches shared configuration that fans out to dozens or hundreds of stacks. Those runs build large queues that block unrelated, targeted changes behind them. In one recent case, a single commit touching terragrunt/regions/multi-tenant/tenancy.hcl triggered almost 800 runs. This comes from how our Terragrunt stacks are structured. Each stack watches its own project root plus shared config files higher up in the hierarchy, for example: project_root = "terragrunt/regions/all/gcp-log-metrics/s4s2" additional_project_globs = [ "terragrunt/regions/all/gcp-log-metrics/*.hcl", "terragrunt/regions/all/s4s2.hcl", "terragrunt/regions/all/tenancy.hcl", "terragrunt/regions/regions.hcl", ] This is correct behavior, since a change to a common setting higher up can affect the stack. But with hierarchies containing hundreds of stacks, one edit to a shared file can start concurrent runs across all of them. Proposed solutions Either of these would solve it, and they could complement each other. Option 1: Priority policy based on affected stacks. Allow a policy (auto-attached or manually attached) that can see the set of stacks affected by a commit or PR and assign run priority. For example: if a change triggers more than N stacks, move those runs to low priority. Spacelift support suggested this approach. Option 2: Priority per project glob. Allow priority to be set on the project root and on each entry in additional_project_globs, so that the matched path determines the run's priority. Using the example above: Glob depth maps closely to run count in our setup, so this would be a simple, declarative way to get the right behavior without needing to count stacks at runtime. Desired ordering High fan-out runs should drop below targeted changes but ideally still stay above drift detection: High → Normal → Low (high fan-out changes) → Drift detection Impact Targeted, single-stack changes would stay fast even while a large fan-out change is working through its queue, which is when unblocked changes matter most.

I have recently came across an idea for a potential “feature”, which might be useful or completely bonkers, I cannot really tell myself. I think I might have a use case for defining Stack extra project globs in another repository than the Stack’s one, i.e., I would like the Stack to be triggered when file in another repository changes. The definition (for GitHub) could look something like: / : How would I use it? We have a sort of collector repo, which holds versions of artifacts, e.g., docker containers. These are pushed and committed by automated workflows building the artifacts. I would like to subscribe Stacks in other repos to be triggered when their artifacts change. There are sure other solutions to this, I just wanted to make this idea public and see where it is gonna lead. Thanks!

Spacelift allows setting “Default runner image” for public and private runners. To my understanding, this affects only image for Stacks, not Terraform Modules, which still require setting custom image individually. It would be nice to for this option to affect Terraform modules runner image as well, or there could be a separate setting for just TF modules to offer more flexibility (This would be a separate Spacelift Terraform provider resource as well…).

Recently, an option to set “OIDC subject template” has been added to Spacelift, which is great for overcoming OIDC limitations for example in Azure. However, it seems like this -quite crucial and sensitive - configuration cannot be configured with Spacelift Terraform provider. I would like such option.

Ability to select a queued run and confirm it while discarding all previous ones.

We connect Claude Code to the Spacelift Flows MCP server to inspect and edit our flows. Today the MCP tools can list and read blocks, but there is no tool to list recent runs (invocations) of a flow with their status, trigger, and failing block. When a flow silently stops producing output we have to open the canvas and click through invocations by hand. A list_flow_runs tool (flow ID, time window, status filter) returning run ID, trigger, start time, status, and the first failing block would let an agent diagnose it directly.

https://feedback.spacelift.io/p/way-to-view-all-other-stacks-in-the-space-from/comment/6aa2c24aeaaac6e3e6732387

Currently when making any policy and a stack is triggered by another stack you only see one triggered_by. If you have more than one layer of apps that depend on the very first stack needing an approval, and you want to auto-approve the dependent stack there isn’t a clean way to say if it was triggered by this job since the triggered_by won’t have any information on what the root stack is. The ask is similar to https://feedback.spacelift.io/p/include-the-runid-of-an-upstream-stack-and-any-other but just always for triggerred_by. Where currently run_id is recursive and you can use the OPA walk function to get the data.

We have 200+ stacks that are set up in the pattern of spaces below. They need to have a common role attached to them and currently we have to attach the role to the stacks separately; this is easy enough to do but it does add 200+ role_attachment resources to our metadata stack. As we scale this pattern out to other roles and stacks spacelift runs will slow down due to large numbers of resources in opentofu. - parent <-- have role here - child_space1 - space_with_stacks_in <-- use role here - child_space2 - space_with_stacks_in <-- use role here Proposed solutions Allow roles to be attached to a space and child stacks inherit it Allow roles to be autoattach: in a similar way that rego policies can be

We used to have Terraform stacks with the terragrunt label in order to run Terragrunt. This configuration allowed us to execute targetted replans. It seems that Terragrunt stacks (without the terragrunt label) do not have this functionality. This functionality should also be supported in Terragrunt stacks.

please add a "copy logs to clipboard" button alongside download logs