Feature Requests

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 📖

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

🔭 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

2

⚙️ 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

🔭 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

2

🔭 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

2