Skip to main content

Stack Activator Sets Stack State

Feature Requests

The stack_activator resource can be used to disable a stack. This is helpful if I’m inferring the creation of many stacks from an input config to an admin stack, but some subset of those need to be disabled. If a new stack is disabled it stays in the None state, but if a stack is in another state and is then disabled, its state stays that way. If the stack was in an undesirable state like Discarded or Failed, that stack will show up elsewhere when trying to surface stacks in a bad state. It would be great if:

  • The stack activator resource could set the stack state

  • OR, it put the stack in a new Disabled state

I’m considering this to be an important feature. A primary benefit to using Spacelift is the automation it provides around “vanilla” terraform workflows. Some of this automation would greatly benefit from the above feature.

Workaround
Problem
See above
Status: ❌ Rejected3 comments

Log in to comment and vote

Comments3

  • Jonah Kowall

    Team•

    Sep 5

    Closing this — stack state is intentionally a byproduct of the last tracked run, not something we want to set through stack_activator (or by inventing a separate Disabled state). Demand has also stayed low.

    If the real pain is disabled stacks still showing up when you look for Failed/Discarded, that’s a filtering/views problem rather than mutating state. Feel free to open a more focused ask there if that’s still biting you.

  • Jade Clay

    •

    Oct 2, 2025

    I’d like to be able to:

    1. Use stack state to surface stacks that need attention

    2. Disable stacks that aren’t ready to be or shouldn’t be built

    3. Avoid surfacing stacks from 2. when I look at stack state in 1.

    This is a non-issue if I disable a stack while it does not have a stack state (the stack has never been run), but if the stack is triggered by a code change before the stack_activator resource is used to disable it, its state will reflect that run, whether it is in a Failed or Discarded state.

    There is a workaround, where I could point stacks in 2. to terraform source code that does not produce any infrastructure, execute those stacks, then disable them when they are in a Finished state, but in my use-case there are many stacks, making this cumbersome.

    A common path that leads to this is:

    • Multiple stacks are created that use the same terraform code, e.g. per environment

    • Some environments may not be used immediately, e.g. production when the stacks’ terraform code is being worked on in development

    • It is convenient, or even preferred, to disable stacks until they are in use

    • One might fail to disable the stacks before a tracked run puts the stack in a state that would suggest the stack needs attention

    All of that being said, it might be that I’d like:

    • To be able to manually trigger a disabled stack, and for that to lead to a tracked run that does not perform “normal” operations, and leaves the stack in a finished state

  • Black Breeze

    •

    Oct 2, 2025

    Stack state is merely a byproduct of tracked runs executing on the stack, it’s nothing you can or even want to manipulate manually. Can you please elaborate what is that you’re trying to accomplish that requires manual control over what’s effectively just a reflection of the effect of the last tracked run?