Changelog

Every platform team is running automation nobody wrote down: a Lambda function nobody remembers deploying, a Slack bot that only two people can restart. Call it what it is: tech debt with a heartbeat.

Spacelift Flows replaces that. As of September 8th, Flows is live and ready to use for your Day 2 Operations.

Wire blocks together on a visual canvas, HTTP Endpoint, Transform, Condition, Schedule, and MCP Tool among them, using expressions that reference outputs., signals., secrets., and ref() directly. Every run is logged and audited from the first execution, with approvals gated at whatever block you choose.

If you run Spacelift Deploy, flows trigger natively off stack, run, and drift events, the kind of context a generic automation tool never has. Route a Slack approval the moment a stack drifts, or gate a staged rollout across dev, staging, and production with human sign-off at each step.

Skip the blank canvas: There are 40+ templates available that cover incident enrichment, drift alerts, environment vending, certificate expiry monitoring, and self-service provisioning through Jira or ServiceNow. Just pick the closest one, and edit it to your specific needs.

Under the hood

Every field accepts full JavaScript. Flows can live in Git and ship through the Spacelift Terraform provider or flowctl, so automation gets the same version control and review your infrastructure already receives. Flows also provides a Model Context Protocol (MCP) server, so a flow can be exposed as a tool an agent calls, or call an agent itself.

Details

• Blocks include HTTP Endpoint, Transform, Condition, Explode, Collect, Schedule, Sleep, Memory, MCP Tool, and Error

• Native triggers on Spacelift stacks, runs, and drift for Spacelift Deploy customers

• Version-controlled via Git, the Terraform provider, or flowctl

• MCP server support for exposing flows as tools to AI agents

Get started today

Flows has its own place in the Spacelift app switcher in the top left corner of the platform. Open it, pick a template, and connect your first app.

Feel free to Browse the template gallery or Read the Flows docs. And as always, take it for a spin, and let us know what you think. We always want to hear from you.

More Spaces should mean more clarity, not less. A few months in, you're managing dozens of them, nested several layers deep, and answering "what lives here" or "who has access" means opening each one and clicking through tabs to piece it together.

We rebuilt the Spaces list and space view so you don't have to do that anymore.

• The space view now shows a Space's Stacks, Contexts, and Policies right there, so you don't have to hunt across screens for what's inside it.

• Access breaks down by kind: a direct role, an Identity Provider (IdP) group, or a role inherited from a parent Space, so you know exactly why someone can do what they're doing, not just that they can.

• Parent Spaces stay pinned at the top of the list while you scroll through their children, so a hierarchy of dozens of Spaces and labels stays readable instead of turning into an endless scroll.

• Breadcrumbs show a Space's full path in your org structure, so you always know where you are.

Be sure to check out the new view, take it for a spin, and let us know what you think! For more info on Spaces, check out the docs here.

Finding Infra Assistant used to take a few clicks. Reading its history meant opening a dropdown. Giving it more room on screen wasn't really an option. You asked, and we listened. So, now that changes, and more!

Here’s what is changing:

• You now land on the new Assistant page by default when you open Spacelift, unless you've already set a different homepage.

  

• Infra Assistant moved up in the main navigation and opens straight into that page now. Want it scoped to what you're looking at instead? Hit Ask in quick search.

• The assistant got a rework: controls adapt to your screen size, chat history lives in a side panel instead of a dropdown on wide screens, and the quick-command examples got refreshed too.

• Set approval mode to always ask and review every step, or switch to auto and let it run with less supervision.

  

• Switch to full-screen from the modes dropdown, or double-click the panel header when you're in floating mode.

• Quick search comes up empty? Ask the assistant directly, or hit the button next to the input to send your text in as a prompt instead of retyping it.

  

• Collapsed navigation now previews on hover, so you can see what's there without clicking in. Pin it open if you'd rather keep it visible.

• Creating a stack now has choices: the traditional way, or by asking the assistant.

• Stacks also get their own Ask button, so you can check what's going on with a stack without leaving it.

  

These updates are pushed out and ready to go. Set a homepage if you don't want the new default, and give auto mode a try if you've been approving every step by hand. As always, take it for a spin, and tell us what you think. We always love to hear your feedback.

You don't live in Spacelift. You live in Slack, and in GitHub. When a run fails or a critical notification fires, you want it where you're already working, not buried in an inbox or a tab you forgot was open.

Now it can be. Connect your Slack or GitHub account under Personal Settings → External Accounts and link it to your Spacelift identity. Once it's authorized, Notification Policies can send updates straight to your linked account. 

Teams support is coming soon.

Ready to get started? Check out the docs:

• Connect an external account

• Notify the commit author in a Notification Policy

