Got an idea for a feature request? Let us know! Share your ideas on improving existing features or suggest something new. Vote on ideas you find useful!
Make sure to read our guidelines before posting 📖
Feature Requests
➡️ Planned
Add worker pool info to Stack details screen
Add worker pool type to the Stack details quick lookup screen.
Allow stack owners to simulate policy on those stacks
We use spaces to govern stack permissions - ie: teams have stack permissions within spaces that we manage through custom read/write roles. And our users are also able to specify custom policy rules for their stacks (most commonly used for custom approval policies). There is no way for us to allow permissions for users to perform policy simulations on the policy they own (ie: the ones that are applied to their stack runs in their spaces). Users should be able to use the same policy debugging tools that admins use for policies being applied to their stacks.
⬆️ Gathering votes
Support explicit Boolean values for accountToggleAllowNonRootAdminSpaceCreation
We would like to manage accountToggleAllowNonRootAdminSpaceCreation declaratively through Terraform. Currently, the GraphQL mutation only toggles the existing value and does not accept an explicit Boolean value. This makes the operation non-idempotent because Terraform cannot reliably ensure the desired state. Repeated applies, retries, failed runs, or manual changes could leave the setting in the wrong state. Please provide a mutation that accepts an explicit value, for example: GraphQL mutation { accountAllowNonRootAdminSpaceCreation(enabled: true) } The same mutation should support false, allowing Terraform to enable the setting during resource creation and disable it during resource destruction.
⬆️ Gathering votes
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.
➡️ Planned
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.
Add an account-wide setting to ignore repository-supplied runtime configuration
We’d like an administrator-controlled setting that ignores repository-supplied runtime configuration by default, with an allowlist for specific repositories. The existing feature:ignore_runtime_config label is useful per stack, but does not give us a consistent account-wide option. Stack level labels are also easy to add/remove. In a large organization with many repositories, repository write access is distributed across teams. Allowing each repository to supply runtime configuration gives those files a way to affect Spacelift runs. We’d like to limit that capability to repositories we explicitly choose as part of our security controls.
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.
Fan-out gate: stop a PR that would trigger runs on many stacks before the runs start
Problem When a PR touches a shared file (a module, a Terragrunt root.hcl, shared variables), Spacelift resolves the affected stacks and triggers a run on each. Push policies decide per stack, so none of them can see that the change reaches dozens or hundreds of stacks. By the time anyone notices, the runs are queued or finished: worker capacity is consumed, unrelated changes wait behind them, and a mistaken change has already planned everywhere. Reviewing the combined result afterward is too late to prevent any of that. Outcome After Spacelift determines which stacks a PR or push affects, and before it creates any runs, evaluate a policy over the whole set: number of stacks, and which spaces, labels, or environments they belong to. Above the threshold, no runs start. The PR gets a status check listing the affected stacks, so the author sees the scope of the change before it costs anything. An authorized user can override and release the runs, recorded in the audit trail. Follow-on: once released, the same PR check summarizes the combined changes across the proposed runs (total destroys and replaces). 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.
Allow confirming runs on a stack locked by a push policy lock
Why: Applying from a PR before merge is common for us, and we need two things at once: one PR at a time per stack, and a person confirming after reviewing the plan. Today we can only have one of them. Any one of these would work: Let users with the Confirm run permission confirm or discard runs that were queued while the stack was locked by a policy key, without unlocking. The lock would still block other PRs from queuing runs. Treat runs a push policy queues under its lock key as belonging to that lock, so the lock’s runs can be confirmed and other runs stay blocked. Let the push policy say a tracked run it queues may be applied without manual confirmation (for example, a confirm or autodeploy rule), with approval and plan policies still gating it at Unconfirmed. Related: Expose GitHub PR state to approval policies for promoted runs. Together they would make promotion plus an approval policy a complete pre-merge apply workflow. Previous (similar) request: https://feedback.spacelift.io/p/stack-locking-doesnt-support-atlantis-style-apply-before-merge-workflow
Expose GitHub PR state to approval policies for promoted runs
We want reviewers to see the Spacelift plan on a PR before approving, then let people promote and apply that PR only once GitHub reports it approved by a code owner and mergeable (required checks passing). Push policies see pull_request.approved / mergeable / undiverged, but only when a run is created, and they aren’t re-evaluated when a review lands. Approval and plan policies, which do run when a promoted run is created, get no PR state, and http.sendis disabled. So today we can only reject all promotions of PR runs (an approval policy checking run.commit.exist_on_tracked_branch and triggered_by) and send people through a /spacelift deploy comment handled by the push policy. Request (any one of these would work): Include the PR’s current approved, mergeable and undiverged in the approval policy input for runs whose commit has a pull_request_id, fetched when the policy is evaluated. Re-evaluate approval policies when a PR review is submitted or the PR’s mergeability changes. Carry a proposed run’s policy flags over to the tracked run created by promoting it, and document this. Why the plan must come before approval: code review alone misses plan-only surprises. For example, a disk is resized during an incident, and a later PR’s harmless-looking size change then plans a delete-and-recreate. We want that caught in review. Related: More Controls for PR Promotion. Option 1 would also cover its behind-main case.
⬆️ Gathering votes
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.
One-click filter to all runs started from a commit hash
I would like to be able to jump to a page showing all runs in spacelift triggered by a single commit hash.
Expose usage metrics through Datadog
We have the Datadog integration configured, which provides the following metrics: It would be great if the usage metrics that we have available now (docs) were exposed as Datadog metrics as well.
Data on Policy Usage
I would like to see more data about how our policies are affecting our development velocity. For example, the # of policy evaluations, approvals, rejections, how long an approval policy is typically waiting for approval. This way, we have data to see what's working or not working as efficiently as we had hoped
Ability to enforce approval requirements for admins
We have a global GCP organization policy that is being used to protect access to a sensitive project. (For context, the project contains sensitive employee data, and so there are very few people at the company allowed to view it and the data is rightfully very strongly protected.) The challenge we're having is that we can't move the Terraform directory for the org policy into Spacelift because it would allow too many people to change the permissions and potentially open up access to the sensitive project. It would be nice if we could move this into Spacelift as currently this policy has to be updated by manually applying Terraform locally, which adds a lot of unnecessary friction when changing this policy, eg the person making the change has to be available and have time to apply the change. For instance, we could add an approval policy to the project so that there's an extra level of review on any applies to the stack managing this policy. The issue is that the current owner of this policy is not willing to move this into Spacelift because our Spacelift admins could (in theory) remove the approval control and make arbitrary changes to the policy. I am not exactly sure how this should work, but it would generally be nice if Spacelift could support this kind of compliance requirement.
Notification on failure to acquire a lock
When using the lock rule in a push policy (https://docs.spacelift.io/concepts/policy/push-policy#stack-locking), failure to acquire the lock blocks runs from that evaluation of the push policy. However, there is no notification that this happened. Ideally, there would be a notification processed by a notification policy that we could use to alert the user that the run was blocked due to failure to acquire a lock, but it does not appear that such an event is currently generated.
Default Push Policy Options In Stack Settings
Would like to add a selection when creating and editing stack settings that allows for users to control what triggers proposed runs when no push policy is attached. Push file changes or PR diff (current behavior, stays the default) PR diff only, so proposed runs reflect the files shown in the pull request Tracked runs are unaffected: they continue to be based on the files in the push to the stack’s tracked branch. If a push policy is attached, it replaces the default behavior as it does today, and the setting has no effect. The UI should say so next to the setting.
Move overlay log text field buttons slightly to the left
Move the overlay buttons in the log text field (Search, Full screen, etc.) slightly to the left (please see screenshot). Currently the cut into the top of the scroll bar, and this can make clicking on the scroll bar rather difficult.
⬆️ Gathering votes
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.