Support GitHub Enterprise teams in access and login policies

Our Spacelift stack uses “GitHub SSO with SAML/OIDC” to provision access to our Spacelift tenant. Organization GitHub teams are passed through to Spacelift and accessible via input.session.teams in login and access policies, but a GitHub enterprise team which has been assigned to the organization is not assigned to input.session.teams. Here is the API output for one of our enterprise teams: { "name": "Mozilla staff", "id": 19266226, "node_id": "ET_kwDNG0XOASX6sg", "slug": "ent:mozilla-staff", "description": "All Mozilla staff with GitHub accounts. Managed by Terraform in https://github.com/mozilla/global-platform-admin", "privacy": "closed", "notification_setting": "notifications_enabled", "url": "https://api.github.com/enterprises/mozilla-corporation/teams/19266226", "html_url": "https://github.com/orgs/mozilla/teams/ent:mozilla-staff", "members_url": "https://api.github.com/enterprises/mozilla-corporation/teams/19266226/memberships{/member}", "repositories_url": "https://api.github.com/enterprises/mozilla-corporation/teams/19266226/repos", "type": "enterprise", "enterprise_id": 6981, "permission": "pull", "created_at": "2026-08-31T22:44:59Z", "updated_at": "2026-08-31T22:44:59Z", "members_count": 926, "repos_count": 8, "organization": { "login": "mozilla", "id": 131524, "node_id": "MDEyOk9yZ2FuaXphdGlvbjEzMTUyNA==", "url": "https://api.github.com/orgs/mozilla", "repos_url": "https://api.github.com/orgs/mozilla/repos", "events_url": "https://api.github.com/orgs/mozilla/events", "hooks_url": "https://api.github.com/orgs/mozilla/hooks", "issues_url": "https://api.github.com/orgs/mozilla/issues", "members_url": "https://api.github.com/orgs/mozilla/members{/member}", "public_members_url": "https://api.github.com/orgs/mozilla/public_members{/member}", "avatar_url": "https://avatars.githubusercontent.com/u/131524?v=4", "description": "This technology could fall into the right hands.", "name": "Mozilla", "company": null, "blog": "https://www.mozilla.org/", "location": "Mountain View, California", "email": null, "twitter_username": null, "is_verified": false, "has_organization_projects": true, "has_repository_projects": true, "public_repos": 2586, "public_gists": 0, "followers": 10968, "following": 0, "html_url": "https://github.com/mozilla", "created_at": "2009-09-26T08:22:18Z", "updated_at": "2026-07-07T18:56:34Z", "archived_at": null, "type": "Organization" }, "parent": null }

Expose GitHub stacked PR data in push policy

Stacked PRs are a relatively new feature in GitHub (and other forges). GitHub exposes the stack information as a stack property on the pull_request object: % gh api repos/example/repository/pulls/1000 --jq '{number, state, base: .base.ref, head: .head.ref, stack}' { "base": "main", "head": "jj-stack/my-cool-branch", "number": 1000, "stack": { "base": { "ref": "main", "sha": "529290e92c9b48aa5c6f187fed2522ad9ba5a2ee" }, "id": 3077290, "number": 1030, "position": 1, "size": 30 }, "state": "open" }

Read burst budget usage with a non-admin API key

We want to automate bursting of our private workers during high-load periods. This seems to require reading burst.remainingMinutes (or usedMinutes) from workerUsage regularly so we stay within the burst budget. However, workerUsage is restricted to root Space Admin. We could use the worker_usage notification policy input but the docs say: "Neither route is real-time monitoring. Your usage is assessed once a day, against figures that stop at the previous midnight UTC, so a spike can be up to a day and a half old before it reaches you. When you need the current picture, check the usage chart." A day-old figure doesn't work for scaling decisions and estimating burst minutes ourselves risks drifting from what is actually billed. Could you add an RBAC action for reading worker usage, for example WORKER_USAGE_READ, that custom roles can include? That way a non-admin API key could query workerUsage. Alternatively, a separate query that returns only the burst figures and is readable without admin would work for us too.

Read-only role for organization settings (IdP group mappings, etc.)

Add a built-in or custom-role action that lets a user or API key read organization settings, including IdP group mappings, without being able to change them. Today viewing IdP mappings requires Space Admin. With Space Reader on root, stacks are visible but the IdP mappings API returns unauthorized. Spacelift support confirmed this is intended and that no read-only admin or auditor role exists. We want an AI agent connected through the Spacelift MCP server to inspect our RBAC setup (which IdP groups map to which roles) and report on it. Granting Space Admin to do that is far too much access for a read-only task. Something like "Organization settings reader" or a read-only auditor role would cover it.

