Ability to decide when to forcibly stop runs

Currently, pressing the "Stop" button sends a SIGINT signal to the process, followed by a 30-second grace period. If the process hasn't stopped by then, a SIGKILL signal is sent. This isn't ideal. Stopping and cleaning up sometimes takes longer than 30 seconds. Forcibly killing the process often leaves behind a dangling state lock, an out-of-sync state file, or a corrupted state file. I'd like the "Stop" button to change to "Forcibly stop" after the first press, letting me decide when to force termination. If I don't press it again, the run timeout would eventually stop the process automatically.

Project-level filtering for AzDO VCS Integration

Implement a way to filter by project in Azure DevOps when creating a VCS integration, so that such an integration can only be used for git repositories within that project.

Execute Ansible-vendor tracked runs in stack concurrent

As a platform engineer, we are building a platform (currently in proof-of-concept stage) that uses Ansible-vendored Spacelift stacks to execute Ansible playbooks. These stack runs are triggered by orchestration via API such that each stack run executes against one EC2 instance as they are launched. Due to the blocking nature of stack runs, this limits the stacks ability to run multiple Ansible playbooks concurrently for a stack. Tasks are not a valid alternative as they do not provide any benefit to the resource/host configuration management natively built into Spacelift stacks. Jubran Nassar is familiar with our use-case. If we end up selecting Spacelift as our tool for our platform, this will be important to solve, but marking as nice to have for now. We should know more in the next few weeks.

Better support for adhoc ansible runs

As an infrastructure owner, I would like to be able to execute arbitrary ansible playbooks using an existing ansible stack. Spacelift currently locks each stack to a single playbook, which makes it difficult to make use of ansible’s full capabilities for managing the operating systems and applications on our EC2 infrastructure.

spacectl: Add --wait / exit-on-complete for stack tasks

In agent workflows, models often use spacectl stack task --tail, which doesn’t exit and stalls agents. Add a --wait (or similar) mode that returns when the task completes (with success/failure exit code) and document it as the recommended option for automation/agents. Example: spacectl stack task --id --wait "terraform import ..." exits when done; --tail remains for interactive streaming.

MCP: Reduce token-heavy outputs + document tool output format

MCP tools can be inefficient with token usage. For example, List Resources may return extremely large outputs (hundreds of thousands of characters / thousands of lines), exceeding model tool limits and causing agents to resort to brittle grepping/jq workarounds. Please introduce more token-safe defaults (pagination/limits/filtered output) and improve documentation explaining the tool output format so this doesn’t happen. Example: Listing resources could return a small summary by default instead of 14k+ lines.

Programmatic access to Spacelift managed state

We have thousands of stacks. The definition of the stacks is multilayered. (I.e. we have a “base”. The on top of the base, we build a “foo” and “bar” type. Then, for example, we could add an “aaa” on top of foo. And then, eventually, we create a stack on top of those other definitions.) This works fine in most cases. But, when we have to make a change to the “base” layer, we have to manually view any proposed changes. For even a dozen or so, this becomes painful. It is completely untenable to do that for hundreds, to say nothing about 1000s. This would be much easier if we had a way to reference the state locally. Thus, we could do a local terraform plan just to figure out the scope of a proposed change. To be clear; I am only talking about “read only” access to the state. Ideally, we could annotate that TF somehow so that we did NOT have to make any change to run tf plan locally. And however it was set up, it would not interfere with the normal “file injection” Spacelift does. FTR; I am aware of: https://docs.spacelift.io/vendors/terraform/state-management#exporting-spacelift-managed-terraform-state-file Doing that for dozens of states/stacks is EXTREMELY time consuming. And it would be a non-starter for hundreds or more.

Terraform and Argo CD Deployment Orchestration

We would like a way to deploy infrastructure and application changes together in a single flow. Today, infra changes go through Spacelift (Terraform) while app changes are handled separately via Argo CD, which forces developers to update multiple repos and tools for one release. We’re looking for orchestration or integration with Argo CD so Terraform runs and app deployments can be coordinated, without replacing their existing GitOps setup.

Deny actions in custom roles

Currently, the custom role definition supports only whitelisted role actions. With the number of those constantly increasing (which is great by the way, kudos to the team!) it’s getting hard to track new ones and evaluate/adjust existing role definitions. In this regard, would be great to have an ability to deny certain actions from the superset of allowed ones. For example, I want to give internal users ability to manage all aspects of the space, except for worker pool. Currently, the only way in this example is to maintain the custom role with curated list of actions without WORKER_POOL_ ones.

