Spacelift should take terraform plan and pass into terraform apply to ensure it only plans once

Thanks

> What would “safe” look like for you?`

We want to be able to apply the plan that the approver has approved in the MR, we don’t want to have to have another gate in the Spacelift UI (we want autodeploy) as we have a lot of infrastructure and this would be a bit of overhead.

> Where does current behavior create risk, friction, or delay?
Currently the plan posted in the MR is not what is actually applied. The second plan after merge to main is what is applied. However this adds adds the extra risk (for us) in the fact that the first plan which is viewed by the MR approver is not necessarily what is applied to the environment. I understand in a perfect world, our terraform would be perfectly idempotent and we would not have ClickOps in our environments- this is not the case, we are every much relying on Spacelift to help get us to this place but right now we cannot guarantee that between MR being opened and approved and then merged into main and replanned that there will not be manual changes in AWS environment for example or anything else.

> What does a successful, trustable GitOps flow feel like—especially at scale?
Ensuring the plan in the MR which the approver has reviewed and approved is what is actually applied.

I think it could work like this.

1. We have a plan in the PR.

2. When spacelift re-plans, its should compare the 2 plans.

3. IF they are the same, then go ahead and apply.

4. IF they are different, then it should stop, and it should be flagged.

Thanks for raising this—it’s a really important concern.

You’re absolutely right that Spacelift plans twice, and in many ways, that’s a feature, not a flaw. The second plan ensures that the assumptions made during PR review still hold true at the time of apply. Infrastructure may have changed in the meantime—another PR could’ve landed, or someone may have ClickOps-ed something in response to an incident, as you noted.

The messy reality is: environments drift, sometimes on purpose. And blindly trusting a stale plan can be just as dangerous as re-applying unreviewed changes.

That said, if the goal is to make the apply feel as safe and trusted as the plan that was reviewed, maybe the answer isn’t skipping the replan—but making the difference between plans visible. Comparing checksums (or even full diffs) could flag when the apply would do something materially different than what was approved.

Before we jump into solutions, though—can we step back and clarify the job you’re trying to get done here?

• What would “safe” look like for you?

• Where does current behavior create risk, friction, or delay?

• What does a successful, trustable GitOps flow feel like—especially at scale?

Understanding this will help us design something that’s both possible and actually solves the right problem.

Thanks!

So to make sure we’re on the same page:
- you don’t mind planning again (given that there’s a real value to it);
- you’re concerned about the MR plan and the merge plan potentially being different;

Is that correct?