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.

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 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

Recently a new view got introduced that enables you to see your workers usage, the available burst budget and how that fits your billing cycle. However, the current view only supports the current billing period. It would be very useful to see historical data as well.

Our centralized team is managing integrations for the decentralized engineers/developers. We want to provide a privileged integration, which should only be available if the stack is using whitelisted Terraform modules (enforced by policy). We have the policy in place, but we're missing the required metadata to detect which integration is attached to the stack. Our current goal: Only allow the use whitelisted modules if the privileged integration (labeled “privileged”) is attached to the stack. This is an example that would be nice if it would work: import rego.v1 # This is currently not possible/available # data like this would be helpful to build policies based on the attached # integrations: # integrations := [ # { # id: "privileged-integration" # type: "azure" # name: "My Privileged Integration" # labels: ["privileged"] # }, # ] integrations := input.run.integrations deny contains msg if { some integration in integrations "privileged" in integration.labels msg := sprintf("integration %q is labeled privileged", [integration.id]) }

I would like to pin specific views (filters) instead of just general menus so that I can quickly navigate to pre-filtered pages

Private Terraform providers are only visible to stacks in the provider’s space and inheriting children. Modules already have space_shares and SPACE_SHARE_MODULE (including share-by-label) so we can grant download without inherit_entities from root. spacelift_terraform_provider has no equivalent, only type, space, labels, and public. Type is unique per account, so we cannot publish one copy per space. We need the same sharing model for providers: Terraform + GraphQL + UI, and the run-token registry download must honour it. A share should allow downloading that provider only, not Space Read on the rest of the owner space. This is not another public/private toggle.

Can we add an option to open all stacks selected in new tabs please? similar to PRs in github

Our Terraform modules often use complex variable inputs of type list(object({})). Unfortunately it’s not possible to expose these complex types in our Spacelift templates. A definition could be something like this: inputs: - id: stacks name: Stacks description: Stacks that should be available to your Spacelift space type: list(object) schema: - id: name name: Name type: string - id: environment name: Environment type: select options: - dev - staging - prod

These settings would override any default images at the Org level, allowing us to define the three different ECR repos we use for Commercial, GovCloud, and FedRAMP respectively.

Add an info (or note) rule to plan policies: a list of strings rendered in the run's Messages list the way warn is, in blue or green, with no effect on the run's outcome and no effect on autodeploy.