Aggregate & summarize Terraform plans across related stacks

We manage approximately 60 Terraform stacks that are essentially duplicates with minor variations. When we make changes, we need to manually view and approve each plan, which becomes extremely time-consuming and inefficient. What would be incredibly helpful is a way to aggregate and summarize plan changes across a group of related stacks. Ideally, this feature would: Group stacks by metadata, tags, or structural similarity Show a consolidated diff of plan changes across those stacks Highlight patterns or inconsistencies in the change sets Let us approve or reject runs in bulk when the diffs are identical or low-risk The current stack summary page only shows individual deltas, which doesn't scale well when managing many stacks that follow the same structure. A higher-level view would drastically improve operational efficiency and reduce the burden on engineers.

Account Level Drift Detection

For detecting changes made outside of Spacelift (e.g., via the console, like assigning a target group to a load balancer), im asking for an integration built in via Terraformer. This can complement Spacelift by allowing reconciliation between the actual infrastructure and Terraform state despite those external changes. A visual representation of the one to one maps and therefore the dependent modules would be an amazingly useful suite of tools and add more value to spacelift usage.

Granular Access Controls: Stack-Level Permissions, Scoped Roles, and IdP Delegation

What would be helpful is to have: Stack-level permissions (e.g. grant preview/apply without needing space admin), Custom roles like: Context editor Policy-only maintainer Read-only + preview, Delegation via IdP-managed groups, Decoupling access from Spaces (Currently forced to move stacks or grant admin to transfer ownership) Avoiding PIM escalations just to test policies or edit contextWe're running into limitations with Spacelift’s current permission model, especially the lack of granularity beyond space-level admin. Right now it’s either full admin or very limited user, nothing in between. We want to avoid moving stacks just to change ownership.Changing ownership of a stack often requires migrating state or temporary admin elevation, which introduces risk and friction. Customers with compliance requirements (e.g. HIPAA, SOC 2) need least-privilege enforcement and auditability.

Ability to propagate changes from Blueprints + support dynamic templating per stack

We're managing a multi-tenant infrastructure with 40+ stacks generated from Blueprints. While blueprints are a great starting point, the current model becomes difficult to scale as we grow. Once a stack is created, it's disconnected from the Blueprint — so if we need to update something across all stacks (like add a config flag or a new file), we have to do it manually or build internal tooling to handle it. This is both time-consuming and error-prone. What would be helpful: Blueprint-linking after creation The ability to apply changes from the Blueprint to existing stacks when needed is like syncing changes downstream. Templating system for dynamic config We'd love to be able to define shared files (like a config file) in the Blueprint and inject stack-specific values dynamically, maybe via a map (e.g. stack ID → values). This would help us keep stack behaviour consistent while still supporting tenant-specific differences. Why this matters: We're growing quickly, and the manual effort to maintain stack configurations is already a burden. The more tenants we onboard, the harder it becomes to keep everything in sync, which slows us down and increases the risk of errors. Having more tooling here would make Spacelift even more powerful for teams like ours who are scaling infrastructure as a platform.

Add a third priority level lower than the default one

Most of the times with our changes we trigger ~5-10 stacks and with rather fast feedback. But somewhat regularly we execute upgrades/migrations that trigger hundreds of stacks, for those we don’t expect fast feedback we are happy with those taking a while as we only have 5 workers. The issue arises when we have both simultaneously, and if the ones triggered early are part of the 100s migration/upgrade batch then the rest will take longer to get feedback. An approach is to prioritize the small batches. But it is not really efficient for us to prioritize every small batch that comes after a big batch. Instead we would like to mark the big batches as `deprioritized` so that the of the stacks to be picked up would be: - prioritized - regular/default - deprioritized

Allow selection and deletion of multiple Contexts SaaS + Selfhosted

User must currently delete context via UI one at a time. To help handle deletion of multiple contexts we could make the context view allow for multiple context selection and mass actions such as one to delete the selected contexts.

Ability to use check block warnings as part of a plan policy

