Skip to main content

GitOps driven Tofu plan, apply, iterate

Feature Requests

To avoid having too many tools our developers need to focus on we would like to have a full GitOps driven Spacelift process. With merging of a PR when all changes are applied for the given stack(s) the PR refers to.

And being able to iterate on a PR to reach the desired end result before merging it.

There also needs to be a mechanism to avoid multiple PRs applying changes to the same stack at the same time, to avoid changes being inadvertently reverted.

Workaround
Problem
Status: ❌ Rejected2 comments

Log in to comment and vote

Comments2

  • Jonah Kowall

    Team•

    Jul 12

    Thanks for the suggestion. The loop described here is largely what proposed runs plus tracked runs with autodeploy already provide: plans on every PR, apply on merge, iterate: https://docs.spacelift.io/concepts/run/proposed. Since this hasn’t gathered further definition or votes, I’m closing it. If there’s a specific gap versus your GitOps expectations, a fresh, focused request would help us act on it.

  • Black Breeze

    •

    May 8, 2025

    Thanks for raising this. We want to better understand what a “GitOps-driven process” would solve for your team—especially since parts of this (like PR-based runs, promotion, iteration) are already supported today.

    A few questions that would help us shape this:

    • What exactly goes wrong today when developers use PRs to propose infrastructure changes?

    • What’s the “gotcha” moment—the part people trip over or forget?

    • What does success look like for your team? Is it fewer tools, less clicking, stronger guarantees, better visibility…?

    Also: can you describe a recent example where two PRs hit the same stack and things broke or got confusing?

    We’re not trying to validate a feature—we’re trying to solve a real pain. That’s where we can help best.