π Discovery
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.
π‘ Feature Requests
7 days ago
π Discovery
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.
π‘ Feature Requests
7 days ago
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.
π‘ Feature Requests
1 day ago
Resources
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.
π‘ Feature Requests
1 day ago
Resources
π Discovery
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.
π‘ Feature Requests
19 days ago
π Discovery
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.
π‘ Feature Requests
19 days ago
β¬οΈ Gathering votes
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.
π‘ Feature Requests
15 days ago
Blueprints
β¬οΈ Gathering votes
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.
π‘ Feature Requests
15 days ago
Blueprints
π Discovery
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
π‘ Feature Requests
About 19 hours ago
π Discovery
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
π‘ Feature Requests
About 19 hours ago
π Discovery
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.
π‘ Feature Requests
2 days ago
Contexts
π Discovery
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.
π‘ Feature Requests
2 days ago
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.
π‘ Feature Requests
15 days ago
Policies
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.
π‘ Feature Requests
15 days ago
Policies
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.
π‘ Feature Requests
10 days ago
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.
π‘ Feature Requests
10 days ago
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!
π‘ Feature Requests
15 days ago
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!
π‘ Feature Requests
15 days ago
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.
π‘ Feature Requests
About 7 hours ago
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.
π‘ Feature Requests
About 7 hours ago
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.
π‘ Feature Requests
15 days ago
Stacks
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.
π‘ Feature Requests
15 days ago
Stacks
β¬οΈ Gathering votes
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.
π‘ Feature Requests
1 day ago
Blueprints
β¬οΈ Gathering votes
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.
π‘ Feature Requests
1 day ago
Blueprints
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β
π‘ Feature Requests
1 day ago
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β
π‘ Feature Requests
1 day ago
π Discovery
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.
π‘ Feature Requests
3 days ago
π Discovery
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.
π‘ Feature Requests
3 days ago
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}).
π‘ Feature Requests
4 days ago
Contexts
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}).
π‘ Feature Requests
4 days ago
Contexts
Microsoft Teams Webhook
If possible, allow stack policies/manual reviews to be approved from Microsoft Teams webhooks. Microsoft Teams - Spacelift Documentation
π‘ Feature Requests
19 days ago
Microsoft Teams Webhook
If possible, allow stack policies/manual reviews to be approved from Microsoft Teams webhooks. Microsoft Teams - Spacelift Documentation
π‘ Feature Requests
19 days ago
π Discovery
Provide a skip button for Spacelift external dependency in UI
Provide a skip button for Spacelift external dependency in UI
π‘ Feature Requests
9 days ago
π Discovery
Provide a skip button for Spacelift external dependency in UI
Provide a skip button for Spacelift external dependency in UI
π‘ Feature Requests
9 days ago
π Discovery
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.
π‘ Feature Requests
10 days ago
π Discovery
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.
π‘ Feature Requests
10 days ago
π Discovery
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.
π‘ Feature Requests
11 days ago
Policies
π Discovery
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.
π‘ Feature Requests
11 days ago
Policies