We would like Spacelift to support exposing its managed Terraform/OpenTofu HTTP state backend in a way that allows authorised users to run plan and apply locally against the same state backend used by Spacelift-managed stacks. The goal is to support a break-glass operational process where, in exceptional circumstances, we can run Terraform/OpenTofu locally while still using Spacelift as the source of truth for state and locking. Ideally, this would allow local Terraform/OpenTofu runs to: Use the Spacelift-managed state backend directly Respect Spacelift state locking Prevent concurrent Spacelift pipeline runs while local operations are in progress Avoid having to manually reconcile or “fold back in” state changes made outside of Spacelift

Support read-only operation mode in order to support strict safety/security boundaries around the use of the Spacelift MCP.

Spacelift currently requires all policies to use the hardcoded package name “spacelift”. This request is to allow users to configure custom package names or support multiple packages per policy.

We would like the ability to conditionally enable or disable stacks defined in a template based on input values. A common use case is selectively deploying optional components, for example via a boolean input such as enable_service_x. When set to false, the corresponding stack should not be created or executed. This becomes particularly important in templates that define multiple related stacks, where some components are optional depending on environment, tenant, or feature flags. Expected behaviour: Stacks can be conditionally included or excluded based on template inputs. Disabled stacks are treated as if they do not exist for that run. Any dependencies referencing a disabled stack are ignored rather than causing errors. The dependency graph is resolved dynamically after conditions are evaluated.

If you have a module that references a local image from it’s repo in it’s README, when the module gets published to Spacelift the link it broken. The workaround is to publicly host and expose images so they’re available to Spacelift. I’d like to request a feature that renders markdown and README files the same in Spacelift as they are in GitHub so we don’t need to develop a new process (and with maintenance and overhead) for exposing things like architecture diagrams publicly.

Requested Solution Add support for routing runs to different worker pools based on run type. The most common use case is: PROPOSED (PR previews) → public worker pool TRACKED (main branch deploys) → private worker pool This could be implemented as a new policy type (e.g. WORKER_POOL) or as a per-stack configuration with two fields: worker_pool_proposed and worker_pool_tracked. Use Case Organizations on plans with a limited number of private workers want to use them efficiently. Private workers are ideal for tracked runs — they cache Docker layers and run on faster hardware. PR previews (proposed runs), however, are frequent and short-lived, making the public fleet a better fit for them. Today, worker pool assignment is stack-level only. Setting a private pool on a stack routes all runs — both proposed and tracked — to that pool, consuming the private worker even for PR previews. This forces a choice: either waste private worker capacity on previews, or don't use the private pool at all.

In order to support sovereign European code repositories without losing some of the quality of life features that GitHub and Gitlab provide via the integration, we would like a fully fledged Codeberg integration with Spacelift, or the option to write our own.

Requesting the GitLab integration be expanded to a first class integration similar to how GitHub is treated. Having to manually setup webhooks for each repo is one/or more steps that have to be done manually before stack creation is able to happen.

Propose a UI re-work to make the Blueprints screen similar in style as the templates market place. I love the new template’s market place as a way to create a self-service for our developers but the feedback from them is that the blueprints UI could use the same overhaul, or even combined into one cohesive UI element. Then the engineer/developer is able to decide which type of deployment they want to create, a blueprint or a template.

We would like Spacelift to support optional delegation of login policy management to space admins. In larger organisations, login policy ownership often needs to sit closer to the teams who own and operate individual spaces. This is especially important where spaces are created dynamically through Terraform, or where child spaces are managed independently and root admins do not have enough context or visibility to manage every login policy centrally. The current model requires root admins to manage login policies for all spaces. That creates an operational bottleneck, slows down onboarding, and makes it harder to scale Spacelift across multiple teams, business units, or platform domains. Ideally, root admins should be able to decide whether login policy management can be delegated on a per-space basis. Delegated space admins should only be able to manage login policies within their own space, or within explicitly permitted child spaces, without affecting the root space or sibling spaces. Root admins should retain central control, visibility, and the ability to revoke delegation if needed.

You are unable to create stack dependencies without space admin

Currently, Spacelift's OIDC API Key feature requires the OIDC provider JWKS endpoint to be publicly reachable (or reachable from Spacelift's egress IPs), because token validation is performed server-side by the Spacelift control plane. This blocks adoption when operating in fully private or air-gapped environments where exposing the JWKS endpoint externally is not permitted by security policy. Requested behaviour: Provide a mechanism to route OIDC JWKS validation through a private worker pool or VCS agent, so users can use OIDC API Keys without requiring a publicly accessible OIDC endpoint.

Tag-triggered runs do not include the triggering tag in the run environment. There is no analogue to TF_VAR_spacelift_commit_branch or TF_VAR_spacelift_commit_sha for tags, despite the tag being the trigger and being available internally (visible in the UI and queryable via the GraphQL API as stack.run.commit.tag). Any consumer that needs the tag inside Terraform has to fetch it out-of-band.

It would be nice to be able to implement some type of logic into blueprint templates. For example, if a specific input is selected only deploy a specific stack.

It would be nice to have Spacelift automatically send browser desktop notifications when actions complete if you have a stack or a run open in a tab. For example, if I open the page for a run, it would be nice to see a desktop notification when the plan is finished and it’s ready for approval. Or it would be nice to see a notification when the tracked run / apply completes.

When a stack has been confirmed, it can not be cancelled or stopped when in the queue and has to be picked up by a worker to enable stop / force quit.

Hi folks, There is a new feature for terraform that support ephemeral resources which don’t store the secret content on terraform state, so I woul like to request the spacelift_mounted_file and spacelift_environment_variable to support it. https://registry.terraform.io/providers/hashicorp/vault/latest/docs/ephemeral-resources/kv_secret_v2 Best, Marcelo

A button to copy the entire log text of a run stage without color characters would be nice, but also, it’s very hard to select text to copy because after it scrolls a bit you lose your selection (and just fixing the selection would probably be enough)