👨‍💻Solutions Eng Requests

👩🏻‍💻Support Requests

➡️ Planned

⚙️ In Progress

✅ Completed

Feature Requests Roadmap

We’d like to request improvements to the billing visibility, specifically around how worker usage is calculated and billed under the P95 model. Background: Currently, the P95 billing model is a bit tricky to fully grasp from the UI, especially when trying to estimate how much we'll be billed or whether we’re within our buffer. We asked a few questions and got helpful answers: Example:<ul><li>If we occasionally exceed the limit (e.g., 6 workers for a short period), the P95 might still be within our contracted limit (e.g., 5 workers), meaning no extra charges.</li><li>However, if we go far over (e.g., 30 workers for the same short time), this could push the P95 up and cause overages.</li></ul>So while both duration and degree of overage matter, it’s currently hard to know what our actual risk or buffer is. Feature Request: We’d love to see better visibility in the UI and/or via metrics endpoints around this billing model, specifically:<ul><li>Current P95 usage: Where we stand right now for the billing cycle.</li><li>Projected billing impact: A clear estimate of our current or projected overages, if any.</li><li>Buffer insights: An answer to the question: “How much buffer do we have left this month?”</li><li>Simulation tool: Something that helps us simulate the impact of increasing worker count temporarily (e.g., during migrations between pools) so we can make informed decisions.</li></ul>Why it matters: This will help us:<ul><li>Plan operations like migrations without unintentional overages.</li><li>Understand when it's safe to scale up temporarily.</li><li>Avoid surprises in billing.</li></ul>Thanks for your consideration!

UI/UX

Workers

Dashboard

Observability

Improved Visibility into Worker Billing (P95 Model)

hidden

We are having issues with the way Terraform/Tofu destroy lifecycle is handled.Currently there are two ways to run a destroy for one of these stacks:<ol><li>Run a task where you manually type in “terraform destroy -auto-approve”</li><li>Delete the stack and select the option to destroy resources managed by the stack</li></ol>Both of these methods have some obvious downsides:Tasks are not intuitive for operational users of Spacelift that don’t commonly destroy stacks. Destroy lifecycle hooks are not executed as part of tasks so the destroy process may fail or be incomplete when run with a task.Deleting the stack doesn’t support all use cases. In some cases we want to destroy the resources managed by a stack but not the stack itself. We use the stack to create resources again using the same configuration later.Most importantly:both methods to not provide a way for us to review the destroy plan and choose to confirm or reject the destroy. There are many reasons a destroy plan may not be acceptable and the underlying project may need unexpected changes before proceeding.Spacelift already has a nice UX for other parts of the TF lifecycle. We would like to option to trigger a destroy, where the destroy lifecycle is executed with hooks and all, and where we get the opportunity to review the destroy plan and confirm or reject it.

Stacks

Add better support for Terraform/Tofu destroy

Allowing to download a stacks state-file locally. Useful for analyzing state-file content, as well as making modifications for later importing. This is useful when a stack might be stuck in a state it can’t refresh, due to bugs in providers or similar.

Ability to download state from stack

Currently, we can only attach a policy to stacks directly, either manually or through autoattach labels. It would be great if the autoattach feature also applied to space level labels, for all of their stacks.To explain our use case, we have a standard approval policy (on the root space) that we only want to apply to our production environment spaces, which are at the lowest level in our hierarchy. The only way for us to do this currently is to add a “prod” label to every stack under these spaces, which can be dangerous in case developers forget to add them. If we could just add that “prod” label to the production spaces, it would ensure that our policy always applies to all of their stacks.

Policies

Spaces

Use space labels to attach policies

Currently, AWS’s terraform-aws-control_tower_account_factory module is configured to use Terraform Cloud/Enterprise (TFC/TFE) or the open-source Terraform Community Edition as the backend for the workspaces required to provision resources. This module simplifies Control Tower account provisioning by providing a large amount of infrastructure out of the box, which makes the process much easier.With a few relatively minor adjustments, the module could instead be adapted to use Spacelift stacks as the backend for managing those workspaces.

Integrate spacelift into AWS control tower account factory module

