Helm chart: support templating annotations for CRDs (Argo CD ServerSideApply)

When deploying spacelift-workerpool-controller via Argo CD, applying the WorkerPool CRD (workerpool-crd.yaml) requires ServerSideApply=true (optionally Replace=true). Since CRDs are shipped under /crds and aren’t templated, it’s currently not possible to set argocd.argoproj.io/sync-options via values.yaml. Please add Kyverno-style support for configuring CRD annotations from values to allow fully automated GitOps sync.

in spacelift ui I want to be able to click on the icon showing the current run state (applying, ...) and it should take me to the current run view

Worker Pool Job Routing

When drift detection is enabled on a stack, you are forced to use your self-hosted worker pool.

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.

Kubernetes / Argo / Terraform providers

We’re very happy with Spacelift overall, it “just works” for us. Where we struggle is the Kubernetes side. The Terraform Kubernetes providers, especially the Helm provider, have caused state issues for us and generally do not work perfectly, so we have moved to using Argo for everything in the cluster and avoid having Terraform deploy Helm charts. Concretely, what would help us a lot: A quick, easy Helm chart we can deploy with Argo to run Spacelift components / private workers in our cluster. Better maintained Kubernetes and Helm provider story from your side. If you owned those and made them reliable, we would rather be using Spacelift than Argo and would happily pay for that.

Enable drift detection without admin permission

To enable drift detection it seems as of now it requires ADMIN permissions. With AAC could there be a role introduced for drift detection that would not require admin permissions to be set?

UI / UX Rain Feature: Year round Ambient Visual Effects (ex. our Holiday snow feature)

Requesting additional ambient visual effects (similar to the holiday snow animation) to be available beyond seasonal use, such as a soothing rain or nature-themed effect. The customer shared that the existing snow effect was unexpectedly calming during long-running deploys. Having a subtle, mesmerizing visual helped make waiting for several minutes feel more pleasant and less tedious. Proposed Idea Introduce optional, non-intrusive ambient UI effects (e.g., rain, nature themes) that could be enabled during long-running operations like deploys. These could be: Available year-round Optional / user-toggleable Designed to be subtle and non-distracting

Agent-based stack refactor and cleanup

We have hundreds of stacks. More than half of them are in an error state. Most of those correspond to development/test infrastructure, and staffing a team to do the cleanup would be expensive. Lots of those stacks are “someone manually upgraded the database, so we need to create a PR to reflect the new DB version” or “this resource got created manually, and now the apply is failing due to the duplicate resource creation attempt.” In addition to failing stacks, some stacks are simply in disrepair. Missing imports, missing move blocks, and other defects mean that maintaining stack state is difficult. Obviously teams using Terraform should be consistent at using Terraform, rather than performing manual operations, but sometimes that’s significantly more expensive/time-consuming than clicking a button in AWS for non-production systems. There’s also a very large category of refactor-type work that’s very expensive to do manually, where you want to restructure some modules or move resources across stacks. I’d like to propose that these tasks are exceptionally appropriate for LLM agent-based workflows. We already have the technology to restrict permissions for terraform plans to dramatically minimize the risk of malicious configuration being introduced at that phase. Spacelift already has sophisticated workflow approvals. Often, the thing I want is for something or someone to operate in a loop making configuration changes and manipulating the state until terraform plan produces a plan with no delta, e.g. “No changes. Your infrastructure matches the configuration.“ That’s an incredibly clear objective to give to an LLM! I’d be thrilled if Spacelift implemented tooling to help teams achieve better resource management.

Allow non-root to read spacelift_role data source

Related to: The Spacelift Terraform provider Request: Could stacks in child spaces be allowed to read and reference available roles via data source, for use with spacelift_role_attachment? Issue: The administrative flag is being deprecated in favor of role attachments. However, there is no way for non-root stacks to programmatically look up and reference available roles to use with the spacelift_role_attachment. Workaround: Can use the UI to look up the ID for existing roles and hard-code it into spacelift_role_attachment resource. Example steps: Create a new child space Create a new Terraform stack in the child space via the UI, and grant it the Space Admin role Use the Terraform stack to create another new stack, which should be assigned an existing role (e.g., the default Space Writer role, or a custom role) The programmatic approach would be to use a data source to reference the role, most likely using the known human-friendly slug ( e.g., space-writer ). However, stacks in a child space are currently not allowed to see that info, so the alternative is a manual step and use the UI to lookup the role ID and add it directly to the code. (Also: appreciate y’all, thank you!)

