This is the roadmap for a Spacelift deploy.

Discovery

Planned

In Progress

Released

Spacelift Deploy Roadmap

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

➡️ Planned

Access Control

Stack level access policy

hidden

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.

Stacks

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

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.

Workers

Workers hard limit on account level or space level

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:<img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/0192005e-b00d-73d2-9e4f-066d32e139ff.png" data-width="100%" data-align="left">

UI/UX

IaC Workflows

Differentiate tracked runs that were triggered from a pull request

Currently, AWS’s terraform-aws-control_tower_account_factory module is configured to use Terraform Cloud/Enterprise (TFC/TFE) or the open-source Terraform Community Edition as the backend for the workspaces required to provision resources. This module simplifies Control Tower account provisioning by providing a large amount of infrastructure out of the box, which makes the process much easier.With a few relatively minor adjustments, the module could instead be adapted to use Spacelift stacks as the backend for managing those workspaces.

Integrate spacelift into AWS control tower account factory module

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):<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://support.spacelift.io/articles/9582913392-resolving-cannot-create-a-workspace-error-when-accessing-external-state">https://support.spacelift.io/articles/9582913392-resolving-cannot-create-a-workspace-error-when-accessing-external-state</a>This is preventing us from being able to adopt the new spaces approach because of the following reasons:<ul><li>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.</li><li>However, for the case of reading remote states from other stacks, this is working just in the opposite way, since based on <a target="_blank" rel="noopener noreferrer" class="c-link link" href="https://support.spacelift.io/articles/9582913392-resolving-cannot-create-a-workspace-error-when-accessing-external-state">the link</a> 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.</li><li>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.</li></ul>

Spaces

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

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 <code>-folder:label-1</code> or something similar to show me every stack without that label. It seems the Sidebar Filter only applies include filters, not exclude filters.

Filters

Negation Search

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.

Integrations

Support more than 10 checks in the GitHub aggregate check

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!

Stack list to link directly to unconfirmed run details

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.

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

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:<ul><li>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.</li><li>However, if we go far over (e.g., 30 workers for the same short time), this could push the P95 up and cause overages.</li></ul>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:<ul><li>Current P95 usage: Where we stand right now for the billing cycle.</li><li>Projected billing impact: A clear estimate of our current or projected overages, if any.</li><li>Buffer insights: An answer to the question: “How much buffer do we have left this month?”</li><li>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.</li></ul>Why it matters: This will help us:<ul><li>Plan operations like migrations without unintentional overages.</li><li>Understand when it's safe to scale up temporarily.</li><li>Avoid surprises in billing.</li></ul>Thanks for your consideration!

⚙️ In Progress

Dashboard

Observability

Improved Visibility into Worker Billing (P95 Model)

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.

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

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:<ol><li>Run a task where you manually type in “terraform destroy -auto-approve”</li><li>Delete the stack and select the option to destroy resources managed by the stack</li></ol>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.

Add better support for Terraform/Tofu destroy

The client is requesting an additional claim —<code>spaceAncestry</code>— that represents the full hierarchy of the space structure.Example: For a hierarchy structured as:<pre><code>root &gt; parent &gt; child </code></pre>A stack in the <code>child</code> space currently receives an OIDC token containing:<pre><code>spaceId = child </code></pre>The proposed enhancement would include an additional claim such as:<pre><code>spaceAncestry = root;parent;child</code></pre>This would enable orgs to make more dynamic and hierarchical authorization decisions, particularly in integrations with identity systems like Google Cloud Workload Identity Federation (WIF). For example, when provisioning GCP service accounts and corresponding Spacelift contexts automatically, policies could be written to recognize all descendant spaces within a hierarchy — ensuring permission inheritance without manual updates whenever new child spaces are added.

OIDC

Include full space ancestry in OIDC token claims

You are unable to create stack dependencies without space admin

Stack Dependencies

Only space_admin can create stack depencies.

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

Include Environment Variable and Context changes in the Stack Runs List

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.

Contexts

Trigger stack runs when contexts change

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 &amp; 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).

User based API keys

Spacelift currently seems to only allow me to be logged in one place at a time, this is very annoying and our developers are having to re-login web / cli many times throughout the day. ideally this should be able to function much like the current login, make folks log in once a day to refresh the session, but otherwise allow using the web and a CLI token at the same time.

Spacectl

Terraform registry

Allow "CLI" logins to co-exist with Web logins

Hi, our team has <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/spacelift-io/prometheus-exporter/pull/43">created a PR </a>(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.

Drift Detection

Add stack and space data to drift section of GraphQL API

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.

✅ Completed

Add Pull Request link

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.

Logs

Allow configuring log retention period

Autoattach cloud integrations

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.

Allow viewing long full plan logs directly from web UI

Policies

support rego.v1

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

Allow space admins to create sub-spaces

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.

SCIM Provisioning / Full IdP Integration

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.

Ability to download state from stack

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?)

"Download logs" button should automatically strip color codes

