Allow push policies to cancel tasks

You can end up with an infinitely delayed tracked run in the following situation: Have a task that ends up in an Undecided approval state and is thus waiting indefinitely for approval Have a tracked run triggered by any means (manually, push policy, etc.) The tracked run is blocked by the pending task. The tracked run sits in the Queued state until the task is manually approved or rejected. We had a tracked run sit in queued for 4 days unintentionally because of a task that was pending approval. While we can notify for tasks pending approval, I have a feeling that we would want tracked runs to take precedence over tasks (if this undesirable, then you could lock the stack perhaps). We could theoretically implement this ourselves using a push policy, except that in reality, task runs pending approval don’t appear in the push policy input in_progress_runs property.

Add dependency stack metadata to stack policy inputs

We would like the option of creating plan policies to warn when stacks that depend on each other from the same repo are not running at the same commit or branch. For example if stack B depends on stack A we’d like to see in the input json data some basic metedata from the stack A run that triggered stack B. This should include the repo, branch and commit but ideally includes the json “stack” data.

Stack names no longer need to be globally unique within a Spacelift tenant

Since we generate a unique slug for Stacks within a Spacelift tenant, we no longer require Stack names to be unique.

Local Preview Should Support Symlinks or Explicitly Allow Them

In workflows where Terraform variable directories are symlinked from an external repo, local preview fails to render changes properly. Currently, the CLI does not follow symlinks, and ignores symlinked directories — especially when also listed in.gitignore. As a result, developers are forced to: Delete the symlink Manually copy the target directory into the project Modify.gitignore temporarily to allow the content to be picked up Requested Enhancements: Add a CLI flag such as --follow-symlinks or --include ./path to explicitly whitelist symlinked directories Improve.gitignore handling in local preview to support more flexible inclusion logic Why It Matters: While the impact is minor and there are workarounds, this limitation creates friction in common enterprise workflows — especially where variable sets or config fragments live in external repositories and are symlinked in. Supporting this would improve usability and encourage wider adoption of local preview.

Fix Search Bar Focus Loss on Page Load

When loading the Spacelift app, the user often clicks quickly into the global search bar to begin typing, but focus is lost after a brief delay, likely due to a script re-rendering part of the page. This creates a small but persistent UX annoyance for fast users. Requested Behavior: Ensure that once the user clicks into the search bar, it retains focus — even during/after DOM rehydration or JavaScript load routines. Why It Matters: This is a minor fix, but improves polish and reduces friction for frequent power userswho move quickly through the interface.

Stack List “Updated at” should reflect last applied run, not any run

On the Stacks → All Stacks page, the Updated at column updates whenever a run finishes—no matter whether it applied successfully, failed, or was discarded after a plan‑only run. As a result, simply kicking off a speculative/plan‑only run bubbles that stack to the top of the list, even though the live infrastructure never changed. Why it’s a problem I use the column to spot which stacks have had real infrastructure changes or gone the longest without them. If a plan‑only (speculative) run finishes, its stack’s Updated at timestamp becomes “just now.” When you sort the stack list by that column, those speculative stacks jump to the top. The genuinely changed stacks—whose last apply happened earlier—get pushed lower in the list, so you don’t see them at a glance. Auditing recent production changes becomes noisy. Requested change Have Updated at reflect the timestamp of the most recent run that entered the Apply phase, regardless of outcome: Run Result Run result Should update “Updated at”? Applied successfully Yes Apply failed / partially applied Yes Apply cancelled Yes (when passed plan phase) Plan‑only (no apply attempted) No No‑op (plan detected no changes) No I’m neutral on whether this is handled by a single ‘Updated at’ field (showing any run that reached Apply) or by separate fields for ‘Last apply attempt’ and ‘Last successful apply.’ I mainly need to exclude plan‑only runs from the default sort. Benefits Quickly surfaces stacks whose resources were recently touched—or whose apply just failed and needs attention. Keeps speculative plan noise out of day‑to‑day monitoring and audits. Aligns “Updated at” with real‑world impact

Disable commit ignore banner organization wide

As a Spacelift platform administrator, I want the ability to disable commit ignore banners on the Tracked runs page of a stack organization-wide.

Overall PR view on Dashboard

It would be handy to have a view on the Dashboard of all open PRs with proposed changes in a single place rather than having to click into every stack

Migrating and Reparenting Stacks Between Spaces While Preserving Run History

There is a need to migrate and reparent stacks between spaces while preserving the run history. Currently, moving stacks between spaces can result in loss of execution history, which makes it difficult to track the progress and state of stacks over time. The goal is to use the Spacelift API to facilitate this operation, ensuring that when a stack is moved from one space to another, its run history remains intact. This is important for maintaining visibility and continuity across environments, as it allows users to reorganize their infrastructure without losing valuable context on the stack’s performance.

The “Ready” State Not Showing as Filterable

