Spacelift Deploy Roadmap

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.

Support dynamic VCS repository input in Templates

Templates currently resolve the VCS repository field at publish time, meaning the repository is baked into the template version and can't be provided as a dynamic input. This prevents using Templates for use cases where the same stack configuration needs to be deployed across multiple repositories - e.g. a "Stack Vendor" template that engineers deploy from to onboard their repo.

Better support for adhoc ansible runs

As an infrastructure owner, I would like to be able to execute arbitrary ansible playbooks using an existing ansible stack. Spacelift currently locks each stack to a single playbook, which makes it difficult to make use of ansible’s full capabilities for managing the operating systems and applications on our EC2 infrastructure.

Nested Maps Support in Blueprints (for regional variations in user tiers)

As a stack author, I want to define map-of-maps in Blueprint inputs so that I can model region → user tier → settings without duplicating large structures. Why this matters: Today the map type is effectively flat. Real-world setups vary by region and tier. Without nesting, we copy-paste blocks and drift creeps in.

Add force apply / custom runtime config options to multi-select trigger action

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.

Terraform and Argo CD Deployment Orchestration

We would like a way to deploy infrastructure and application changes together in a single flow. Today, infra changes go through Spacelift (Terraform) while app changes are handled separately via Argo CD, which forces developers to update multiple repos and tools for one release. We’re looking for orchestration or integration with Argo CD so Terraform runs and app deployments can be coordinated, without replacing their existing GitOps setup.

Allow multiple custom subject templates

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.

Templates within Templates

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

Deploying Templates To Multiple Spaces

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

Ansible Dynamic Inventory

Spacelift should be able to do a dynamic inventory so a manual inventory file doesn’t need to be created. Managing an inventory file should be an afterthought for a solution like Spacelift.

Stack level access policy

We would like to be able to restrict read/write access to stacks using policy in the same space based on their labels.

Support for configuring a Spacelift Stack to "track" a git tag rather than a branch

We have a use case where we want to deploy some infra into multiple environments from a repository that uses git tags to semantically version the infra. By configuring a Stack to point at a git tag rather than a branch we could align the way we use Spacelift to manage this use case with our existing DevOps process. Our use case is a little bit different than Spacelift’s typical use case where a branch is tracked for infra changes. In our case, we’re not planning changes to this infrastructure. We just want to be able to create multiple stacks that deploy this infra into different environments. If (when) we need to make changes to this infrastructure, we will approach this by reconfiguring Stacks to point at a newer git tag.

Workers hard limit on account level or space level

Is it possible optionally to turn on workers limit on account or space level? Purpose of request is to avoid accidentally having too many workers running.

Differentiate tracked runs that were triggered from a pull request

Right now, when you promote a run from a PR, you just see the commit message in the tracked runs tab. That’s usually a non-descriptive message like “typo“, ”fixes”, etc. since the PR will be squashed on merge anyway and you only care about the PR title, not the individual commit messages. However, from the stack view, you have to go to the commit sha if you want to find which PR it belongs to. It would be way better that every tracked run that comes from a PR shows the title of the PR somehow. I would suggest something like this:

Allow direct access through terraform_remote_state data blocks to other stack's TF states regardless of the space in which they are located

Right now spaces + access control features are also extended to the TF states, so that one source stack can read the TF state from another target stack, the source stack must be administrative, the target stack must have external state access enabled, and additionally, and this is the main issue/blocker for us, the target stack has to be located in the same or a child space, as indicated here (point 3): https://support.spacelift.io/articles/9582913392-resolving-cannot-create-a-workspace-error-when-accessing-external-state This is preventing us from being able to adopt the new spaces approach because of the following reasons: Spaces are mainly intended for access control and to group/constrict which resources can be used/attached to other resources (e.g. AWS integrations, policies, etc), and for all these cases, the inheritance works in the way that each child space inherits the permissions/resources/... from the parent spaces. For example, a group that has write access in a parent space is also inheriting write access in the child space, and in the same way, an AWS integration attached to a parent space can be attached to a stack that belongs to a child space. So far so good. However, for the case of reading remote states from other stacks, this is working just in the opposite way, since based on the link shared above, an stack can only access the remote state of another stack that is in the same space or in a child space, and we have verified that this is indeed working as indicated, which basically makes useless the inheritance concept in many use cases, since it is common that stacks in child spaces (with higher permissions granted to the teams) need te read remote states from parent stacks (managing base/centralized resources), which are usually more sensitive and therefore have more restricted access. This can not be achieved in this case, since the child stacks (with wider access) has to be located in parent spaces so that they can get remote state access to the parent (more sensitive) stacks. Administrative stacks (meaning stacks that are managing other Spacelift resources) need to be placed in the parent spaces so that they are able to manage resources in Spacelift belonging to lower spaces, and this is completely ok. The pain point is that reading remote states from other stacks, which has nothing to do with managing Spacelift resources, is using the same approach. Organization and relations in Spacelift context don’t have to be necessarily related with the existing relations across the resources managed by all the existing stacks in Spacelift spread across the spaces structure, since in many cases such as product companies, those resources managed across the stacks/spaces can perfectly belong to a single platform or stack.

