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)

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.

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

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

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.

When using the api if a service crashes after the api request but before a database is updated with deployment id's, there is a risk that any retries will create duplicate deployments. With idempotency keys this is mitigated.

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.

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?

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.