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.

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.

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.

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

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.

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.

Current in the UI i can see that a stack is drifted but i can’t easily see that run and past runs to see when it started or what the change even is

Today a Spacelift account is single-tenant: one root space, one set of account-level settings (SSO, audit trail, billing, login-policy ownership), and spaces as the only isolation boundary inside it. Spaces are excellent for team/project segregation, but they are not a hard tenant boundary, since root/account admin remains all-powerful across every space, and several controls stay account-wide. We need the same pattern GitHub provides with Enterprise → multiple Organizations: one commercial / SSO / billing substrate, with multiple tenants underneath as first-class isolation units. Each tenant would own its own admin boundary, spaces tree, integrations, and audit delivery, without requiring a fully separate Spacelift account per regulated entity. Analogy: GitHub: Enterprise → Org A / Org B / Platform Org Spacelift: Account → Tenant A / Tenant B / Platform Tenant └── spaces… └── spaces… That would let us keep a shared paved path (modules/policies consumed across tenants) while giving each regulated entity a native isolation unit stronger than a space subtree, without the cost and duplication of N independent Spacelift accounts. Related: we are also requesting per-space audit trail endpoints (link after posting) for the spaces-only model; multi-tenant accounts would preferably include per-tenant audit trail as part of the tenant boundary.

Today the audit trail webhook is account-wide: one endpoint for the whole account (docs, config under Audit trail → Configuration). Spaces already isolate almost everything else: RBAC, VCS integrations, worker pools, cloud integrations, policies. We would like to use a space-per-entity topology for regulatory / conflict-of-interest separation, but for this each entity needs its audit events delivered only to its own immutable sink (SIEM / Object-Lock bucket), under its own keys and access controls. It would be very helpful if audit trail webhooks could be configured per space (optionally with inheritance to child spaces), so events for resources in space A go only to space A’s endpoint. Account/root-level events could still use a root webhook. Terraform/API parity (space_id on spacelift_audit_trail_webhook) would be ideal. Related but different: Multiple Audit Trail Configurations asks for multiple account-level endpoints so several teams can ingest the same stream. We need space-scoped delivery so each entity’s sink receives only that space’s events — not a shared fan-out of the full account trail.

https://github.com/spacelift-io/celplate/blob/main/evaluator/cel.go#L41 Add ext.Encoders() so that we can encode to string

Spacelift’s OIDC tokens always have their audience set to your Spacelift hostname. However, many OIDC consumers require that they be able to set their own audience. Such consumers work on HCP Terraform because it allows you to set TFC_WORKLOAD_IDENTITY_AUDIENCE [1] to customize the token’s audience, but Spacelift offers no such feature. [1] https://developer.hashicorp.com/terraform/cloud-docs/dynamic-provider-credentials/manual-generation

Instead of the current behavior of drift detection runs being skipped if there are not available workers, it would be nice for there to be a separate queue for drift detection runs. The separate queue would have to be prioritized lower than the planned/tracked runs so that it is never pulled from when there are planned/tracked runs waiting to execute. This prevents users from having to space out drift detection runs evenly during off hours to ensure they all get run. It is both difficult to maintain and initially configure. There are probably many other solutions to the same problem.

Could the Changes tab show field-level diffs for Pulumi runs, similar to the Terraform diff view? Pulumi already includes the old and new values in its plan output, but Spacelift currently only shows high-level resource actions. This makes it pretty hard to see what actually changed without manually reading the full plan log.

Allow admins to select a system role and view all users currently assigned to it — consistent with how custom roles already work. Current behavior: For custom roles, admins can select a specific role and see the list of users who have it enabled (forward + reverse lookup both work - see image #2 “stack manage”). For system roles, only the forward lookup is possible (user → role). There's no way to select a system role and see which users have it assigned as “System roles cannot be managed”.

Feature Request: enable moving state from S3 to Spacelift State Management w/o needing to re-create stacks Per docs, once a stack has been created with an S3 backend, it is not possible to move to Spacelift State Management. It is a setting that can only be created at Stack creation Why is this important? If a run does not complete and times out / stuck / killed, S3 state-file remains locked. Admin intervention is needed to unlock the workspace. When using S3 state management, it is not possible to lock a stack in the Spacelift self-hosted UI