Historically, when something fails on our side, our infrastructure, not yours, our API still responds with HTTP 200. The response body says "internal error," but the status code says everything was fine. Any monitoring tool watching status codes never sees the failure at all.

This is just to let you know we’re fixing that. Internal errors will soon return HTTP 500. Your monitoring catches what it should have caught all along, and so does ours, which means faster detection and faster fixes on infrastructure issues on our end.

Nothing about the failure itself changes, only the status code does. These are errors you could never have fixed on your end anyway: the error message never gave you anything actionable, and that hasn't changed.

We're rolling this out behind a feature flag, and aren’t going to start for about a month, so we can control the pace and revert immediately if needed. This also gives you some warning period about the change. This won’t affect every account in Spacelift, due to configurations, and usage, but there are some things to look for.

What to check

This is technically a breaking change, even though we expect the real-world impact to be small for most teams. It only matters if your integration reads HTTP status codes to drive logic, retries, alerts, pipeline gates, and so on.

• If you have custom automation built on our API, check whether it treats a 200 as "succeeded" without also checking the response body for errors.

• A request that previously came back as 200 during an internal error will now come back as 500.

• Everything else about the request and its outcome is unchanged.

If your integration already handles 5xx responses the way it should, you won't notice this change at all. Have questions? Please let us know. We’re here to help.

That’s right! Now you can ask the AI to deploy a module by name. Spacelift Intent resolves it against your Spacelift module registry and applies it as a single managed resource, under your existing policies, state, and audit trail. No module block, and no PR required. The guardrails already built into your registry and your Intent policies still apply.

"Deploy the elb module" resolves to the module's slug (terraform-aws-elb), picks its latest active version, and prompts for any missing inputs. Pin a version or pass inputs up front for precision: "Deploy the elb module at version 1.2.0, with the web load balancer inputs.

Before applying, Intent verifies the module is visible and active, and that every required input is set with nothing undeclared. If it fails a check then nothing will run. Pass them, and Intent evaluates your Intent policies (resource_type: spacelift/module, operation, provider: the slug, provider_version, proposed_state: your inputs), then runs the module on a worker in the background.

Updates and upgrades work the same way: "Set the idle timeout to 120" or "Upgrade to the latest version." Intent diffs the input schema between versions, and carries your existing values forward. It only asks about what's new or newly required.

Each deployment is one spacelift/module resource in your Intent project. Its managed resources are nested underneath and read-only. Every create, update, and delete action is logged in History.

Intent only deploys modules from your Spacelift module registry. It does not pull modules from the public Terraform Registry or directly from Git. The module has to be published to Spacelift first. As always, take it for a spin, and let us know what you think.

Check out the documentation here: Deploying Spacelift Modules

Spacelift now supports SCIM 2.0 (System for Cross-domain Identity Management). Your identity provider becomes the single source of truth for who has access to Spacelift. Okta, Microsoft Entra ID, OneLogin, or any IdP that speaks SCIM 2.0 can automatically sync users and groups, so you never have to manually invite or remove anyone again.

When someone joins your company or switches teams, their Spacelift access updates automatically based on IdP group membership. When someone leaves, their account is deactivated and all active sessions are revoked. No stale accounts, no forgotten cleanup.

Groups sync too. Push them from your IdP via SCIM, then assign roles using the Spacelift Terraform provider (recommended) or the UI. You get version-controlled, auditable access management that stays current with your IdP automatically.

How it works

Generate SCIM credentials in Organization Settings > Single Sign-On, configure your IdP with the base URL and OAuth 2.0 client credentials, and syncing starts immediately. The credentials are scoped exclusively to SCIM endpoints. SCIM creates user and group records but does not assign permissions. You control what people can do through role bindings or login policies.

Details

• Full CRUD for users and groups via SCIM 2.0 (RFC 7644)

• User deactivation and deletion both revoke active sessions immediately

• Group membership syncs automatically, keeping role assignments current

• Filtering by userName, active status, email (users) and displayName (groups)

• Enterprise plan only. Requires SSO to be configured first. Some IdPs (like Okta) require SAML, not OIDC, for SCIM.

Read the full documentation: SCIM documentation

Have you been working hard since the new learning modules in the Launchpad came out? We know a lot of you have. And now, we’ve introduced a way to commemerate all your hard work, and celebrate your accomplishments! As you complete the learning modules, you can now view and download a certificate of completion. Your whole team can share in the pride as everyone gains more skills by completing missions, and collecting more certificates!

This update also brings the Launchpad and learning modules to even more users of the Spacelift platform. It’s not just admins who can see the Launchpad now. So be sure to check it out, complete some missions, and let us know what you think! Happy Learning!

Please Note: Some missions may not be available to all tiers, and some users may not have all the access needed to complete all of the missions.