Imagine this scenario: 1. you make some changes, and the policy posts a few comments in a PR, let’s say Stack A, B, C have some changes, so a post gets added to the PR about that 2. you make some more changes, let’s say you accidentially touch something that changes other stacks, now stack D, E, F have also new comments added to the PR 3. you realize your mistake and undo those changes, the comments for stacks D, E, F are never updated, you have to manually hide/delete them in the PRPerhaps “hiding” would work best here with the current paradigms, since then you could also un-hide it when needed. eg: <pre><code>package spacelift

import future.keywords

pull_request contains {
 "id": run.commit.pull_request_id,
 "deduplication_key": deduplication_key,
 "hide": hide,
} if {
 run := input.run_updated.run
 hide := count(input.run_updated.run.changes) == 0
 deduplication_key := input.run_updated.stack.id
}</code></pre>

Integrations

Notification Policy: Github PR Comment -- allow deleting and/or hiding existing comments

in spacelift ui I want to be able to click on the icon showing the current run state (applying, ...) and it should take me to the current run view

We don’t want to see log messages like ```[Ground Control] [2025-10-08T21:55:57.688306146Z] Workspace is GO [Ground Control] [2025-10-08T21:55:57.713268817Z] We're ready 01K72V1D00JASVRB85KQXY579H [Ground Control] [2025-10-08T21:55:57.713276695Z] Over to you 01K72V1D00JASVRB85KQXY579H, we'll see you on the other side [01K72V1D00JASVRB85KQXY579H] [2025-10-08T21:56:12.370730422Z] Mic check 1 2, is this thing on? [01K72V1D00JASVRB85KQXY579H] [2025-10-08T21:56:12.370790531Z] This is 01K72V1D00JASVRB85KQXY579H to Ground Control, I'm on ``` since they don’t have any discernible meaning to us. It would be great to prioritze real log messages.

Logs

Remove useless logs

<img data-width="100%" data-align="left" data-featurebase-content-key="6697afd8db026456df4b91e0/static/01956f6f-1b47-77da-88f7-f14c059b2c67/ss-01956f6f-1b47-77da-88f7-f14ba7e578e9.png" src="https://6697afd8db026456df4b91e0.featurebase-attachments.com/c/static/01956f6f-1b47-77da-88f7-f14c059b2c67/ss-01956f6f-1b47-77da-88f7-f14ba7e578e9.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260405T000000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260405%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=8c9d1244a035094adf5a3bb84d933c9869be51ae9d9b0e08cb628f9602f3fca5" data-featurebase-content-filename="ss-01956f6f-1b47-77da-88f7-f14ba7e578e9.png">Currently it’s really difficult to find out where the drift runs are located unless someone is really familiar with the product. I would like to file this feature request to provide a view for drifted runs under stack overview page along with Tracked runs and Ignored runs.

Drift Detection

Drift Detection View under stack Overview Page

We are making extensive use of contexts to both share configuration between stacks and also split configuration from code more cleanly. A problem we have though is when configuration of a context changes this will not trigger a run of stacks it is attached to. Ideally contexts should behave like dependencies do with the ability to trigger (either implicitly or via a trigger policy) when a change to them occurs.

Contexts

Trigger stack runs when contexts change

The client is requesting an additional claim —<code>spaceAncestry</code>— that represents the full hierarchy of the space structure.Example: For a hierarchy structured as:<pre><code>root &gt; parent &gt; child </code></pre>A stack in the <code>child</code> space currently receives an OIDC token containing:<pre><code>spaceId = child </code></pre>The proposed enhancement would include an additional claim such as:<pre><code>spaceAncestry = root;parent;child</code></pre>This would enable orgs to make more dynamic and hierarchical authorization decisions, particularly in integrations with identity systems like Google Cloud Workload Identity Federation (WIF). For example, when provisioning GCP service accounts and corresponding Spacelift contexts automatically, policies could be written to recognize all descendant spaces within a hierarchy — ensuring permission inheritance without manual updates whenever new child spaces are added.

OIDC

Include full space ancestry in OIDC token claims

