Public workers today are a single shared account-wide pool with no segmentation or priority controls. Private worker pools, by contrast, support multiple named pools, per-stack routing via labels, and priority ordering: the primitives we rely on to isolate workloads, manage concurrency, and protect critical paths. As we scale, teams that want those organizational controls have only one option: stand up private pools, which means owning the infrastructure, autoscaling, runner cost, and lifecycle. Given that public and private workers are priced the same per worker, we'd love to see public pools reach feature parity: named public pools, stack-to-pool routing via labels, and priority ordering. That would let teams get the segmentation controls they need without absorbing the operational lift of self-managed runners, and it would also open a fairer conversation about whether the pricing model should reflect the operational burden customers take on when they choose private purely for reasons other than segmentation.

The Prometheus exporter (spacelift-io/prometheus-exporter) currently requires an Admin API key because some of the metrics fields it queries are gated behind admin access. This forces us to distribute admin-scoped credentials to every cluster running a private worker pool, purely to expose queue depth, worker counts, and billing usage to Prometheus. Please add a read-only role (or scoped permissions) that grants only what the exporter needs, assignable via IdP group mapping and usable with OIDC API keys the same way other roles are. Reducing the exporter's permission floor to a space-scoped read role would eliminate credential sprawl, align the exporter with least-privilege posture, and make it defensible in regulated environments where admin scope on a metrics collector is a hard audit finding.

In the stack list, each stack shows an aggregate delta badge (~2, +3 −12, or a collapsed "2 deltas"). Today the only way to see which resources changed is to click into the stack and then navigate back. A tooltip or hover popover showing the resource-level breakdown — resource addresses plus change type — would let us triage a list of unconfirmed drift in place. Expanding the collapsed "N deltas" badge on hover would help for the same reason.

The default-card Slack notification (via a NOTIFICATION policy's slack rule) already color-codes its sidebar by run state, e.g. yellow for UNCONFIRMED, red for DISCARDED, blue for CONFIRMED. We'd like control over that mapping, since blue doesn't read as "resolved" the way green would. Ideally either a way to set the color per state ourselves, or at least having Spacelift map CONFIRMED/FINISHED to green instead of blue.

Description: There is currently no way to automate private worker pool key rotation in Spacelift. The only available mechanism is a manual reset via the console (Manage Organization → Worker Pools → Reset), which immediately disconnects all workers and requires a planned maintenance window. Request: Provide an API or automated mechanism to rotate private worker pool keys without requiring full worker disconnection, enabling teams to rotate on a regular cadence (e.g. 90 days) without manual intervention or downtime. Desired outcome: API-driven key rotation support Graceful worker reconnection (no hard disconnect/maintenance window required) Ability to integrate rotation into existing secret management pipelines (e.g. Azure Key Vault)

Add a way, ideally with the spacectl CLI, to create a (renewable?) access token with more restricted permission scope than the user’s full access.My use case is I would like to use spacectl with AI in a sandbox, so it can view the plans made by PRs, and trigger speculative plans. However, I have more elevated spacelift permissions, and I DO NOT want the AI to be able to make actions that I have access to with my spacelift permissions

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.

In the new Slack integration, confirming a run updates the previously posted UNCONFIRMED notification to CONFIRMED. This is very good for Slack ops efficiency - on-call can scan the channel for today and see outstanding actions. I'd like to request the same for FAILED. If a subsequent run from the same commit resolves the stack into FINISHED, the associated Slack notification should also resolve into an OK/green state. This would help with transient errors: retrying a run, or invalid operator decisions - an operator rejected a run flagged by policies, but the run should actually have been approved.

Currently when making any policy and a stack is triggered by another stack you only see one triggered_by. If you have more than one layer of apps that depend on the very first stack needing an approval, and you want to auto-approve the dependent stack there isn’t a clean way to say if it was triggered by this job since the triggered_by won’t have any information on what the root stack is. The ask is similar to https://feedback.spacelift.io/p/include-the-runid-of-an-upstream-stack-and-any-other but just always for triggerred_by. Where currently run_id is recursive and you can use the OPA walk function to get the data.

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.

Can we add an option to open all stacks selected in new tabs please? similar to PRs in github

Our Terraform modules often use complex variable inputs of type list(object({})). Unfortunately it’s not possible to expose these complex types in our Spacelift templates. A definition could be something like this: inputs: - id: stacks name: Stacks description: Stacks that should be available to your Spacelift space type: list(object) schema: - id: name name: Name type: string - id: environment name: Environment type: select options: - dev - staging - prod

These settings would override any default images at the Org level, allowing us to define the three different ECR repos we use for Commercial, GovCloud, and FedRAMP respectively.

Add an info (or note) rule to plan policies: a list of strings rendered in the run's Messages list the way warn is, in blue or green, with no effect on the run's outcome and no effect on autodeploy.

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

Spacelift self-hosted deployment uses a static RDS master password. Best practices and compliance requirements call for DB credentials to be regularly rotated, which AWS supports out of the box for Aurora clusters: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html Even better, AWS RDS/Aurora supports IAM database authentication, which uses short-lived (15-minute) authentication tokens instead of a stored password, and can be used together with master password rotation: Master password rotated regularly via AWS Secrets Manager, and used only for administrative/break-glass access Spacelift connects to the database for normal operation via a dedicated database user authenticated with IAM auth tokens, so no static password is used on the application's connection path Note: the module already sets iam_database_authentication_enabled = true on the aws_rds_cluster resource, so the AWS-side prerequisite for IAM auth is already in place. Can Spacelift backend be configured to generate/use IAM auth tokens for their connections rather than a password?

The private provider registry ingests only overview, resource and data source documentation. Pages under docs/functions/ — the standard layout emitted by HashiCorp's own tfplugindocs — are discarded on upload with no error or warning, so providers that ship functions have no documentation in the registry UI beyond their overview page. To reproduce 1. Publish a provider whose docs/ contains index.md and functions/.md 2. spacectl provider upload-docs --version --docs-archive docs.tgz → exits 0 3. Query docs { files { key type } } → only docs/index.md is present

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

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.