Instead of the current behavior of drift detection runs being skipped if there are not available workers, it would be nice for there to be a separate queue for drift detection runs. The separate queue would have to be prioritized lower than the planned/tracked runs so that it is never pulled from when there are planned/tracked runs waiting to execute. This prevents users from having to space out drift detection runs evenly during off hours to ensure they all get run. It is both difficult to maintain and initially configure. There are probably many other solutions to the same problem.

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

Similar to how the SPACELIFT_COMMIT_BRANCH and SPACELIFT_COMMIT_SHA exist in the plugin execution environment as well as TF_VAR_spacelift_commit_branch / TF_VAR_spacelift_commit_sha, please add a SPACELIFT_COMMIT_MESSAGE / TF_VAR_spacelift_commit_message with the run.commit.message from the VCS webhook when available.

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

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.

Currently, when a run is triggered from a specific sha, the Spacelift UI does not show the branch, falling back instead to -. I asked this in the past in a Github issue and this is due to the difficulties of finding out the branch, as a commit can be in many branches. However, what Spacelift knows, is whether the commit sha is in the tracked branch (and that is exposed to the policies via commit_exist_on_tracked_branch. I would like that the UI of a commit sha triggered run in Spacelift does one of the following things: Either if commit_exist_on_tracked_branch is true, show the tracked branch name instead of - Or in the same line that the branch, sha, triggerer, etc information is shown, it show that the run is in a commit that belong to the tracked branch I would favour 1, but 2 would be aceptable.

We would like Spacelift to support a configurable display field for OIDC-authenticated API activity, so that administrators can choose which OIDC claim is used to represent the actor in the UI and audit logs. At the moment, actions performed via an OIDC API key appear as the key itself. While this technically identifies the credential used, it does not always identify who or what initiated the request. For audit logging, fields such as sub, or potentially another configured claim, may provide a much more useful and traceable identity. The requested behaviour is: Allow administrators to configure which OIDC claim should be used as the display value for actions performed through an OIDC API key. Show that configured value in relevant UI activity views and audit logs. Preserve the existing API key identity as supporting metadata, so it is still clear which credential was used. Avoid requiring full token storage, but retain enough selected claim information to support later audit and investigation. Ideally support a fallback behaviour, such as showing the API key name when the configured claim is missing. This would make OIDC-based automation more transparent and easier to govern. It would also help organisations trace changes back to the original requester without needing access to transient token contents that are not stored today.

We would like to request support for reusable template composition in Spacelift templates. The goal is to allow a Spacelift template to reference other templates as reusable building blocks, while still supporting local stack definitions in the same parent template. This would extend the existing template model rather than replace it. Today, templates already define user inputs and a stacks array, each stack requires a unique key, and stack dependencies are handled through fields such as depends_on and stack_dependency_references. The missing capability is the ability to reference another template from within a template and provide its required inputs explicitly. For example, we may have reusable templates such as: create_network stacks: - key: network - key: firewall_rules create_vm stacks: - key: vm add_dns_record stacks: - key: dns_record Each of these templates may contain one or more stacks. These should be reusable in their own right, but they should also be available as building blocks inside larger templates. An illustrative parent template could look something like this: inputs: - id: environment name: Environment type: select options: - dev - test - prod - id: vm_name name: VM Name type: short_text - id: dns_zone name: DNS Zone type: short_text templates: - key: network template: create_network inputs: environment: ${{ inputs.environment }} name: ${{ inputs.vm_name }} - key: vm template: create_vm inputs: environment: ${{ inputs.environment }} name: ${{ inputs.vm_name }} network_id: ${{ templates.network.network.vpc_id }} firewall_group_id: ${{ templates.network.firewall_rules.group_id }} stacks: - key: bootstrap name: ${{ inputs.vm_name }}-bootstrap depends_on: - templates.vm.vm environment: stack_dependency_references: - name: VM_PRIVATE_IP from_stack: templates.vm.vm output: private_ip vcs: reference: value: main type: branch repository: bootstrap-repo provider: GITHUB vendor: terraform: manage_state: true version: "1.5.0" - key: dns_record name: ${{ inputs.vm_name }}-dns depends_on: - bootstrap environment: stack_dependency_references: - name: VM_PRIVATE_IP from_stack: templates.vm.vm output: private_ip - name: BOOTSTRAP_ID from_stack: bootstrap output: bootstrap_id vcs: reference: value: main type: branch repository: dns-repo provider: GITHUB vendor: terraform: manage_state: true version: "1.5.0" The exact YAML schema could differ, but the important point is that a parent template should be able to contain both: references to other templates local stack definitions A referenced template would need a unique key, a template reference, and an explicit input mapping. Those inputs could come from parent template inputs, static values, outputs from a specific stack inside another referenced template, or outputs from a local stack in the parent template. For example: network_id: ${{ templates.network.network.vpc_id }} would refer to the vpc_id output from the network stack inside the referenced network template. bootstrap_id: ${{ stacks.bootstrap.bootstrap_id }} or an equivalent syntax would refer to the bootstrap_id output from a local stack in the parent template. Likewise, dependency references may need to target a specific stack, not just a whole template. For example: depends_on: - templates.vm.vm - bootstrap In this example, templates.vm.vm means the vm stack inside the referenced vm template, while bootstrap means a local stack in the parent template. This distinction matters because reusable templates will often contain more than one stack. A parent template may not always depend on the whole child template as a single unit. It may need to pass an output from, or depend on, one specific stack created by that referenced template. This would allow organisations to build a proper catalogue of reusable templates, including both simple stack-only templates and larger templates composed from other templates and local stacks. For example: create_network - reusable template owned by the networking team - contains one or more network-related stacks create_vm - reusable template owned by the virtualization team - contains one or more VM-related stacks deploy_gitlab - higher-level self-service template - references create_network - references create_vm - defines its own local bootstrap or configuration stacks - maps inputs and stack outputs between all of them

I would like the ability to set the name of the template that will be deployed. For example a top level field ‘name: ${{ inputs.environemnt }}-${{ inputs. github_repo }}-etc...”

I would like to deploy 1 Template to 3 different spaces (dev,stage,prod) but unfortunately in the YAML configuration ‘space’ is a top-level field which means it can only take 1 space at a time. If ‘space’ was under stacks then i could easily achieve this. I believe blueprints have the spaces under the stacks?? For Example: stacks: - key: dev name: dev space: dev-space - key: stage name: stage space: stage-space - key: prod name: prod space: prod-space

If a new stack is created an has auto-apply enabled, go ahead and trigger the apply based on the DAG. I don’t want to have to manually trigger each stack.

» Spacelift answer Thanks for your patience! the issue is that when Spacelift serves a module via tfr://, it uses GitHub's auto-generated tarballs, which don't include git submodule content. That's why the terraform-aws-apigateway-v2 directory is empty, and why git::ssh:// works fine (it does a real git clone). Unfortunately git submodules aren't supported via the module registry right now. Your best options are: Stick with git::ssh:// for this module Copy the submodule content directly into your repo it's not on the roadmap as far as I know. Feel free to raise it at https://feedback.spacelift.io so the team can track interest. » My answer Is it planned to be implemented? I didn’t want to include submodule content in my repo as it would clutter things and also will be hard to update the submodule after. I wanted to have clear line between my repo and the submodule repo. » Spacelift answer Given you want to keep a clean separation, the best workaround at this point would be publishing terraform-aws-apigateway-v2 as its own module in the Spacelift registry and referencing it as a separate source instead of a git submodule. » My answer Yes but this is rather workaround, because then I need to update my fork, publish new spacelift module version and then update my terraform-apigw-v2 module and second time publish another version. With submodules I update with git submodule -q foreach git pull -q origin master and publish version terraform-apigw-v2. So it is one step less. I also try to avoid nested dependencies on our modules as it already proved to be time consuming and bad practice. Dependency on external module didn’t cause us trouble yet.

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.

It would be useful if we could see the last pulled date/time for a module - we want to keep on top of stale modules, and some data around their user would be handy.

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.

Each published template version is pinned to a specific VCS commit from: https://docs.spacelift.io/concepts/template We would like to request that you can toggle between PINNED and UPINNED VCS commits on Templates. Our use case for templates is different than intended. We would like the template feature to help create mulitple identical stacks but with the same characteristics as manually created stacks.

As a administrator I would like to grant users the ability to toggle on/off Protect from deletion on a stack without having to grant SPACE_ADMIN privileges

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.