Default Push Policy Options In Stack Settings

Would like to add a selection when creating and editing stack settings that allows for users to control what triggers proposed runs when no push policy is attached. Push file changes or PR diff (current behavior, stays the default) PR diff only, so proposed runs reflect the files shown in the pull request Tracked runs are unaffected: they continue to be based on the files in the push to the stack’s tracked branch. If a push policy is attached, it replaces the default behavior as it does today, and the setting has no effect. The UI should say so next to the setting.

Add worker pool info to Stack details screen

Add worker pool type to the Stack details quick lookup screen.

spacelift should support OIDC for incoming requests

non-human identities that integrate with spacelift must create api keys, which must be stored someone/managed. I would much prefer that spacelift is able to support authentication/authorization via OIDC. Two main use cases that I have in mind: 1. I have a use case where I need one spacelift instance to be able to auth as a role on another instance 2. We are moving orchestration to an external tool that will be called spacelift 3. workerpools should be able to be trusted by spacelift without having to generate an apikey

Push run and worker metrics via OTLP

Metrics today come from the pull-based Prometheus exporter, which still needs an Admin key (a read-only role is Planned), or from the Datadog-only integration. Teams that are standardizing on OpenTelemetry collectors want Spacelift to push run, queue, and worker metrics over OTLP to any backend, without running and securing an exporter per cluster. This is related to, but separate from, Richer native Prometheus metrics: full exporter coverage, run timing, worker/queue metrics. That post is about making the pull exporter complete. This one is about a push path over OTLP. Also related: Expose usage metrics through Datadog. Customers also want better queued-run and queue-time monitoring than they get from the current run count metrics. What this should include: The same endpoint config as the OTLP trace export request, so one destination can take traces and metrics. Metrics for run count, outcome, and duration by phase, queue time, drift runs as a separate series, worker pool busy/idle/capacity, and usage minutes. Labels for stack, space, worker pool, and run type. Keep the Prometheus exporter as the pull option. OTLP is the push option, not a replacement.

Export run traces via OTLP to your own observability backend

Run Observability already shows OpenTelemetry traces from the worker and the run engine inside Spacelift, and you can download a Jaeger file for a single run. That's useful, but it's not enough for teams that already run Grafana, Tempo, Datadog, Honeycomb, New Relic, or Splunk. They want those spans to land in their own backend automatically, next to the rest of their telemetry, without downloading a file per run. A large financial services customer running Grafana already has the consumer side built and wants a place to send these traces. Partners and other teams are getting a separate, unparented trace per tofu command and have to filter them by hand. They need a run root span plus export. It's also hard today to tell whether a slow run is on us or on a provider download. What this should include: An account-level OTLP/HTTP endpoint, with headers and auth, and optionally per-stack or per-space overrides. Batching and retry should be part of it. The same spans you already see in the Observability tab: the run root span, phases, hooks, providers, modules, policy eval, and server-side spans. Propagate TRACEPARENT so OpenTofu's own OTLP spans nest under the Spacelift run. OpenTofu v1.13 supports inbound propagation. Follow OpenTelemetry semantic conventions for attribute names, and keep the endpoint config contract stable. Those are one-way doors. Self-hosted parity on day one. Share the OTLP envelope with the audit and SIEM export work, rather than building this twice.

Segmentation and priority controls for public worker pools (parity with private pools)

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.

Read-only role (or scoped permissions) for the Prometheus exporter

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.

Allow stack owners to simulate policy on those stacks

We use spaces to govern stack permissions - ie: teams have stack permissions within spaces that we manage through custom read/write roles. And our users are also able to specify custom policy rules for their stacks (most commonly used for custom approval policies). There is no way for us to allow permissions for users to perform policy simulations on the policy they own (ie: the ones that are applied to their stack runs in their spaces). Users should be able to use the same policy debugging tools that admins use for policies being applied to their stacks.

Allow Admins to run Tasks on Template Deployment Stacks

Until very recently, we were able to run tasks on stacks managed by template deployments via spacectl. As of late this week, that’s no longer possible. Tasks serve important purposes for us: they aid in deletion (running tofu state rm) where deletion of deployments through the UI would otherwise fail due to how our infra is structured; they let us import state during migration of non-template deployment stacks to be managed by template deployments; and various other purposes such as unlocking state, quickly listing providers in the case of a SEV, etc. I’m requesting that, at least, admins be allowed to run tasks on Spacelift Template managed stacks.