Helm chart: support templating annotations for CRDs (Argo CD ServerSideApply)

When deploying spacelift-workerpool-controller via Argo CD, applying the WorkerPool CRD (workerpool-crd.yaml) requires ServerSideApply=true (optionally Replace=true). Since CRDs are shipped under /crds and aren’t templated, it’s currently not possible to set argocd.argoproj.io/sync-options via values.yaml. Please add Kyverno-style support for configuring CRD annotations from values to allow fully automated GitOps sync.

Include the run_id of an upstream stack, and any other metadata in policy inputs.

We currently have a stack that when triggered triggers it’s dependencies. We want to create one notification policy and have a unique id that we can use for the entire dependency chain since run.id is per stack. I tried to have the upstream’s stacks run_id as an output, but when dependent stacks get triggered the policies do not contain this information, nor the run_id of the upstream stack. For our purposes just a triggered_by_run_id would be perfect, but in general the feature is to include all possible metadata. Especially on the inputs the stack received from the output of an upstream stack. Something like inputs.triggered_by_outputs would be nice too.

Detach tags from the stack graphql api

Since tags are so important in spacelift, It would be nice if there are easier ways to bulk edit.

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

Worker Pool Job Routing

When drift detection is enabled on a stack, you are forced to use your self-hosted worker pool.

Remove context only appears when hovering priority

The fact that the delete context from stack button only appears when you hover over the priority of an assigned context is asinine and infuriating. Can this please be split out into its own button either under a “…” or a dedicated “Delete” button?

Allow merging multiple stack notifications into common GitHub PR comment

We sometimes get PRs which affect many different Stacks. Because each Stack posts an individual comment with the proposed run status, the PR conversation section can become bloated and basically unusable. Also, we have hit GitHub API rate limits and the comments may have contributed here. We would like there to be an option to merge proposed runs into a single PR comment which would gather all proposed runs for given PR. We keep comment content quite short, so the GitHub comment character limit should not be an issue.

Improve display / readability of input “type” in Modules Documentation page

On the Modules documentation page, the “type” column for input fields is truncated/abridged, which becomes especially problematic when the input type is a complex object with nested fields. Current issues: The full type is only visible on hover. Even on hover, readability is poor. This makes it difficult to understand complex input structures at a glance. In comparison, tools like Terrareg display the full type in a separate column, which is easier to read.

Error when renaming Login Policy to same name but capitalized letter

Created a login policy “login” and attempted to rename it to “Login” but got the error message “A policy with this name already exists in the account.” even before submitting the form to save change. Confirmed this error behavior is consistent with other login policies. Workaround was to rename the Login Policy to a placeholder name and then rename it again with the capitalized “Login”. Error seems to be something tied to the client side input validation.

Notification Policy - Pull Request comment not auto-resolved

By default, Pull Request comments (as outlined in the docs: https://docs.spacelift.io/concepts/policy/notification-policy#creating-a-pr-comment) are auto-resolved/closed - at least on Azure DevOps. This default behaviour is fine for the built-in PR integration which simply reports proposed changes on a PR run back to the Azure DevOps UI itself. However, if the Notification policy is being used to flag something which requires user input, it would be useful to be able to turn off this auto-resolution behaviour. That way the comment would act like a normal user comment which needs some action (or discussion) to resolve. Without this, comments can be ignored and changes can be merged without any action being taken. On Azure DevOps this is enforced under Repos > Policy > Check for comment resolution. On Github is looks like there is a “Require conversation resolution before merging” setting. Something like this could be implemented: package spacelift pull_request contains { "commit": run.commit.hash, "body": "", "auto-resolve": false, } if { ... } Where the auto-resolve input defaults to true, so as not to break existing behaviour.

Better observability for run times and worker utilization

We run self hosted Spacelift and would like the following observability. Run Execution Metrics End-to-end run duration (histogram): Distribution of total wall-clock time from run creation to terminal state. Enables tracking p50/p90/p99 durations, detecting regressions, and setting SLOs on deployment latency. Should support labels for stack, space, run type, and terminal state. Worker Pool Metrics Runs queued for workers (gauge): Count of runs currently waiting for a worker, queryable over time. Enables alerting on queue saturation and right-sizing worker pools. Should support labels for stack, space, and worker pool. Per-run worker wait time (histogram): Distribution of time each run spends waiting for a worker before execution begins. Should support labels for stack, space, and worker pool.