Drift detection notifications per stack owner or team label

Ability to route drift notifications based on stack level metadata. For example, each stack could have a label or owner field that maps to a Slack channel, alias or user list. When drift is detected, the system would send a notification directly to the right team instead of relying on a single global webhook. This is especially important where many teams own their own stacks.

Filter resources by attributes in the resources view

Ability to filter resources by their attributes, not only by IaC resource name. For example, I want to list all S3 buckets with a specific encryption configuration, or all resources with or without a given parameter. The data is already there in the inventory but today I need to click each resource, open the JSON on the right, and search manually. A filter on key and value would already solve most of this.

Reverse lookup: find stack by cloud resource

Ability to start from a cloud resource identifier or name and quickly find which stack manages it. Example: given an IAM role or S3 bucket name from an event or CloudTrail, I want to search in the resources view and see which stack is responsible for that resource. This makes it much easier to investigate manual changes, alerts and incidents that originate from the cloud side.

Support Terragrunt run-all with Spacelift Native State Management

Spacelift integrates with Terragrunt, but when using Terragrunt’s run-all functionality, Terraform state cannot be managed by Spacelift’s native state management. This limits the effectiveness of the integration for teams using Terragrunt to orchestrate multi-module and dependency-driven deployments.

Explorer-like inventory of providers/modules (and versions) across Stacks

It would be really helpful if Spacelift had an Explorer-like inventory view (similar to Terraform Cloud → https://developer.hashicorp.com/terraform/cloud-docs/workspaces/explorer ) showing providers/modules and their versions across all stacks. This would make it easier to : understand how far behind the stacks are see how spread out the module versions are across stacks Nice-to-have additions: - filters by stack/space/environment - charts showing version distribution - export to CSV - click-through to affected stacks

Option on spacelift_run resource to continue even if target stack is disabled

The spacelift_run resource has an optional wait block that allows it to continue if the run is in a defined run state, and to continue if it did not reach any defined end state. I would like to configure the resource to also continue if a run cannot be triggered because the target stack is disabled.

Display Raw Terraform Output Only

Not sure if it’s a change that needs to happen in Spacectl or spacelift itself. Any spacectl command that outputs logs (ie spacectl stack deploy or spacectl stack logs ) displays the output of Spacelift and Terraform. It’d be useful if we could optionally abstract all spacelift specific logs and only show the raw Terraform Output only. And possibly maybe a final line stating full spacelift logs can be seen on spacelift and link the run URL.

RBAC for module delete-version

It’s currently not possible to delete a module version without the space_admin permission on the root space. I would like to see a permission like MODULE_DELETE_VERSION available in RBAC.

Action overlay cover up list item details

On pages like Stacks or a worker pool, selecting items brings up an action overlay showing the number of items selected and actions to perform. This overlay covers up the list items, making it really hard to see what’s being selected and deselected. For example, in the attached screenshot, I couldn’t tell which stacks items 30 and 31 were. When I clicked the X to see them, it dismissed my selections. I found both behaviours frustrating.

Sort or filter on Delta, Issues column

There is a filter for Needs approval, although it may still be nice to use column sorting on Issues to group stacks (within a given set of filters or view) that have and don’t have issues. I’m not aware of a filter for Delta, e.g. terraform stacks that’ll add resources, or that’ll destroy them. It’d likewise be nice to group by or filter this way

Support outputs from multiple stacks to the same input in a downstream stack

I’d like to be able to configure multiple outputs to share an input in a downstream stack. For example. Stack A - Output: ecr_role Stack B - Output: codecommit_role… Stack X - Inputs: [ecr_role, codecommit_role] → allowed_roles