It would be helpful if it were possible to apply custom subject templates at the space level, or as contexts. That way calls coming from some spaces/stacks have different subject templates that other spaces/stacks. This would give us the flexibility to adjust the template based on customer needs instead of purely at the instance level.

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.

On large native Terragrunt stacks, the post-plan per-unit processing contributes to a large amount of the time the planning stage takes. The request is to increase the concurrency of the post-plan per-unit step.

Currently, notification policies evaluate per-run event, so each policy execution can only see a single run. This means: Multiple PR comments (one per run) clutter the PR timeline Reviewers must click into each run individually to see what changed Teams resort to building external aggregators (webhooks → custom service → GitHub API) to work around this Add the ability for native support for aggregating all proposed runs triggered by the same commit/PR into a single GitHub PR comment

Currently, there's no way to restrict Infra Assistant to only an admin-approved AI Integration. Even after configuring one, Spacelift's default/managed integration remains available alongside it, and any user can freely switch between the two at any time, per conversation, via the model selector in Infra Assistant chat.

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

Currently the retry button retries with the same environment as the initial run (hooks, provider version, environment variables ect) This can be confusing when a user removes a hook to fix the issue and then retries the run to just get the same issue. Similar to being able to click on the trigger drop down to trigger with force apply it would be good to be able to click on a retry drop down to retry normally or retry with current config.

Right now when I click into policies I can see created at and last updated at. However a “last evaluated at” field would be helpful to understand what policies are inactive and can be cleaned up / to see what policies would have recent samples for troubleshooting.

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.

Accelerate infrastructure development with CloudFormation pre-deployment validation and simplified troubleshooting | AWS DevOps & Developer Productivity Blog The above feature appears to be in use, as CloudFormation runs detected failures from the changeset worfklow: The following hook(s)/validation failed: [AWS::EarlyValidation::PropertyValidation]. To troubleshoot Early Validation errors, use the DescribeEvents API for detailed failure information. However, it would be more useful if Deployment Validation failures were displayed along with this using the DescribeEvents API as mentioned, so then the developers did not have to try to track these down in the AWS console.

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

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

Current Proposed Note the presence of a 1-click option to clear the search box, while still maintaining the existing functionality. Exceptions This doesn't have to be everywhere. Only persistent search boxes. For example, in the global search Ctrl+K the search box that comes up does not keep its value between invocations. It would not need a clear button; it would be bad if it was changed to remember its state.

Add a stable URL form for a saved Stack View that references the view by its identity (view ID or slug) rather than encoding the expanded filter/search/sort state in the query string. Loading the permalink should resolve to the view's current definition, so the link stays correct after the view's filters are edited. Example of the desired behaviour:.../stacks?view= (or a slug equivalent) loads whatever that view is currently defined as — instead of today's.../stacks?filterKeys=...&filterTypes=... which snapshots the filter state at copy time.

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.

In addition to run.command, have another input value that is a list of the “subcommands”. Specifically if the command is something like “command1; commad2 -option” or “command1 && command2 -option”, then you would get [“command1”, “command2 -option”]. This would make it a lot simpler to ensure the commands are in an allowlist, while still allowing multiple commands to be run at once. Or alternatively, have a way to create a pipeline of multiple tasks to run in the same container, to avoid having to pay the cost of warming up a container for each command when you need to perform multilple tasks.

Sometimes when you are in stack you can see that the status has changed. You need to click the ‘Tracked runs’ tab before you can do anything about that. Please make the badge clickable.

Right now, if a stack produces a notification on your PR via the notification policy, it creates a brand new comment under the PR. When multiple stacks produce a notification for the same PR, it will post multiple comments. It would be nice to batch them in a single comment.

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.