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.

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)

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

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.

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.

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

We are currently tightening our security policies on certain actions in Spacelift. One of our focus is to reach the plan phase of a proposed run only after an approval of a codeowner. So far we succeeded testing adding a label on a stack that basically contains a list of GitHub teams based off of the actual CODEOWNERS, this way Spacelift on any action in the stack can access to the GitHub team that owns the stack and the code it tracks. Then we created an approval policy that waits for an approval from the codeowners. Once a PR is created and thus a proposed run is triggered and starts, then evaluates something in the lines of: requires_approval if { not creator_is_codeowner } ## Creator is a code owner if their GitHub teams overlap with codeowner_teams creator_is_codeowner if { some session_team in input.session.teams some codeowner_team_group in codeowner_teams session_team in codeowner_team_group } ## Auto-approve: creator is code owner approve if not requires_approval ## Approve: someone from the owning team reviewed in Spacelift approve if { count(input.reviews.current.rejections) == 0 requires_approval some review in input.reviews.current.approvals some session_team in review.session.teams some codeowner_team_group in codeowner_teams session_team in codeowner_team_group } TL;DR if the author of the PR is not a codeowner (i.e. doesn't belong to a github team the the stack is labeled with), then requires an approval of a codeowner. The parts that work: The approval policy is evaluated before the plan phase The approval policy lets the run continue and finish only after a codeowner approval The parts that we would like to have but are not supported by Spacelift (to the best of our knowledge) At the PR creation event and evaluation of the approval policy this block is in the approval policy: ... "commit": { "author": "AUTHOR_USERNAME", "branch": "BRANCH_NAME", "created_at": 1785152807000000000, "exist_on_tracked_branch": false, "hash": "HASH", "message": "Test codeowners approval", "tag": "", "url": "https://github.com/ORG/REPO/commit/COMMIT_HASH" }, ... "creator_session": { "admin": "", "creator_ip": "", "idp_subject": "", "login": "", "machine": true, "name": "", "teams": [] } ... No way of getting author teams

Users running a single large Terragrunt stack with Use Run All enabled have no way to scope a run to the units affected by a change. Every triggered run executes terragrunt run-all across the entire project root regardless of what changed [https://docs.spacelift.io/vendors/terragrunt/run-all], which on a large project means long, wasteful runs and a single monolithic run log with no per-unit history.

Currently my company is on the Starter plan which comes with two public workers. 90% of the time, that is more than enough for our day to day operations. However, it would be amazing and also something I would be completely onboard with paying a premium price on if we could dynamically scale up even a couple workers on occasion. The scenario where we may want something like that would be in the case where we are affecting a change across a module with many stacks, like ECS or Lambdas. The two worker limitation on Starter becomes a bottleneck. While I know Enterprise has the ability to auto scale, we just don’t need that big of a contract or that many workers on a regular cadence for it to make sense to sign onto that. But I would be more than willing to pay a per-min compute price for a few extra workers on demand or when our queue of jobs gets to a certain depth.