Could you make it easier to understand the plan and apply diff for terraform? One way to do it is something like <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/aws-ia/terraform-aws-runtask-tf-plan-analyzer">https://github.com/aws-ia/terraform-aws-runtask-tf-plan-analyzer</a> 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:<ul><li>See the plan diff while an Apply is running</li><li>Show just the individual fields that are changing</li><li>make it easier to grok what is happening when there are lots of changes</li><li>handle complex resource diffs </li></ul>Without this, our engineers find your current plan diff completely unusable, and so they are just blindly applying.

Improve Terraform Diff View

What would be helpful is to have: Stack-level permissions (e.g. grant preview/apply without needing space admin), Custom roles like: <code>Context editor Policy-only maintainer Read-only + preview, </code>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.

🔭 Discovery

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

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.

Support dynamic VCS repository input in Templates

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.

Better support for adhoc ansible runs

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.

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

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.<img src="https://6697afd8db026456df4b91e0.featurebase-attachments.com/c/post/6a6a110b680d4cd37678aec2/019fae52-66fa-7064-9986-aaa4ee3da066/b64u-MDE5ZmFlNTItNjZlZS03MDJkLWEyMGEtMTVmZmVjZWQ2OTE2.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260922T150000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260922%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=3e65faa6a1a8ad7ea5eef6d89be194806a02ee19261d6761ee35d9479bc54b29" data-width="100%" data-align="left" alt="image.png" data-featurebase-content-key="6697afd8db026456df4b91e0/post/6a6a110b680d4cd37678aec2/019fae52-66fa-7064-9986-aaa4ee3da066/b64u-MDE5ZmFlNTItNjZlZS03MDJkLWEyMGEtMTVmZmVjZWQ2OTE2.png" data-featurebase-content-filename="019fae52-66ee-702d-a20a-15ffeced6916"><img src="https://6697afd8db026456df4b91e0.featurebase-attachments.com/c/post/6a6a110b680d4cd37678aec2/019fae52-8a45-7910-bd13-47530dd7ce23/b64u-MDE5ZmFlNTItOGEzYy03NDEzLWIxNjItOTIyOGY0ODQ2MTQz.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260922T150000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260922%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=753413f2277f0c91827aa01dbe3b0638094abb283a2dee51ed4dda7576ab2013" data-width="100%" data-align="left" alt="image.png" data-featurebase-content-key="6697afd8db026456df4b91e0/post/6a6a110b680d4cd37678aec2/019fae52-8a45-7910-bd13-47530dd7ce23/b64u-MDE5ZmFlNTItOGEzYy03NDEzLWIxNjItOTIyOGY0ODQ2MTQz.png" data-featurebase-content-filename="019fae52-8a3c-7413-b162-9228f4846143">

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

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.

Terraform and Argo CD Deployment Orchestration

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.

Allow multiple custom subject 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 <code>stacks</code> array, each stack requires a unique <code>key</code>, and stack dependencies are handled through fields such as <code>depends_on</code> and <code>stack_dependency_references</code>.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:<pre><code>create_network
 stacks:
 - key: network
 - key: firewall_rules

create_vm
 stacks:
 - key: vm

add_dns_record
 stacks:
 - key: dns_record</code></pre> 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:<pre><code>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"</code></pre> The exact YAML schema could differ, but the important point is that a parent template should be able to contain both:<ol><li>references to other templates</li><li>local stack definitions</li></ol>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:<pre><code>network_id: ${{ templates.network.network.vpc_id }}</code></pre>would refer to the <code>vpc_id</code> output from the <code>network</code> stack inside the referenced <code>network</code> template.<pre><code>bootstrap_id: ${{ stacks.bootstrap.bootstrap_id }}</code></pre>or an equivalent syntax would refer to the <code>bootstrap_id</code> 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:<pre><code>depends_on:
 - templates.vm.vm
 - bootstrap</code></pre>In this example, <code>templates.vm.vm</code> means the <code>vm</code> stack inside the referenced <code>vm</code> template, while <code>bootstrap</code> means a local stack in the parent template.This distinction matters because reusable templates will often contain more than one stack. A parent template may not always depend on the whole child template as a single unit. It may need to pass an output from, or depend on, one specific stack created by that referenced template.This would allow organisations to build a proper catalogue of reusable templates, including both simple stack-only templates and larger templates composed from other templates and local stacks.For example:<pre><code>create_network
 - reusable template owned by the networking team
 - contains one or more network-related stacks

create_vm
 - reusable template owned by the virtualization team
 - contains one or more VM-related stacks

deploy_gitlab
 - higher-level self-service template
 - references create_network
 - references create_vm
 - defines its own local bootstrap or configuration stacks
 - maps inputs and stack outputs between all of them</code></pre>

Templates within Templates

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

Deploying Templates To Multiple Spaces

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.

Ansible Dynamic Inventory

Help Center

Security

Improvement

Announcement

spacelift

👀 In Review

⌛ Waiting for User

⬆️ Gathering votes

❌ Rejected

🗑️ Archived

Ansible

Blueprints

CloudFormation

Resources

Pulumi

Kubernetes

Terragrunt

Spacelift Provider

Notifications

OpenTofu

Helm

Self-hosted

Search

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 <a target="" rel="noopener noreferrer nofollow" class="link" href="https://docs.spacelift.io/product/feature-requests">guidelines</a> before posting 📖