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.

Read-only role (or scoped permissions) for the Prometheus exporter

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.

Enable transitive AWS STS Session Tagging

Currently, session tagging when assuming an AWS IAM Role via Spacelift will only tag the first assumption. For situations where there are multiple links in an assumption chain, e.g using a Spacelift integration to automatically assume an access role, then using the OpenTofu AWS provider to assume a second role in a target account, this means only the access role assumption is tagged. Ideally, transitive session tags would be used so the tag persists through the entire assumption chain. AWS docs for session tagging for reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html Our security team is keen for this feature so that AWS CloudTrail events can be captured in our SIEM to understand exactly which Spacelift stack run resulted in changes, which can then be linked back to specific commits/authors.

Show delta details on hover in the stack list

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.

Better YAML diffs

diffs for YAML strings in the “changes “ tab of a run are… not great. It would be nice could either show a semantic diff of the yaml, similar to what it does for json, or even just show a linewise diff, rather than showing the full string replacement.

Confirm button on "changes" view

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.

Delete flows personal projects when a user is deleted.

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

Render README.md in Spacelift Repos

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:

Feature Request: Terraform Source Code Scanning within Approval Policies

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.

Ability to create limited scope tokens with spacectl

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

Customizable state-to-color mapping on default-card Slack notifications

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.

Support Automated Private Worker Pool Key Rotation

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)

Disable sidebar auto-expand

Infra Assistant: reach customer MCP servers and private model gateways through your own network

Problem Bring your own model supports a custom base URL, but model calls originate from Spacelift's side. The gateway (LiteLLM, an internal Azure OpenAI or Bedrock proxy) must therefore be reachable from the internet, which many enterprises will not allow. Infra Assistant also has only built-in tools. It cannot call the customer's MCP servers (CMDB, observability, ticketing, internal APIs), which is what it needs to answer "who owns this," "is this service healthy," or "is there an approved change open." Outcome Admins register customer MCP servers as Infra Assistant tools, scoped by space, read-only by default, with per-tool allow lists. Model and MCP traffic can optionally route through customer-run infrastructure inside their network, so neither the gateway nor the MCP servers need public exposure. VCS agent pools already follow this pattern for private VCS. Every tool call is recorded in the audit trail, and Build mode writes stay governed by Intent policies.

Intelligence skills: customer-authored instructions and reference material for Infra Assistant

Problem Infra Assistant knows Spacelift's docs, the GraphQL schema, and the page you are on. It does not know your organization: naming and tagging standards, approved modules, which spaces map to which environments, change windows, runbooks for common failures. Users re-explain this in every conversation, and answers that are correct in general come out wrong locally. For example, it suggests a raw resource where the organization requires an approved module. Outcome Admins author skills (instructions plus reference documents) scoped to the account or to a space. Skills are versioned, ideally sourced from Git like other Spacelift configuration. Infra Assistant loads the relevant skills automatically, with the Spacelift-provided model or your own model. No model training or fine-tuning. Content stays within the account, and skill changes are recorded in the audit trail. Skills shape guidance, not enforcement. Plan and Intent policies remain the deterministic control.

PR-level blast-radius guard for changes that fan out across many stacks

Problem Plan policies evaluate one stack's plan at a time. A PR that edits a shared file (a module, a Terragrunt root.hcl, shared variables) can trigger runs on dozens or hundreds of stacks. Each plan looks small on its own, so per-stack deny and warn rules pass. Nothing in Spacelift sees the aggregate: how many stacks are affected, and how many destroys and replaces they add up to. The failure mode is a one-line diff to a shared file that replaces resources in every environment and gets approved because no single plan looked dangerous. Outcome Once every run triggered by a PR has finished planning, evaluate the combined change: stacks affected, total destroys and replaces, and changes to named resource types. Above a threshold set per space, hold the tracked runs from that commit until named approvers confirm. Report the result as a single status check on the PR so it can be a required check. Out of scope Destroy limits on a single stack. Plan policies already handle this. Run priority for fan-out changes. Covered by Automatically lower run priority for high fan-out changes.

Windows Support for Ansible stacks

The Spacelift maintained Ansible container that is used by default in Ansible stacks does not have the necessary python packages to support connecting to Windows servers, like pykerberos and pywinrm (there could be more, but these two are as far as I've dug on the subject at the moment). It would be a huge win to have support out-of-the-box for this

Copy Logs Button

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

Pin views

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

Shard github activity over multiple GH apps

We would like to be able to install multiple Github apps to a single VCS integration to work around githubs rate limits of 15k request per an hour in a busy monorepo, this pattern is used by other apps such as WIZ, and would allow us to scale without hoping that Github will approve our limits increase With out this during busy times we see sync operations fail, and missing comments and checks in github This would also make it easier to manage then knowing what is pinned to what app, and changing the integration on existing stacks can be messy with active stacks.