We have used the check block resource in several of our terraform projects and it would be great if we could use these same warning blocks in our plan policies to control automatic approval.

Support Name-Based Lookup for Worker Pool ID in spacelift_worker_pool Data Source

Please add support for resolving a worker pool’s ID by name in the data "spacelift_worker_pool" data source, to enable assigning worker_pool_id to resources without introducing plan noise.

Support for AWS VPC Endpoint to Access Spacelift

We’d love to see Spacelift support AWS VPC endpoints for private connectivity. This would allow us to route traffic to Spacelift entirely within AWS infrastructure, without traversing the public internet, similar to how we currently handle connectivity with providers like CloudAMQP and MongoDB Atlas. Right now, our setup requires VPN-based access and IP whitelisting, which occasionally causes issues when IPs aren’t updated promptly or VPNs behave inconsistently. While this isn’t a blocker, it introduces operational overhead and inconsistent access behaviour that could be avoided with private networking. Thanks for considering this!

Deprioritize Run option

Jobs are launched at what I’ll call “standard” prioritization. Using the “Flag” icon in the Worker Pool Queue view I can increase the prioritization of runs. I’d like to specifically be able to de-prioritize runs in the case of large deploys so as not to adversely impact other teams.

Record Preparing Step Timings in UI

Currently the Preparing step where Spacelift is downloading the repo & initializing the docker container is only exposed while it is happening, those timings do not appear to then be recorded in the UI. We’d like to track these timings to understand how long we’re waiting on those steps.

Increase blueprint max stack dependencies

I have a workflow that deploys a virtual machine via terraform and runs ~10-15 separate ansible playbooks for post configuration management. I can only in one blueprint create a maximum of 5 stack dependencies (meaning one terraform stack and max 4 ansible playbook stacks.

Auto attach contexts to label folders

I have a stack with a label folder “folder:Cloud/Azure/Storage Accounts/Standard”. I would like the ability to auto attach to a contexts to all resources within “folder:Cloud/Azure”

Allow to check past/historic states

Would be very useful for debugging purposes to be able to check the state of previous applies for stacks. Since there’s a “State history” tab where all the checkpoints are saved as events, I guess the states are saved. However, the only allowed operation is to Rollback. This State history feature could be very useful if combined with the “IaC management“ tab, allowing to check the resources in different points of time. The motivation for this request was a bunch stacks failing because some resources changed, and we would like to investigate how was the state some time ago, to compare to current one.

Filter errored stack with error message content

Ability to "namespace" Context attachments to avoid variable name clashing

We’d like to request the ability to optionally specify a namespace prefix when attaching a Context to a Stack. The goal is to avoid variable collisions when multiple Contexts expose similarly named environment variables (e.g. TF_VAR_vpc_id) and need to be consumed simultaneously by a single Stack. Example Use Case: We have separate base infrastructure Contexts for environments like prod and staging, each exporting variables like TF_VAR_vpc_id. Most stacks only need one Context, but occasionally a stack needs to consume both environments. A namespace prefix would allow both to coexist without conflict: Attach prod Context with namespace prod → TF_VAR_prod_vpc_id Attach staging Context with namespace stage → TF_VAR_stage_vpc_id This avoids having to namespace all variables in the base Contexts upfront, which would complicate simpler use cases unnecessarily. Proposed Behaviour: Support an optional namespace string on Context attachments that is prepended to all exposed variable names (e.g. TF_VAR_{namespace}_{var}).

Microsoft Teams Webhook

If possible, allow stack policies/manual reviews to be approved from Microsoft Teams webhooks. Microsoft Teams - Spacelift Documentation

Provide a skip button for Spacelift external dependency in UI

Provide a skip button for Spacelift external dependency in UI

Canned Tasks

It’d be useful to have canned/templated tasks that users can reuse that are defined at the org level. Initial use would be to make it much easier for people to manually unlock their states.

User level Slack Integration

If it was possible to connect your slack account to you Spacelift account, then in a notification policy, you could potentially use that Slack user information for something like notifications to users directly on Slack when a stack requires approval.