February 26th, 2026
Maybe you’ve seen this issue before. In complex organizations where multiple teams share a Spacelift account, spaces often end up with the same name in different branches of the hierarchy, like having a us-east-1 space under both production and staging. Without the ability to customize the subject claim, those spaces produce identical OIDC tokens, making it impossible for cloud providers like AWS, GCP, or Azure to tell them apart and apply the right permissions.
You can now customize the OIDC subject claim that Spacelift includes in tokens generated for cloud provider authentication. Previously, the subject claim was always built from the space slug, which caused a frustrating problem in hierarchical space structures: two spaces in different branches of your organization but with the same name, like /root/production/us-east-1 and /root/staging/us-east-1, would produce identical subject claims. That made it impossible to write cloud provider trust policies that distinguished between them.
The new subject template setting lets you define your own claim format using a set of available placeholders, including {spacePath}, which resolves to the full hierarchical path of the space. This unlocks two things that were not possible before: you can now differentiate between identically-named spaces in different branches, and you can write a single wildcard trust policy that covers an entire branch of your space hierarchy, like all production spaces, without needing to update the policy every time a new space is added. The setting is available in Organization Settings under Security, requires admin access, and comes with a migration guide to help you update existing trust policies without causing authentication failures during the transition.
You can read the full documentation here!
February 25th, 2026
Improvement
In our continued effort to bring you the best possible platform for your IaC management, today we are happy to announce that Terragrunt is now officially a first-class citizen in Spacelift! What does that mean exactly? The biggest news is that we now support native state management inside the platform. That means you can now let Spacelift do what Spacelift does best, while using your Terragrunt projects. Previously, you had to use remote state configurations if you wanted to use Terragrunt inside Spacelift, but not anymore.
This is a big win for all of our users, and provides even more options and flexibility when it comes to working with multiple frameworks across clouds. Be sure to give it a go, and let us know how you like it. Your feedback and input is critical for us.
Note: In the process of delivering the functionality for Spacelift to manage the state of Terragrunt projects natively, previously the behavior of selecting to “Delete Resources” when deleting a stack was that none of the resources would actually be removed. So whether you picked to keep or delete resources, they would simply remain. This non-expected behavior has now been remediated. Now, the expected behavior should be exactly what you select when deleting resources. When deleting the stack, resources will either stay or be deleted based on which option you select.
For more info on Terragrunt support in Spacelift, and to get started, check out the blog, video, and Documentation.
February 18th, 2026
As always, you’ve been asking, and we’ve been listening. I’m sure you’re already very familiar with Blueprints in Spacelift. A Blueprint is like a template for a stack and its configuration. The blueprint contains variables that can be filled in by providing inputs when creating a stack from the Blueprint. The blueprint can also contain a list of other resources that will be created when the stack is created.
This is all well and good, but we really wanted to step it up a notch. And with that being said, I’d like to introduce you to Templates! Templates provide a self-service approach to infrastructure provisioning, making it easier for application developers to deploy infrastructure without deep IaC or Spacelift knowledge. Templates focus on enabling end users to deploy infrastructure through a simplified, form-based interface.
Now, I know what you’re thinking. That kinda sounds like Blueprints. But, while both features enable infrastructure provisioning, they have fundamentally different approaches and serve different use cases:
Blueprints are a creation tool that generates stacks which then live independently:
Creates stacks that become regular, fully editable Spacelift stacks
Once created, stacks can be modified manually like any other stack
No ongoing relationship between the blueprint and the created stacks
Stacks continue to evolve independently after creation
Blueprint changes don't affect previously created stacks
Templates are a lifecycle management tool that maintains control over deployed infrastructure:
Creates stacks through deployments that are fully managed by the template
Stacks created from templates are immutable - cannot be edited manually, even by admins
The only way to modify infrastructure is by:
Updating the template deployment to use a different version
Creating a new template version with changes and update deployment to use it
Modifying deployment inputs
Deployments maintain a permanent link to the template version
Templates ensure consistency across all deployments
There are 2 main interfaces for Templates. The Templates Workbench is designed for platform teams and template authors. The Templates List is designed for application developers and end users.
Templates are now available for any customers with Business plans and above!
For more information, check out the documentation. And be sure to let us know how it goes. Your feedback is important to us!
January 13th, 2026
Happy New Year! We’ve been hard at work, back after a great holiday season. And now we’re ready to share a cool new update we have for module sharing permissions. Previously, to be able to share a module with a space, you needed the following permissions:
Admin access on the space where the module belongs, AND
Write access on the space where the module belongs
We know that it wasn’t exactly ideal to have to provide admin or write access to the entire space just for module sharing. We heard your requests, so now we are introducing a new action to advanced access. The SPACE_SHARE_MODULE control allows sharing a module with a space without giving admin or write access to the target space!
Note: that the role should be assigned to the space you want to share with, and not the space of the module itself.
This was a highly requested feature, so we are really happy to deliver it to you. You can read more about module registry permissions in the documentation here. And, as always, your feedback is important to us. So take it for a spin, and let us know how you like it.
December 19th, 2025
Have you found yourself creating a new stack, and wish that your cloud integration would simply just be available and attach automatically? Your day has come. Auto-attach for cloud integrations is now GA in Spacelift!
Whenever you create or edit a cloud integration, you can now toggle Enable auto-attach. Once that is done, just add a label to the integration that says autoattach:<your_label>. Any stack that has <your_label> on it will automatically attach the cloud integration. It is as simple as that!
This was one of the most requested features, so we are really happy to deliver it. Take it for a spin, and be sure to let us know what you think. We always want to hear from you.
For more info, check out the documentation here.
December 17th, 2025
Yep! You heard that right! Early Access to Spacelift Intent is now available for everyone!
What is Spacelift Intent?
Spacelift Intent lets you provision and manage infrastructure by describing what you need in natural language. Instead of writing Terraform/OpenTofu code, your MCP client (e.g. Claude Code) calls Spacelift Intent, which directly interacts with provider schemas under Spacelift’s guardrails (policies, audit trail, state, permissions).
Are you ready to deploy and manage infrastructure using natural language through the LLM tools that you’re already using? Then be sure to take Intent for a spin. For more information on Spacelift Intent, you can read up in the documentation here.
Spacelift Intent is still in early access, so we're looking for your feedback. Is it helpful? How could it be more useful to you? We definitely want to hear how it is working for you and what you think of it, so make sure to leave us feedback and reach out if you'd like to talk with a member of our product team about it.
You can check out a quick video about how to configure Intent with Claude and get started here.
December 4th, 2025
Yet again, you asked, and we listened! Today we would like to announce that the Command Pallete is now available in beta!
You can find it up in the top left corner of the UI, or access it quickly with command+K. You’ve now got quick access to a multitude of actions, from one simple menu:
From shortcuts like Create New Stack, and Create New Module, to navigation shortcuts like Dashboard, and Resources. You can also toggle the Theme of the UI, and search for things that may be harder to look for. This feature will be handy for new and experienced Spacelift users alike. You can open this box, and navigate, all with your keyboard. Or use the mouse and click around like you normally do.
As I mentioned before, this feature is in beta for now. So, take it for a test drive, and make sure to leave us feedback. We always want to make sure that we are not only building the features you want and need, but that we’re implementing them in the right ways. Your feedback is always welcome. Stay tuned for more exciting things heading your way!
November 17th, 2025
As always, when you ask for things, we listen. We are happy to announce that you can now assign the Space Admin role to users for non-root spaces! Non-root Space Admins can now view all roles, users, API keys, IdP group mappings (read-only), and manage role bindings within their assigned administered spaces. Previously, these capabilities were limited to Root Space Admins only. This is a big step forward to help better enable multi-tenancy administration inside the Spacelift platform.
Root Space Admins (Space Admin role on the root space) have account-wide privileges including:
All Space Admin permissions across all spaces
SSO setup, VCS configuration, audit trail management
Invite/revoke users and create/modify/delete roles
Create/modify/delete API keys and IdP group mappings
Manage role bindings across all spaces
Non-root Space Admins (Space Admin role on any non-root space) have limited privileges:
Space Admin permissions only within the spaces they administer
Can view all roles, users, API keys, and IdP group mappings
Can manage role bindings only for the spaces they administer
Cannot invite/revoke users, create/modify/delete roles, or create/modify/delete API keys and IdP group mappings
For more information on the Space Admin role, check out the documentation here!
November 13th, 2025
If you thought Spacelift couldn’t get any better, then wait until you hear about Plugins! Plugins are a way to extend the functionality of Spacelift even further. They allow you to integrate with third-party services, automate tasks, and enhance your workflows. Spacelift supports a variety of plugins here on Day 1, which can be used to perform actions such as sending notifications, managing resources, or integrating with external systems. We have a template gallery available right now with a number of great tools.
You can also develop your own custom plugins using our plugin SDK, spaceforge.
For more information on how to use Plugins, check out the Documentation.
Do you not see the tool you want integrated as a plugin? We have a great list of plugins already available for use, such as Infracost, terrascan, and Checkov. Though, if you don’t see something you need, we highly encourage you to contribute! Check out the GitHub Repository here!
November 10th, 2025
We are pleased to announce this new feature today. Previously, we had the ability to set a stack as Administrative, so that it could manage resources in other stacks, but this ability was only available in Spaces on the same branch. We are now introducing Stack Roles into the platform. This will allow you to have stacks that can manage resources across any spaces, even when not in the same branch.
You can assign multiple roles to a single entity within the same space.
To use custom roles, your role must have at least the Read system role as a minimum permissions baseline.
You can also leverage the Write system role as a baseline and add other permissions as well, if you need something that is more powerful than Write, but less powerful than Admin.
NOTE: The Administrative flag behavior in the stack settings is now officially deprecated in favor of the new Stack Roles settings, and will be removed by June 1, 2026.
To read more about Stack Roles, check out the documentation here!