Negation Search

Is there a way to exclude items in a Stack List View? For instance, I'd like to see all stacks that do NOT include a certain folder label, so I hoped searching -folder:label-1 or something similar to show me every stack without that label. It seems the Sidebar Filter only applies include filters, not exclude filters.

Support more than 10 checks in the GitHub aggregate check

Currently the aggregate check GitHub integration is limited to 10 checks. For PRs with more than 10 runs, it is difficult to get to a spot where you can see all the runs for that specific PR. It would be great if the aggregate check could support more than 10 checks.

Stack list to link directly to unconfirmed run details

At the moment Stacks list links only to the stack. But it would save a couple of unnecessary clicks if either the Status tag or the Delta info could link to the run causing the status/delta. As of now, to validate the Delta (view the unconfirmed run) you need to click the Stack open (with CTRL/CMD hold down, as there’re no links opening it to a new tab/window!), then navigate to the that run, and only then (after two click) you are able to see the changes. If there would be direct link, it would be only one click; much more easier!

Add a --no-open option to `spacectl profile login`

In environments like WSL2, spacectl can try to opne a browser for autheenticaiton, when that is less than desirable. Adding some sort of no open option to just give the URL to click on would be great, and avoid trying to start udesired browers in the VM. I imagine there are other situations too where trying to start a browser would be undesirable here, but I dont see a current option in the help text to stop it happening.

Discard out-of-order push events from github

Github can sometimes send out of order push events from a repository, discarding these events through some sort of detection on spacelifts end or giving folks the ability to detect this in some capacity through a push policy to prevent duplicate runs is important.

Improved Visibility into Worker Billing (P95 Model)

We’d like to request improvements to the billing visibility, specifically around how worker usage is calculated and billed under the P95 model. Background: Currently, the P95 billing model is a bit tricky to fully grasp from the UI, especially when trying to estimate how much we'll be billed or whether we’re within our buffer. We asked a few questions and got helpful answers: Example: If we occasionally exceed the limit (e.g., 6 workers for a short period), the P95 might still be within our contracted limit (e.g., 5 workers), meaning no extra charges. However, if we go far over (e.g., 30 workers for the same short time), this could push the P95 up and cause overages. So while both duration and degree of overage matter, it’s currently hard to know what our actual risk or buffer is. Feature Request: We’d love to see better visibility in the UI and/or via metrics endpoints around this billing model, specifically: Current P95 usage: Where we stand right now for the billing cycle. Projected billing impact: A clear estimate of our current or projected overages, if any. Buffer insights: An answer to the question: “How much buffer do we have left this month?” Simulation tool: Something that helps us simulate the impact of increasing worker count temporarily (e.g., during migrations between pools) so we can make informed decisions. Why it matters: This will help us: Plan operations like migrations without unintentional overages. Understand when it's safe to scale up temporarily. Avoid surprises in billing. Thanks for your consideration!

Richer native Prometheus metrics: full exporter coverage, run timing, worker/queue metrics

It would be really nice to get metrics on # runs, run success, # stacks, etc. via Prometheus so we can create custom internal dashboards with this info. It’s helpful for measuring adoption, but we don’t use Datadog so we can’t get the info from there.

Add better support for Terraform/Tofu destroy

We are having issues with the way Terraform/Tofu destroy lifecycle is handled. Currently there are two ways to run a destroy for one of these stacks: Run a task where you manually type in “terraform destroy -auto-approve” Delete the stack and select the option to destroy resources managed by the stack Both of these methods have some obvious downsides: Tasks are not intuitive for operational users of Spacelift that don’t commonly destroy stacks. Destroy lifecycle hooks are not executed as part of tasks so the destroy process may fail or be incomplete when run with a task. Deleting the stack doesn’t support all use cases. In some cases we want to destroy the resources managed by a stack but not the stack itself. We use the stack to create resources again using the same configuration later. Most importantly: both methods to not provide a way for us to review the destroy plan and choose to confirm or reject the destroy. There are many reasons a destroy plan may not be acceptable and the underlying project may need unexpected changes before proceeding. Spacelift already has a nice UX for other parts of the TF lifecycle. We would like to option to trigger a destroy, where the destroy lifecycle is executed with hooks and all, and where we get the opportunity to review the destroy plan and confirm or reject it.

Only space_admin can create stack depencies.

You are unable to create stack dependencies without space admin

Include Environment Variable and Context changes in the Stack Runs List

It’s common for people to edit env vars/contexts etc and then do a manual trigger of a stack to apply the new variables, however to people looking at the stack runs list it’s difficult to see historically what has changed and why someone did a manual trigger. Right now the runs list only groups runs by the commit that they’re related to, however it is very difficult to see other things that may be impacting the run. I believe that it would be very beneficial to be able to see when changes are made to the following in the run view: - Environment variable changes - Context changes (hooks, env vars, mounted files) - Cloud integration changes

