Feature Requests

Got an idea for a feature request? Let us know! Share your ideas on improving existing features or suggest something new. Vote on ideas you find useful!

Make sure to read our guidelines before posting πŸ“–

πŸ”­ 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

1

πŸ”­ 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

2

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

1

πŸ”­ 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

2

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