Skip to main content

Support a single plan plus approve plus apply flow without re planning.

Feature Requests

For every change, users currently experience two plans. one for the plan, one for the apply. For long running plans or repeated changes across many stacks this makes Spacelift feel noticeably slower than terraform apply or terragrunt apply. This friction nudges engineers back to local CLI usage even though Spacelift is available and preferred from a control and visibility perspective.

Status: ⬆️ Gathering votes2 comments

Log in to comment and vote

Comments2

  • Black Breeze

    •

    Nov 27, 2025

    Thanks for this feedback about the dual planning workflow. I understand the performance frustration, especially with long-running plans across multiple stacks.

    The current approach of planning twice is intentional - it ensures that the plan you're approving reflects the absolute latest state and configuration. This prevents issues where infrastructure changes between your initial plan and when you actually apply it.

    However, I recognize the performance impact you're describing. Have you considered these approaches to improve speed:

    1. Stack Decomposition: Breaking large stacks into smaller, focused ones reduces individual plan times and enables better parallelism


    2. Targeted Replans: Use the targeted replan feature to only plan specific resources when making focused changes


    3. Plan Optimization: Review your Terraform configuration for expensive data sources or inefficient resource dependencies

    We're always looking at ways to optimize performance while maintaining safety. Would any of these approaches help with your specific use case? I'd also be interested to hear more about your typical stack sizes and what's driving the long plan times.

    • Teal Mongoose

      •

      Dec 1, 2025

      Thank you @Marcin Wyszynski for the reply & those suggestions to improve performance.

      For us, our largest stack size has nearly 293 resources in it, with a plan runtime of just over 2 minutes. It is definitely a candidate for splitting up and/or optimising. Our average resource size is 15 however so this is an outlier.

      So for my DevOps team, any change to that big stack would take ~2 mins if run locally, or >4 minutes if I run in Spacelift. For other stacks it’s roughly a 1 minute local vs 2 minutes with Spacelift. That decision creates a disincentive for my team to use Spacelift.

      It would be nice to know the median / average run duration across all our stacks to give you a better figure but the Spacelift dashboard for median / average run duration includes drift detection times which are often queued. That skews our runtime metrics in the dashboard so it’s not easy to see how long things take across our 930 stacks (removing drift runs from the median/average runtime metrics is another suggestion I made to our customer rep however).

      We will look to the suggestions above however and see what can be done.