Trigger stack runs when contexts change

We are making extensive use of contexts to both share configuration between stacks and also split configuration from code more cleanly. A problem we have though is when configuration of a context changes this will not trigger a run of stacks it is attached to. Ideally contexts should behave like dependencies do with the ability to trigger (either implicitly or via a trigger policy) when a change to them occurs.

User based API keys

There’s currently no way to make user based API key. It’s only possible to create them on an organization level and it requires us to micro-manage API keys and their permissions in order to distribute them to teams (e.g. for usage with spacectl & terraform login for the registry). It would be good to allow users to create their own API keys which are immediately bound to the permissions they have (and change with permission changes of the user they’d get later).

Add stack and space data to drift section of GraphQL API

Hi, our team has created a PR (running locally in our LGTM stacks) of the promex service that adds space and stack labels for metrics that have that data available. We would like to see additional data for stack and space added to drift data in the GraphQL API so that we have this available for our dashboards etc.

AWS RDS IAM Auth

Spacelift self-hosted deployment uses a static RDS master password. Best practices and compliance requirements call for DB credentials to be regularly rotated, which AWS supports out of the box for Aurora clusters: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html Even better, AWS RDS/Aurora supports IAM database authentication, which uses short-lived (15-minute) authentication tokens instead of a stored password, and can be used together with master password rotation: Master password rotated regularly via AWS Secrets Manager, and used only for administrative/break-glass access Spacelift connects to the database for normal operation via a dedicated database user authenticated with IAM auth tokens, so no static password is used on the application's connection path Note: the module already sets iam_database_authentication_enabled = true on the aws_rds_cluster resource, so the AWS-side prerequisite for IAM auth is already in place. Can Spacelift backend be configured to generate/use IAM auth tokens for their connections rather than a password?

Add support for colourblind themes

This is a request for themes to be added to the UI that cater to common forms of colourblindness. I’ve marked this as important rather than nice to have as difficulties distinguishing important changes to our infrastructure can potentially lead to costly mistakes

Add Pull Request link

Within a stack page, when opening a run related to a PR, so from the PRs tab, there is no link to the PR, only one to the commit.

Allow configuring log retention period

For compliance purposes, we need to retain Run logs for longer than the default 60 days. Currently, there is no easy way to achieve this while keeping the logs easily visible in Spacelift. Allowing the retention period to be configured (could be a paid feature), or allowing logs to be pulled from customer-hosted storage would be nice.

Autoattach cloud integrations

Allow viewing long full plan logs directly from web UI

When the full plan logs are too long, you have to download the logs, then view them through a terminal if the logs have ANSI color codes in them. This is all around a confusing experience, between having to leave Spacelift, then figure out how to view the logs. A searchable log viewer that can handle really long log outputs would be nice. We have legacy Terraform stacks that we don’t want to shard before moving them to Spacelift, and sometimes you just end up with a really long plan, no matter how small your stack is.

support rego.v1

Support rego.v1 for policies

Allow space admins to create sub-spaces

Allow the admins of a non-root space, create spaces under that space. This allows us to delegate responsibilities to teams.

SCIM Provisioning / Full IdP Integration

We’d love to see full SCIM 2.0 support in Spacelift so that user provisioning and deprovisioning is handled automatically via our IdP (Okta, Azure AD, etc.). Right now we have to manually add/remove users in Spacelift, which slows us down and introduces risk of leaving stale accounts around. Ideally, if someone is added to an IdP group, they’d show up in Spacelift with the right role, and when they’re removed, access should be revoked automatically. This would really help us improve security, reduce admin overhead, and align with how we manage access in the rest of our SaaS tools.

Ability to download state from stack

Allowing to download a stacks state-file locally. Useful for analyzing state-file content, as well as making modifications for later importing. This is useful when a stack might be stuck in a state it can’t refresh, due to bugs in providers or similar.

"Download logs" button should automatically strip color codes

While it is nice to be able to have colors in the output from Spacelift in the UI (and I wish to keep it), when downloading logs for further review (and/or when the logs are too long), the color codes are extremely noisy. It would be nice to have a preprocessing pass that strips everything before the download. It is slightly related to 2 other FR but: - “Disable color injected by Spacelift logger” is more about respecting a “—no-color” flag when passed in a tool, - “Allow viewing long full plan logs directly from web UI” is more about being able to see all logs in the web UI, and not having to download them (it’s marked as complete, but it doesn’t seem to be the case from my experience?)

Improve Terraform Diff View

Could you make it easier to understand the plan and apply diff for terraform? One way to do it is something like https://github.com/aws-ia/terraform-aws-runtask-tf-plan-analyzer where you push it through an LLM, but also some UI improvements to make it more like terraform cloud's plan diff would work as well. Example use cases: See the plan diff while an Apply is running Show just the individual fields that are changing make it easier to grok what is happening when there are lots of changes handle complex resource diffs Without this, our engineers find your current plan diff completely unusable, and so they are just blindly applying.