Skip to main content

Make Stack vendor version constraints more flexible

Feature RequestsStacksUI/UXOpenTofu

Currently you can define the used version for HashiCorp Terraform / OpenTofu in your Stack configuration with SemVer. This works fine if you are managing your Stack through .spacelift/config.yml in the same repository, but if you manage your Stacks through the Terraform provider you end up with difficulties testing:

  1. Update the used version in the parent Stack

  2. Test the newly used version in the child Stack

  3. If good, merge 1 and 2.

Ideally the version constraint field would work similar to tenv where you would only need to specify the used tooling (HashiCorp Terraform vs OpenTofu) and it would pick the required version based on your code.

Workaround
Status: ❌ Rejected2 comments

Log in to comment and vote

Comments2

  • Jonah Kowall

    Team•

    Jul 12

    Thanks for the request. Spacelift already supports version ranges and constraints for Terraform/OpenTofu per stack: https://docs.spacelift.io/vendors/terraform/version-management. The additional flexibility asked for here hasn’t gathered further interest, so I’m closing this. If the current constraint syntax blocks a real workflow, comment with the exact constraint you need and we’ll revisit.

  • Black Breeze

    •

    May 10, 2025

    Thanks for the suggestion! We’d love to understand the underlying problem better.

    Right now, you can use open-ended version constraints in your stack config or YAML files—for example, specifying >= 1.3.0 for a vendor version. You mentioned something like tenv that would automagically figure out the right version. That sounds promising—but we’d love to dig deeper.

    Could you share a bit more about the job you’re trying to get done?

    • What breaks down or feels frustrating with the current setup?

    • Are you trying to align versions across stacks? Match local tooling to Spacelift’s behavior?

    • What would success look like if this worked perfectly?

    Understanding the trigger and the progress you’re trying to make will help us think about the right solution—whether it’s config simplification, a smarter default, or something else entirely.