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

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.

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.

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.

You are unable to create stack dependencies without space admin

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.

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

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.

We use infracost by attaching the infracost to enable spacelift’s integration. As per the docs we also attach a auto-atatch a context with our api key as an env var with the infracost label. We would like to be able to disable the infracost integration when a run is triggered via drift detection.

Problem The current BYOM configuration accepts an API key for a supported provider (Anthropic, OpenAI, Gemini), but does not allow specifying a custom base URL. Enterprise organizations typically route LLM traffic through an internally-hosted proxy or gateway (e.g., LiteLLM) to enforce security controls, model governance, and cost management. In these environments, using a personal or team API key tied to a commercial provider account is not viable. All traffic must go through an internal endpoint on an approved FQDN. Requested Solution Add a custom base URL field to the Spacelift AI BYOM configuration, alongside the existing API key field. This would allow Spacelift to direct AI requests to any OpenAI-compatible endpoint (e.g., https://llm.internal.example.com/v1) rather than only to a commercial provider's public API. This pattern is standard across OpenAI-compatible clients (OPENAI_BASE_URL, openai.base_url in the Python SDK, etc.) and is how tools like LiteLLM, Azure OpenAI, vLLM, and Ollama are accessed. Use Case Our organization runs a centrally-managed LiteLLM instance serving internally-approved models via an OpenAI-compatible API. We want Spacelift AI features (plan summaries, resource explanations, policy suggestions) to use this internal endpoint, but the current BYOM flow only accepts a provider API key, with no way to redirect the base URL. Priority High. This is a blocker for enterprise customers with internal model governance requirements.

Not all MCP clients can do OAuth, so it would be nice for the nice for the Spacelift MCP server to support token based auth in https://docs.spacelift.io/integrations/api-development-with-mcp.html Example from Honeycomb: https://docs.honeycomb.io/integrations/mcp/configuration-guide#setting-up-an-api-key

Problem We use the admin stack pattern with for_each over auto-discovered config files. When a PR introduces a new config (i.e., a net-new stack), the PR gets no plan preview because the stack doesn't exist yet. Reviewers merge blind. Post-merge automation works — trigger policies handle auto-triggering newly created stacks. But pre-merge plan visibility for stacks that don't yet exist has no platform-native solution. Adding new infrastructure is when plan previews are most valuable. Modifying existing stacks has full visibility today. Creating new stacks has zero visibility until after merge. Proposed Feature When an admin stack's proposed run on a PR shows new spacelift_stack resources would be created, Spacelift should automatically run speculative plans for those new stacks using the PR branch and post the results as PR comments. Suggested UX: Opt-in setting on the admin stack (e.g., "Enable speculative plans for new stacks discovered in PRs"). After the admin stack's proposed run completes and shows new spacelift_stack resources, Spacelift triggers speculative plan-only runs for those stacks using the PR branch. Results appear as PR comments labeled distinctly (e.g., "Speculative plan for new stack stack-name"). Speculative stacks are ephemeral and are cleaned up when the PR is closed or merged. Why There's No Workaround The only alternative is external automation (e.g., a CI job that detects new config files, creates temporary stacks via spacectl, triggers plans, posts comments, and cleans up). This duplicates discovery logic that already exists in the admin stack and is disproportionately complex for something Spacelift is positioned to handle natively.

It’s really confusing to see newest items at the top of the stack run history, especially when switching context between other tools where the precedent is normally later/newer items appear at the bottom. Would it be possible to get a per user config to reverse the run history ordering? I have a small css injection to fix this annoyance (imagine slack messages appearing at the top! or new comments on pull request) #runWrapper ol { flex-direction: column-reverse; }

Right now Tracked runs can only run sequentially, while proposed runs will run in parallel on the same stack. You can easily ignore multiple proposed runs inside of a push policy but this means that they are all dropped. This is a concern when any number of proposed runs is less than the number of private workers available to a stack. With a central pool it can be totally saturated, it can also cause throttling on providers. The solution would be allowing a user to specify a number of parallel proposed runs allowed before they queue. Ideally a push policy update to match the existing proposed run logic.

## Requested Solution Add an account-level (and optionally space-level) toggle: **"Disable public worker pools."** When enabled: - Stacks without a `worker_pool_id` cannot trigger runs; they fail immediately with a clear error message before reaching any worker - The Spacelift UI hides or disables the "use public workers" option when creating/editing stacks - API and Terraform provider calls that create or update a stack without a `worker_pool_id` are rejected This should be inheritable: setting it at a parent space cascades to all children, matching the existing space-based RBAC model. --- ## Use Case Our organization requires all Terraform execution to occur on internally-managed private worker pools for security and compliance. Today, this requires writing and maintaining an OPA/Rego PLAN policy, attaching it to the correct space, and accepting that the policy only fires after `terraform plan` has already executed on the public runner. A misconfigured or newly-created stack silently defaults to public runners with no preventive guardrail. A simple toggle would eliminate the need for policy-based workarounds entirely. --- ## Priority High. This is a blocker for enterprise customers with private infrastructure mandates.

Add Support for using a native Git binary to clone repositories in Spacelift. This would be really useful for teams that want more control over the checkout process, with options for partial cloning and mirror support as well.

We would like to be able to create a custom role that is able to create/update/delete policies. Currently the only way to grant stacks or users permissions to manage our Spacelift policies is through the default admin role.

We have separate AWS IAM roles for Spacelift integration attachments, so we can allow preview runs to run on unapproved code changes, without worrying about someone being able to make a change to the underlying AWS resources from their GitHub branch. This is working well, except autoattach: no longer works to attach these integrations, because it defaults to allowing writes. So we have to explicitly create every integration attachment for every stack. Is it possible to allow autoattach_read: (and autoattach_write: for symmetry) labels on AWS integrations to specify what the integration should be used for on the stacks that match?