Removing Legacy Policy Types

On May 30, 2026 we’re fully removing three policy types from Spacelift:

• Task Policies
• Initialization Policies
• Stack Access Policies

They’ve been marked deprecated for over a year. At the end of May, they’ll stop having any effect.

We know deprecations are never welcome news, especially when you’ve been using a feature, but I’m writing this post to explain what’s changing, why we’re doing it, and how to move forward.

In New Zealand, there’s a species of reptile called the Tuatara. It’s an evolutionary holdover that scientists love because it gives them a glimpse into evolutionary paths not taken. It survives because it has no natural predators, but it isn’t the most efficient species. It has a third eye that doesn’t really see and it’s the slowest-reproducing reptile on Earth.

Why are we talking about a reptile in a blog about feature deprecation? Well, Stack Access Policies are our Tuatara, and on May 30th, we’re saying goodbye.

For Task and Initialization policies, we introduced Access Policies which do everything they did, but better. If you’re still using Task or Initialization policies, the migration is mostly mechanical. The functionality exists, just in a better place. For more information, see our migration guides.

This one is different. Stack access policies were our earliest attempt at access control. They were attribute-based, flexible, and powerful on paper. In practice, they created problems that compounded as organizations scale. They survived this long because we protected them. Now, we’re removing them, and there isn’t a direct replacement. Here’s why:

They sit on the critical path. Every read request evaluates Stack Access Policies. That makes performance unpredictable and slow in larger accounts. Imagine if every time you opened a door, someone had to consult an oracle first.

They’re impossible to reason about. With attribute-based evaluation, you can’t answer basic questions like “who has access to this stack?” without running the policy against every possible user. Auditors hate this. Compliance teams hate this. Honestly, we hate this.

They only affect stacks. Stack Access Policies don’t cover:

• Spaces
• Contexts
• Policies

They’re like a security guard who only checks IDs at one door while the windows are wide open.

They create ongoing complexity. Every new feature we build has to special-case the legacy space where these policies work. That slows us down and makes it harder to evolve the platform.

Since then, we’ve built a predictable RBAC system with Spaces, Custom Roles, and Stack Roles. Maintaining a parallel, fundamentally different access system no longer makes sense.

There may be edge cases our current RBAC doesn’t handle. We’ve carefully reviewed how these policies are used in practice, and those cases are rare, but we know they exist.

If you’re in that situation, we want to hear from you to understand what we might be missing and where the platform still needs to improve.

Many of you using Stack Access Policies have been with us from the beginning. You helped us learn what worked and what didn’t. Thank you for building with us when the product was younger and weirder. This feature exists because we were figuring things out together, and you trusted us while we did.

Deprecating this isn’t about dismissing that trust, it’s about making Spacelift clearer, faster and more reliable for everyone going forward, including you.

• Now: Creation of new stack access, task, and initialization policies is disabled.
• May 30, 2025: These policies stop having any effect. The tuatara retires to a nice farm upstate.

If you need migration support, or this change affects you and you’re unsure of how to move forward, contact your Customer Success Manager to book dedicated time with our team.