While it is nice to be able to have colors in the output from Spacelift in the UI (and I wish to keep it), when downloading logs for further review (and/or when the logs are too long), the color codes are extremely noisy. It would be nice to have a preprocessing pass that strips everything before the download. It is slightly related to 2 other FR but: - “Disable color injected by Spacelift logger” is more about respecting a “—no-color” flag when passed in a tool, - “Allow viewing long full plan logs directly from web UI” is more about being able to see all logs in the web UI, and not having to download them (it’s marked as complete, but it doesn’t seem to be the case from my experience?)

"Download logs" button should automatically strip color codes

There’s currently no way to make user based API key. It’s only possible to create them on an organization level and it requires us to micro-manage API keys and their permissions in order to distribute them to teams (e.g. for usage with spacectl &amp; terraform login for the registry). It would be good to allow users to create their own API keys which are immediately bound to the permissions they have (and change with permission changes of the user they’d get later).

Access Control

User based API keys

Spacelift integrates with Terragrunt, but when using Terragrunt’s <code>run-all</code> functionality, Terraform state cannot be managed by Spacelift’s native state management. This limits the effectiveness of the integration for teams using Terragrunt to orchestrate multi-module and dependency-driven deployments.

Terragrunt

Support Terragrunt run-all with Spacelift Native State Management

Currently, Spacelift WorkerPools retain failed pods indefinitely to allow for debugging. While this is useful for short-term analysis, in certain scenarios (e.g., when a stack’s Project root is removed in Git but drift detection remains active), these failed pods can accumulate rapidly and exhaust the worker pool.Proposed Feature: Introduce an optional configuration (e.g., keepFailedPods=false or a TTL-based cleanup) that allows customers to opt-in to automatic cleanup of failed pods, similar to the existing keepSuccessfulPods flag. This would let customers balance between log retention and cluster stability.Value:<ul><li>Prevents runaway resource consumption when jobs repeatedly fail at the workspace preparation stage.</li><li>Reduces operational burden of manually cleaning up failed pods.</li><li>Maintains flexibility by keeping the current default (retain failed pods), but provides an escape hatch for customers prioritizing stability.</li></ul>

Kubernetes

Add opt-in option to automatically clean up failed worker pods

A lot of tools have a Command Palette function these days. It would be nice if I could press a shortcut like Cmd-K to open a global search window in spacelift and find a particular stack

Cmd-K global search

Hi, our team has <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/spacelift-io/prometheus-exporter/pull/43">created a PR </a>(running locally in our LGTM stacks) of the promex service that adds space and stack labels for metrics that have that data available. We would like to see additional data for stack and space added to drift data in the GraphQL API so that we have this available for our dashboards etc.

Add stack and space data to drift section of GraphQL API

I have the following stacks:client-a-test-area client-a-test-area-eu-west-2-app-1 client-a-test-area-eu-west-2-app-2,client-a-test-area-eu-west-2, client-a-test setting sort=name &amp; sortDirection=ASC results in client-a-testclient-a-test-area-eu-west-2client-a-test-area-eu-west-2-app-1client-a-test-area-eu-west-2-app-2client-a-test-area setting sort=name &amp; sortDirection=DESC results inclient-a-test-areaclient-a-test-area-eu-west-2-app-1client-a-test-area-eu-west-2-app-2client-a-test-area-eu-west-2client-a-test As can been seen neither of these sort orders are correct

Sort on name in stack display incorrect

When I manually trigger a task in a stack, I can’t see any indication from the main stack view that something is happening.For stacks with lots of activity, it's hard to track task runs unless I go into each stack manually. I’d love to see a simple visual indicator or status icon on the stack list or overview page, similar to what we see for tracked runs.Even something lightweight (like a bubble, badge, or flag) would really help for observability and usability, especially in environments with lots of stacks and teams.

Make Task Runs Visible on the Stack Overview Page

We’ve set up automations to manage module updates at the root level, which helped reduce the number of people who need admin access to the root space. However, one issue remains:Right now, confirming a run before <code>plan/apply</code> (the "commit approval") requires root-level admin privileges. We’d prefer if this approval could be handled with a separate scoped permission or role, so we don’t need anyone to have persistent admin access.This would help us better align with least privilege access and compliance requirements and reduce audit complexity.Ideally, it would work similarly to how we assign access to specific spaces or stacks today, without needing full admin rights at the root.

