Skip to main content

Hierarchical Spacelift Config

Feature Requests

Currently, stacks require the .spacelift/config.yml to be present at the root of a multi-root repository.


I would like to not have to trigger other stacks when the .spacelift/config.yml changes for a specific stack, but there is no way to tell what changes were made to the file (we can only tell that the file itself was changed). The closest thing that we currently have is repository_runtime_config_changed, which is still undocumented but nevertheless a feature of approval policies.

I would propse that one of two things happen (or both):

  1. repository_runtime_config_changed is implemented as a field in the data passed to push policies

  2. .spacelift/config.yml can be specified in an hierarchical manner, meaning a specific project root could have its own project-root/.spacelift/config.yml (which could furthermore be merged with the root .spacelift/config.yml so that defaults could be specified at the repo-level, as an example).

Workaround
no
Problem
Status: 🗑️ Archived4 comments

Log in to comment and vote

Comments4

  • Natalia Gazda

    Team•

    Jul 16

    Hey, thanks for the suggestion. We're archiving this one for now. It hasn't picked up much interest since it went up, so it isn't on our near-term roadmap. Archiving isn't deleting: the request stays on record, and if it gathers more votes or comments we can bring it back. If it still matters to you, add a vote or a comment so we can gauge the demand.

  • Natalia Gazda

    Team•

    Aug 6, 2025

    Hi Zach,

    Thanks for sharing this feedback about runtime configuration in multi-root repositories. I can see how changes to the shared .spacelift/config.yml file triggering all stacks can be problematic.

    Regarding hierarchical config files - while I understand the appeal, this would add significant complexity to how Spacelift resolves configuration. The current design with a single config file at the repository root is intentional, as it provides a clear, auditable source of truth for all stack configurations.

    Have you considered using Spacelift's Terraform provider to manage stack-specific settings programmatically? This might give you the flexibility you need without fragmenting your configuration across multiple files.

    I'd also be curious to understand more about your specific scenario - how many stacks are typically affected by these config changes, and what types of settings are you modifying that only apply to specific stacks?

    • Indigo Stew

      •

      Aug 6, 2025

      We are using Spacelift’s provider to manage Spacelift. Changing stack settings through the API affects the entire stack (proposed, tracked, tasks), while changes in the .spacelift/config.yml can be tested through the PR process.

      My other two suggestions still would fit the need, either allowing project-root specific .spacelift/config.yml that take priority, or adding the repository_runtime_config_changed attribute to push events.

      • Natalia Gazda

        Team•

        May 4

        Hi Zach,

        First off - I owe you a real apology for the long silence here. Nine months without a follow-up isn't okay, and I'm sorry to have left you hanging.

        Your points are fair. Managing stack settings through the Terraform provider does have a different trade-off profile than .spacelift/config.yml, especially around being able to test changes through the PR process.

        I want to be straight with you, though: this isn't on our near-term roadmap. We're focused on other priorities right now, and I'd rather be upfront than leave you waiting on something that isn't coming soon.