Multi-select bulk actions bar only offers Trigger/Lock/Disable/Run task — it should also expose "Trigger with force apply" and "Trigger with custom runtime config" like the single-stack Trigger dropdown does, so you can bulk force-apply or set a custom runtime config across selected stacks instead of doing it one by one.

Currently the only way to read sensitive values from a stack is to running a task that runs tofu output . This works - but has a major flaw, it exposes the sensitive output value to anyone who has read only on the stack. We’d like a way to directly view sensitive outputs in the stack UI (and potentially via tools like spacectl) which is locked behind a more privileged permission than Read only. This could be stack write or (better) a specific, new permission for viewing sensitive outputs.

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.

Feature Request: enable moving state from S3 to Spacelift State Management w/o needing to re-create stacks Per docs, once a stack has been created with an S3 backend, it is not possible to move to Spacelift State Management. It is a setting that can only be created at Stack creation Why is this important? If a run does not complete and times out / stuck / killed, S3 state-file remains locked. Admin intervention is needed to unlock the workspace. When using S3 state management, it is not possible to lock a stack in the Spacelift self-hosted UI

We are currently tightening our security policies on certain actions in Spacelift. One of our focus is to reach the plan phase of a proposed run only after an approval of a codeowner. So far we succeeded testing adding a label on a stack that basically contains a list of GitHub teams based off of the actual CODEOWNERS, this way Spacelift on any action in the stack can access to the GitHub team that owns the stack and the code it tracks. Then we created an approval policy that waits for an approval from the codeowners. Once a PR is created and thus a proposed run is triggered and starts, then evaluates something in the lines of: requires_approval if { not creator_is_codeowner } ## Creator is a code owner if their GitHub teams overlap with codeowner_teams creator_is_codeowner if { some session_team in input.session.teams some codeowner_team_group in codeowner_teams session_team in codeowner_team_group } ## Auto-approve: creator is code owner approve if not requires_approval ## Approve: someone from the owning team reviewed in Spacelift approve if { count(input.reviews.current.rejections) == 0 requires_approval some review in input.reviews.current.approvals some session_team in review.session.teams some codeowner_team_group in codeowner_teams session_team in codeowner_team_group } TL;DR if the author of the PR is not a codeowner (i.e. doesn't belong to a github team the the stack is labeled with), then requires an approval of a codeowner. The parts that work: The approval policy is evaluated before the plan phase The approval policy lets the run continue and finish only after a codeowner approval The parts that we would like to have but are not supported by Spacelift (to the best of our knowledge) At the PR creation event and evaluation of the approval policy this block is in the approval policy: ... "commit": { "author": "AUTHOR_USERNAME", "branch": "BRANCH_NAME", "created_at": 1785152807000000000, "exist_on_tracked_branch": false, "hash": "HASH", "message": "Test codeowners approval", "tag": "", "url": "https://github.com/ORG/REPO/commit/COMMIT_HASH" }, ... "creator_session": { "admin": "", "creator_ip": "", "idp_subject": "", "login": "", "machine": true, "name": "", "teams": [] } ... No way of getting author teams

Users running a single large Terragrunt stack with Use Run All enabled have no way to scope a run to the units affected by a change. Every triggered run executes terragrunt run-all across the entire project root regardless of what changed [https://docs.spacelift.io/vendors/terragrunt/run-all], which on a large project means long, wasteful runs and a single monolithic run log with no per-unit history.

Currently my company is on the Starter plan which comes with two public workers. 90% of the time, that is more than enough for our day to day operations. However, it would be amazing and also something I would be completely onboard with paying a premium price on if we could dynamically scale up even a couple workers on occasion. The scenario where we may want something like that would be in the case where we are affecting a change across a module with many stacks, like ECS or Lambdas. The two worker limitation on Starter becomes a bottleneck. While I know Enterprise has the ability to auto scale, we just don’t need that big of a contract or that many workers on a regular cadence for it to make sense to sign onto that. But I would be more than willing to pay a per-min compute price for a few extra workers on demand or when our queue of jobs gets to a certain depth.

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

I’d like to be able to see within the context view if stacks are attached either by showing autoattched to x number of stacks or - with no stacks attached, for when removing a stack the context kicks and isn’t always tidy’d up.

When a stack has Autodeploy enabled and a run reaches UNCONFIRMED due solely to a pending policy approval (not a manual review requirement), approving that policy should auto-confirm the run and let it proceed to apply — no separate manual click. Reviewed documentation on enabling Autodeploy, which allows approved runs to proceed automatically, and using plan policies that return `warn` to require review only when necessary. Setup involves plan policies issuing warnings, approval policies requiring manual approval, and notifications via Slack, but the final confirmation step remains manual, which can be unintuitive. Exploring if this manual confirmation can be eliminated or automated.

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

We have 2 apps that send checks for separate self-hosted instances. (though this could happen if you have 2 github integrations for whatever reason. We would like the ability to configure the spacelift/ prefix in the checks. so that we can have spacelift-a/ and spacelift-b/ in our checks list.

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.

Stack update audit events are currently missing an important piece of context for audits in that they only include the state of the stack after the update. With the current info we can see that a user updated a stack, but not the specific change to the stack that the user made. My team would like to see the specific change made to the stack in the audit log event, for instance on setting a new branch for the code source, the before and after branch name. More broadly this seems applicable to any resource that can be changed in an update action.

Whenever I use the JSON diff view I unclick the option “Show side by side” so I can view it as a unified diff. I would love to either have the browser remember what I selected last (so I only have to click it once) or have a user-level setting where I can choose which view I prefer, instead of having to switch to unified diff every time.

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

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.

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.

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.