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.

Right now when a user is deleted, their personal projects are not deleted along with them.

It whould be great to have markdown rendering for the README.md file inside of Spacelift Repos - similar to common Git-Providers like Github oder Gitlab. Maybe this can be achieved similar to the README rendering for modules. Right now a README.md is just a file like every other file else in the repo:

We need the ability to scan and validate Terraform source code within Spacelift approval policies to enforce security guardrails. Specifically, we want to prevent (not just detect) the usage of potentially dangerous Terraform providers before plans are executed. Currently, approval policies do not have visibility into the underlying Terraform source code, limiting our ability to enforce provider-level security controls.

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

I would like to have a button to confirm changes directly on the “Changes” tab of a planned run. After reviewing the changes in the changes review, I would like to be able to click a single button to confirm the changes without having to navigate to a different page first.

Currently it is spacectl stack logs --id terraform-postgresql-database --run xxxx, but it should be spacectl module logs --id terraform-postgresql-database --run xxxx

Microsoft just this week has started to allow user accounts in Azure DevOps linked to service principals in Azure to work as an authentication piece for 3rd party systems.  We have just added this for a couple of other vendors.  We would like for this to be available for our ADO integration with Spacelift rather than having to rely on personal access tokens.

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.