You are unable to create stack dependencies without space admin

As an example, when iterating on login policies, every change invalidates all active sessions for the affected account. This creates a feedback loop: authors must repeatedly log back in (and disrupt other users' sessions) each time they test a policy modification, even for minor fixes like correcting a role name. The existing policy simulator helps validate syntax and basic logic, but it does not catch real-world authorization issues. For example, a policy may reference a role name like writer instead of the correct space-writer. The simulator evaluates the policy as valid, but the role doesn't actually grant the intended permissions in practice. These kinds of bugs are only discoverable through live testing — which currently means deploying to production and invalidating sessions.

When using OIDC API keys for authentication, JWT teams/groups claims are completely ignored, only the sub claim is processed. Teams must be pre-configured statically when creating the OIDC API key, making it impossible to pass through user group/team information dynamically at runtime. We are building a custom Backstage integration with Spacelift to enable self-service infrastructure provisioning with per-user permission boundaries. The Backstage plugin is not suitable as it uses a single admin API key. We need OIDC API keys to pass through the current user and respect Spacelift login policies, as is currently possible with SAML via input.session.teams. With thousands of team/service combinations, the existing workarounds (static API keys per team or subject-based encoding) are not viable at scale.

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.

It would be helpful to set a private workerpool as the default for all stacks organization-wide.

State import is only available through the Spacelift UI. Users must manually click through each stack one by one to import state files. For customers migrating large numbers of stacks, this is a significant manual bottleneck. Desired behavior A CLI command (e.g. spacectl stack state import) that accepts a state file path and a stack identifier, allowing state import to be scripted and automated as part of a migration pipeline.

Please implement RBAC for source code integrations. We do not allow our user-base to assume ‘space admin’ privileges. We make the most of the new custom roles feature to allow customer teams to create their own stacks. However, we have to manage their source code integrations on their behalf as there are no available RBAC actions that can be assigned to custom roles to create Github / Gitlab / Bitbucket integrations. Could you please implement this? It would vastly simplify the administrative overhead. Many thanks and loving your work.

Add data sources for working with templates in the Terraform provider, such as spacelift_templates to list templates and spacelift_template_version_by_name to resolve a version by name (for example 1.0.0).

When a run fails unexpectedly, stale Terraform state locks are sometimes left behind. Request to have this condition detected and automatically clean up locks that were created as part of a run.

We would like the ability to share private worker pools across spaces without requiring space inheritance to be enabled. Ideally, this would support sharing between sibling spaces, in a similar way to how modules can currently be shared.

I would like to be able to systematically monitor our worker pool to get quantitative data on our internal developer experience as our engineers all share the worker pool to run their IaC. I would like to use those metrics to improve decision making on the number of workers we need for our organizations needs.

Templates currently resolve the VCS repository field at publish time, meaning the repository is baked into the template version and can't be provided as a dynamic input. This prevents using Templates for use cases where the same stack configuration needs to be deployed across multiple repositories - e.g. a "Stack Vendor" template that engineers deploy from to onboard their repo.

“Mark version as bad” is informational only. Enterprise customers need a structured lifecycle so module authors can deprecate versions with a grace period and then block unsupported versions without maintaining brittle external OPA logic. In many organizations, infrastructure patterns are encapsulated into approved modules (e.g., networking, S3 buckets, IAM roles, etc.). When these patterns are modularized, developers can safely self-serve infrastructure by consuming those modules rather than building resources directly. Proposed solution Add first-class lifecycle state for each module version: active deprecated (optional sunset_date) unsupported Ideal behavior Using a deprecated version: plan succeeds but emits a warning stating it’s deprecated, recommended version, and sunset date (if set). Using an unsupported version: plan fails (hard stop). Acceptance criteria Registry UI shows lifecycle state per version and (if applicable) sunset date. Lifecycle state is persisted per version and queryable via GraphQL. Deprecated usage generates a warning surfaced in the run. Unsupported usage blocks the run automatically.

It looks like the current tools in the MCP server only allow either getting a specific run using a stack id and run id, or listing the runs in a stack. For some use cases it would be more efficient to have a tool that allows searching or filtering the runs. In particular so that an agent can find the proposed runs for a pull request based on the commit id

We’d like to be able to manage the integrated Slack channels and their scopes via a Terraform resource in the Spacelift provider

Add server-side GPG signature verification when providers are uploaded to Spacelift's registry. Currently, Spacelift accepts providers even if the signature file is corrupted. Validating the signature on upload would catch corruption regardless of whether it happened on the client side or in transit, preventing broken providers from ever being published.

Today, we have stack specific secrets that live in Azure Key Vault. To use them in Spacelift, we end up duplicating them into a Spacelift context or stack environment variables, so we have to maintain the same value both in Key Vault and in Spacelift. That creates extra work, increases the chance of drift, and makes rotation harder. What I would like is a native way in Spacelift to reference an external secret store, starting with Azure Key Vault. For example, instead of pasting the value into a context, I want to be able to define something like “this variable comes from Key Vault secret X” and have Spacelift fetch it at runtime using the stack’s identity, service principal, or managed identity. This is similar to how Azure DevOps variable groups can pull from Key Vault, if the identity has access, the secret becomes available as a variable during the run.

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.

We use stack contexts and environment variables to store useful metadata, such as the version being deployed. However, notification policies do not have access to those context variables. Because of this, we have to run custom scripts before the plan step to expose values as flags, just so notifications can read them. It would be much cleaner if notification policies had access to the same variables that plan policies do, including context-attached environment variables. This would remove the need for workarounds and simplify our notification logic.