There’s a concern that the "Ready" state does not appear as a filterable option in the stack filter list. This state is crucial, as it helps identify stacks that are in a ready-to-deploy or healthy state but currently isn’t included as a filterable criteria in the UI. The lack of this filter makes it more difficult for the team to quickly identify and manage stacks that are in a ready-to-go state, especially when managing a large number of stacks. Including the "Ready" state in the filter would enhance usability and streamline their workflows, allowing them to sort and manage stacks more efficiently.

Plans to Make Stack Columns Filterable/Sortable Directly

I'd like to be able to click on "State" or "Issues" to both filter or sort. Right now only the name / starred columns appear to be sortable.

Spacelift Prometheus Exporter Being Actively Developed?

Are there any plans to add metrics / pivots around spaces and individual stacks?

Make the API easier / friendlier to use

GraphQL is a new skill for REST developers. This post is not about GQL. I think GQL is great. This feedback is about everything Spacelift do to make the Developer Experience 10x worse than it could be. When the Spacelift API is difficult to use, it discourages growth of an ecosystem around the API. There are no utilities or apps of note using the Spacelift API and I believe part of the reason is that the API is so difficult to use. 1. The documentation is sparse writing + looms cosmetically, the page is a nightmare. Many images are poorly sized and it’s hard to keep track of where you are in the header hierarchy. Understanding how to authenticate is fundamental, and yet it is poorly documented. The key idea is “Add a header Authorization: bearer $YOUR_JWT but you won’f find this written on the page anywhere! (If you look closely, it’s in a code snippet) Instead we document five ways to get a JWT. One of which is specific to Github Actions. Two of which are only relevant for personal testing (spacectl & PAT). The docs and UX for getting a static API key suck. You’re forced to download a file containing the secret rather than copy to clipboard. The file contains two secrets and it’s not clear how they differ. The file also doesn’t contain the key ID, which is required during authentication. You have to go back a step, find your new key in the web UI, and copy the ID manually. Docs for graphiql are simply wrong and do not explain how to authenticate (which is required to access schema). 2. No schema is published, adding a hoop to codegen users (figuring out how to authenticate without having the schema) I spent 30mins trying to do this and eventually figured out the magical incantation: npx get-graphql-schema https://demo.app.spacelift.io/graphql > schema.graphql I still have no idea how to download the schema from our own account subdomain, despite Spacelift staff insisting that using the wrong schema will lead to ruin. Major companies like Github and Shopify run graphql APIs, and they can publish easily accessible URLs to download their schema. There’s no reason Spacelift cannot do the same. 3 There are only two sources of existing code to learn from. spacectl and https://github.com/spacelift-io/spacelift-api-examples which both have no “client sdk” layer and rely on non-reusable gql queries plus untyped JSON unmarshalling Please make API development better.

Stack Resources tab should show address instead of name

Since names can be repeated (like “this”), displaying the full address will help to identify the resource/output/whatever in the list. Currently, you can find yourself checking entry by entry until finding the proper resource by looking to the address, which is a time consuming task.

Allow modification of the PR comment author in policies

Allow for the option to set the PR comment author in policies such as “Notification as a comment on your pull request which summarises your logs”

Allow tags for blueprint VCS source

Right now only branches are supported: vcs: branch: branch-name namespace: namespace-name repository: repo-name provider: AZURE_DEVOPS We are planning to use blueprints to allow developers to deploy infrastructure based on our reusable Terraform modules. Our reusable modules use tagging for versioning, and so we would like our blueprints to target a specific tag so that when we merge breaking module changes to the main branch, we do not have to update our blueprints immediately.

Blueprint: input "float" validation is wrong

It seems to assume integer inputs only

Blueprint context: Allow CEL in input definitions

Allow the following: inputs: - id: instance_name name: Instance Name default: ${{ user.login }}

Blueprint stack creation errors are useless

The error shown in this screenshot provides no useful information to me. Please improve it ❤️

Blueprint: advanced inputs

Some inputs in a Blueprint are not for normal use, eg they change various parameters we might need during debugging but not during normal use. I wish these inputs could be hidden by default in an “Advanced Options” accordion. A broader feature request might be: Allow assigning inputs to an optional “Section”. Sections only affect the UI of blueprint creation screen. Inputs without a section are shown unchanged from today. Inputs with a section are grouped by section and shown in collapsed-by-default accordions. Section inputs appear after non-section inputs. Example: inputs: - id: name name: Stack name - id: ttl_hrs name: Stack TTL (hrs) - id: repo name: VCS repo to use default: myrepo section: Advanced - id: autoconfirm type: boolean default: true name: Autoconfirm tracked runs - id: branch name: VCS branch to use default: main section: Advanced This results in a stack creation screen ordering of: name ttl_hrs autoconfirm Advanced Section (collapsed by default) repo branch