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.
💡 Feature Requests
5 days ago
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.
💡 Feature Requests
5 days ago
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.
💡 Feature Requests
7 days ago
OpenTofu
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.
💡 Feature Requests
7 days ago
OpenTofu
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.
💡 Feature Requests
7 days ago
Stacks
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.
💡 Feature Requests
7 days ago
Stacks
🔭 Discovery
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.
💡 Feature Requests
12 days ago
🔭 Discovery
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.
💡 Feature Requests
12 days ago
➡️ Planned
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.
💡 Feature Requests
12 days ago
➡️ Planned
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.
💡 Feature Requests
12 days ago
⚙️ In Progress
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
💡 Feature Requests
About 1 month ago
Stacks
⚙️ In Progress
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
💡 Feature Requests
About 1 month ago
Stacks
🔭 Discovery
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.
💡 Feature Requests
21 days ago
Stacks
🔭 Discovery
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.
💡 Feature Requests
21 days ago
Stacks
⬆️ Gathering votes
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
💡 Feature Requests
About 1 month ago
UI/UX
⬆️ Gathering votes
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
💡 Feature Requests
About 1 month ago
UI/UX
⚙️ In Progress
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.
💡 Feature Requests
16 days ago
⚙️ In Progress
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.
💡 Feature Requests
16 days ago
➡️ Planned
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.
💡 Feature Requests
16 days ago
Stacks
➡️ Planned
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.
💡 Feature Requests
16 days ago
Stacks
🔭 Discovery
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.
💡 Feature Requests
16 days ago
🔭 Discovery
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.
💡 Feature Requests
16 days ago
🔭 Discovery
Spacelift Prometheus Exporter Being Actively Developed?
Are there any plans to add metrics / pivots around spaces and individual stacks?
💡 Feature Requests
16 days ago
Integrations
🔭 Discovery
Spacelift Prometheus Exporter Being Actively Developed?
Are there any plans to add metrics / pivots around spaces and individual stacks?
💡 Feature Requests
16 days ago
Integrations
🔭 Discovery
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.
💡 Feature Requests
25 days ago
🔭 Discovery
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.
💡 Feature Requests
25 days ago
⚙️ In Progress
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.
💡 Feature Requests
About 2 months ago
Resources
⚙️ In Progress
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.
💡 Feature Requests
About 2 months ago
Resources
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”
💡 Feature Requests
4 days ago
Notifications
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”
💡 Feature Requests
4 days ago
Notifications
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.
💡 Feature Requests
4 days ago
Blueprints
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.
💡 Feature Requests
4 days ago
Blueprints
🔭 Discovery
Blueprint context: Allow CEL in input definitions
Allow the following: inputs: - id: instance_name name: Instance Name default: ${{ user.login }}
💡 Feature Requests
5 days ago
🔭 Discovery
Blueprint context: Allow CEL in input definitions
Allow the following: inputs: - id: instance_name name: Instance Name default: ${{ user.login }}
💡 Feature Requests
5 days ago
Blueprint stack creation errors are useless
The error shown in this screenshot provides no useful information to me. Please improve it ❤️
📝 Feedback
5 days ago
Blueprint stack creation errors are useless
The error shown in this screenshot provides no useful information to me. Please improve it ❤️
📝 Feedback
5 days ago
🔭 Discovery
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
💡 Feature Requests
5 days ago
🔭 Discovery
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
💡 Feature Requests
5 days ago