Allow Commit Approvals Without Requiring Root Admin Role

Within a stack page, when opening a run related to a PR, so from the PRs tab, there is no link to the PR, only one to the commit.

Add Pull Request link

For compliance purposes, we need to retain Run logs for longer than the default 60 days. Currently, there is no easy way to achieve this while keeping the logs easily visible in Spacelift. Allowing the retention period to be configured (could be a paid feature), or allowing logs to be pulled from customer-hosted storage would be nice.

Allow configuring log retention period

Autoattach cloud integrations

When the full plan logs are too long, you have to download the logs, then view them through a terminal if the logs have ANSI color codes in them.This is all around a confusing experience, between having to leave Spacelift, then figure out how to view the logs. A searchable log viewer that can handle really long log outputs would be nice. We have legacy Terraform stacks that we don’t want to shard before moving them to Spacelift, and sometimes you just end up with a really long plan, no matter how small your stack is.

Allow viewing long full plan logs directly from web UI

support rego.v1

Allow the admins of a non-root space, create spaces under that space. This allows us to delegate responsibilities to teams.

Allow space admins to create sub-spaces

We’d love to see full SCIM 2.0 support in Spacelift so that user provisioning and deprovisioning is handled automatically via our IdP (Okta, Azure AD, etc.). Right now we have to manually add/remove users in Spacelift, which slows us down and introduces risk of leaving stale accounts around. Ideally, if someone is added to an IdP group, they’d show up in Spacelift with the right role, and when they’re removed, access should be revoked automatically. This would really help us improve security, reduce admin overhead, and align with how we manage access in the rest of our SaaS tools.

SCIM Provisioning / Full IdP Integration

Right now there is no way (or at least, not an obvious one) to find all the stacks that are disabled - as there is no ‘Enabled: true/false’ filter on the Stacks page (<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://synerise.app.spacelift.io/stacks">https://synerise.app.spacelift.io/stacks</a>). Please add such filter :)

Filters

Please add filter 'enabled' to Stacks page

The “Mark for Deletion” in “Organization Settings” is awfully close to other buttons in the menu. It seems very dangerous to have this option so close to other buttons without confirmation if clicked. I’d suggest moving this button so<img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/ss-0193bc1c-4235-76a0-a415-b92c863809c3.png" data-width="100%" data-align="left">mewhere else and adding a confirmation after clicking

Move the "Mark for Deletion" button

Our Company uses a monorepo. All company code, including terraform, is in this repo. Because of this, the repo is quite large, and can take time to checkout / download. We’d love it if we could sparse checkout the terraform subdirectory since that’s all Spacelift needs. Maybe add it as a stack setting under source control. Scenario:An engineer needs to touch multiple stacks in their PR. That means they need to wait for all stacks to terraform plan before merging. Each stack has to pull their branch and run terraform… which means that every second we can shave off pulling their branch, the faster they can get feedback.

Support Git Sparse Checkouts

While documentation clearly states that EC2 instances must be able to reach S3 and public Internet destinations, I believe that the documentation should be more explicit about the need for a NAT Gateway or Egress-Only Gateway. By the way, kudos for making spacelift endpoints reachable by IPv6.

Private Worker Documentation Enhancement  for AWS EC2-based Workers

Spacelift Provider

Import documentation for spacelift_aws_integration should be improved.

Help Center

Security

Improvement

Announcement

spacelift

👀 In Review

❌ Rejected

⬆️ Gathering votes

🗑️ Archived

🔭 Discovery

Ansible

Blueprints

CloudFormation

IaC Workflows

Resources

Spacectl

Pulumi

Terraform registry

Stack Dependencies

Notifications

OpenTofu

Helm

Self-hosted

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 <a target="" rel="noopener noreferrer nofollow" class="link" href="https://docs.spacelift.io/product/feature-requests">guidelines</a> before posting 📖