We have consolidated our modules into one git repo and are using sparse checkout paths. However, our resources are split across separate modules. As an example we have three separate modules: - `terraform-azure-sqlserver` - `terraform-azure-sqlelasticpooldb` - `terraform-azure-sqlserverdb` When I test the `sqlserverdb` module, I need the server and elastic pool modules available. Historically we've referenced the Spacelift registry version of the sister module in the test stack. This worked fine, but now we're doing a big bang azurerm v3 → v5 upgrade and testing fails due to the provider dependency conflict described above.

Ship ARM binaries in self-hosted tar so customers can choose ARM AWS EC2 instances, such as Graviton. This will bring consistency across SaaS and Self-Hosted.

We used to have Terraform stacks with the terragrunt label in order to run Terragrunt. This configuration allowed us to execute targetted replans. It seems that Terragrunt stacks (without the terragrunt label) do not have this functionality. This functionality should also be supported in Terragrunt stacks.

We have 200+ stacks that are set up in the pattern of spaces below. They need to have a common role attached to them and currently we have to attach the role to the stacks separately; this is easy enough to do but it does add 200+ role_attachment resources to our metadata stack. As we scale this pattern out to other roles and stacks spacelift runs will slow down due to large numbers of resources in opentofu. - parent <-- have role here - child_space1 - space_with_stacks_in <-- use role here - child_space2 - space_with_stacks_in <-- use role here Proposed solutions Allow roles to be attached to a space and child stacks inherit it Allow roles to be autoattach: in a similar way that rego policies can be

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.

We can see all the metrics available in the Prometheus exporter here: https://github.com/spacelift-io/prometheus-exporter#available-metrics But there are no metrics to see the time our runs are waiting for runners to be ready This is the metric in the UI (see image)

Expose plan-phase diagnostics to policy. Preferred shape: input.terraform.diagnostics[] in the plan policy input, each entry carrying severity, summary, detail, address (when resource-scoped), and source range (filename + line). That shape is the most useful because a plan policy could then act on warnings and set run flags — which notification policies already read via input.run_updated.run.flags. Workable alternative: write them into the workspace before after_plan hooks run, e.g. spacelift.diagnostics.json beside spacelift.plan. Either one solves it; we don't need both. This is data OpenTofu/Terraform already emit — "plan -json" produces exactly these fields as {"@level":"warn","diagnostic":{...}}. Nothing new needs computing, it just isn't captured anywhere reachable.

When viewing the resources page for a stack, I would often like to filter to all resources in a certain module. While there is a “parent entity” filter, that only shows resources that are direct children of the module, not resources in nested modules. I want a filter that shows all resources including resources in recursively nested modules.

## Summary When Terraform marks a resource attribute as Sensitive (e.g. okta_app_oauth.client_secret, using the Okta provider), Spacelift run UI still shows the plaintext value in the resource create/update diff. We expected the same redaction the tofu CLI uses: (sensitive value). ## Why it matters OIDC client secrets (and similar provider-computed secrets) are visible to anyone who can view the Spacelift run. That expands the blast radius beyond state access and makes it harder to share run links / screenshots safely. Our module already marks the output as sensitive; the gap is in the resource attribute diff rendering. ## Reproduction 1. Apply a stack that creates okta_app_oauth (confidential client; omit_secret left at default false). 2. Open the Spacelift run and inspect the resource changes for the OIDC app. 3. Observe client_secret shown as a raw string in the diff, e.g.: + client_secret: "..." instead of: + client_secret: (sensitive value) ## Expected Any attribute Terraform reports as sensitive should be redacted in: - plan diffs - apply diffs - related run log / change views in the Spacelift UI State may still contain the value (Terraform limitation), but the UI should not display it in plaintext when sensitivity metadata is present. ## Ask Please redact Sensitive resource attributes in Spacelift run diffs/logs using Terraform’s sensitivity metadata, consistent with terraform plan/apply CLI behavior.

Spacelift Repos selection only shows in stack creation when creating a stack in a space where a repo exists. Would like this to change to always be available and just note that there are no available repositories in the space if that is the case.

Requesting re-usable actions for templates. For instance: creating a template that adds an EC2 to a space. In that template is a drop down that says “Select Space.” Behind the scenes is a dynamic action that runs an api call that gathers a list of all spaces inside Spacelift. Then this list is presented to the user in a drop down. This would also enable a team to create re-usable actions that enable templates to be more dynamic and less stactic.

Currently the only way to read sensitive values from a stack is to running a task that runs tofu output . This works - but has a major flaw, it exposes the sensitive output value to anyone who has read only on the stack. We’d like a way to directly view sensitive outputs in the stack UI (and potentially via tools like spacectl) which is locked behind a more privileged permission than Read only. This could be stack write or (better) a specific, new permission for viewing sensitive outputs.

We have 2 apps that send checks for separate self-hosted instances. (though this could happen if you have 2 github integrations for whatever reason. We would like the ability to configure the spacelift/ prefix in the checks. so that we can have spacelift-a/ and spacelift-b/ in our checks list.

Hi Spacelift community, for running Spacelift workers in Azure, we currently have 2 different possibilities: deploying the workers in a Kubernetes cluster or deploying them via the Terraform module in VM scaling set. We have the requirement to use a different managed service for the deployment, Azure Container Apps. In this regards, we have the question if this is something which is on the roadmap or could be potentially supported? Many Thanks & Best Regards

When creating a module in the private registry, the module is launched without a version and users have to manually “trigger” the module to make it available. There should be a way to automatically have the module launch with an initial version and then future iterations can rely on the spacelift yaml file.

We should be able to approve all stack syncs. Right now if there are multiple confirms queued up. You need to individually confirm the first one, wait until done, and then confirm the next one, etc. one at a time. You can't confirm a queued request while another one is running. This is very annoying!

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.

Audit trail webhook did not deliver RBAC role create/delete events. Compliance evidence gap; access enforcement remains operational.