Support explicit Boolean values for accountToggleAllowNonRootAdminSpaceCreation

We would like to manage accountToggleAllowNonRootAdminSpaceCreation declaratively through Terraform. Currently, the GraphQL mutation only toggles the existing value and does not accept an explicit Boolean value. This makes the operation non-idempotent because Terraform cannot reliably ensure the desired state. Repeated applies, retries, failed runs, or manual changes could leave the setting in the wrong state. Please provide a mutation that accepts an explicit value, for example: GraphQL mutation { accountAllowNonRootAdminSpaceCreation(enabled: true) } The same mutation should support false, allowing Terraform to enable the setting during resource creation and disable it during resource destruction.

Expand stack logs

Improved Policies Dashboard for compliance monitoring

Hi! Currently the policies dashboard allows us to check where policies are applied and to check the last sampled policy runs. This is important for plan policies, as we use them to enforce guidelines. It is hard to link a given policy to the stacks where it evaluated to a warning or deny. We would like to improve this dashboard to be able to have an overview of the compliance state of different stacks. When clicking on a plan policy, we would like to get the list of stacks where the policy evaluates to Pass, Warn or Deny. We would also like to get a global overview across all the plan policies of the number of stacks with their different evaluation results and the possibility to drill down into them. We also would like to be able to export the policy evaluation result to be able to centralize them in our SIEM tool. This is especially valuable as we have several Spacelift instances running independently.

Add an account-wide setting to ignore repository-supplied runtime configuration

We’d like an administrator-controlled setting that ignores repository-supplied runtime configuration by default, with an allowlist for specific repositories. The existing feature:ignore_runtime_config label is useful per stack, but does not give us a consistent account-wide option. Stack level labels are also easy to add/remove. In a large organization with many repositories, repository write access is distributed across teams. Allowing each repository to supply runtime configuration gives those files a way to affect Spacelift runs. We’d like to limit that capability to repositories we explicitly choose as part of our security controls.

failed run

A failed run retry shouldn't require re-approval for no code changes

Include stack and space labels in OIDC session tags

We’re using Spacelift OIDC so runs can read secrets from AWS Secrets Manager. My options for the trust policy seem to be limited to the sub string and either wildcarding spaces/stacks by a naming convention that would be messy to implement and maintain, or enumerating slugs in the trust policy which is even less desirable. I’d like to be able to extend the existing Spacelift autoattach: mechanism that we use to attach contexts to stacks through to the AWS policy by including stack and ideally space labels as session tags. I see that you already have a few session tags as an opt-in feature by way of the feature:aws_oidc_session_tagging stack label, but labels aren’t included in what’s sent. AWS limits the number of session tags and key length, so extending the opt-in label with options to filter by prefix such as oidc: would be helpful. It would also let us narrow which labels are used for access control. Including space labels would be beneficial from a security and maintainability angle, since space labels can be more tightly controlled than stack labels and not having to label every child stack individual would be much easier to maintain. I’d think these should have separate, configurable prefixes so we could distinguish the label scope on the AWS side. If there was a way to enable and configure session tagging (filters, prefixes, stacks/spaces/modules enabled, etc…) at the account level would be great. Having to add that feature label to several hundred stacks is cumbersome. Modules should support this too using module labels so module tests can access secrets via OIDC when needed. Using labels in this way doesn’t feel like it adds a new trust boundary since stack labels already can/are used to control context attachments and role assignments. This would just allow us to use that same mechanism for extending access to other backends.

Targeted replan for Pulumi stacks

Targeted replan works for Terraform and OpenTofu stacks. On a Pulumi stack the API returns "replan is only supported for Terraform and OpenTofu stacks", and the Changes view has no resource selection because "detailed resource changes are only available for Terraform, OpenTofu and Terragrunt stacks, not Pulumi; use changesV2 for this run". We want the same flow for Pulumi. A tracked run reaches Unconfirmed. The user selects resources in the Changes view and presses Replan. Spacelift plans again with `pulumi preview --target ` for each selected resource, and applies with `pulumi up --target `. The run stops at Unconfirmed again with the reduced plan. Pulumi already supports `--target` on preview and up, and the changesV2 data has the URN for each resource. The URN is the address Pulumi expects. Our use case is a stack with unrelated pending changes that need their own review. Today we run a task with pulumi up `--target --yes`. That skips the plan and confirm steps, and the approver sees a command string instead of a plan.