Skip to main content

Ability to "namespace" Context attachments to avoid variable name clashing

Feature RequestsContextsStacks

We’d like to request the ability to optionally specify a namespace prefix when attaching a Context to a Stack. The goal is to avoid variable collisions when multiple Contexts expose similarly named environment variables (e.g. TF_VAR_vpc_id) and need to be consumed simultaneously by a single Stack.

Example Use Case:

We have separate base infrastructure Contexts for environments like prod and staging, each exporting variables like TF_VAR_vpc_id. Most stacks only need one Context, but occasionally a stack needs to consume both environments. A namespace prefix would allow both to coexist without conflict:

  • Attach prod Context with namespace prod → TF_VAR_prod_vpc_id

  • Attach staging Context with namespace stage → TF_VAR_stage_vpc_id

This avoids having to namespace all variables in the base Contexts upfront, which would complicate simpler use cases unnecessarily.

Proposed Behaviour:

Support an optional namespace string on Context attachments that is prepended to all exposed variable names (e.g. TF_VAR_{namespace}_{var}).

Workaround
Status: 🗑️ Archived2 comments

Log in to comment and vote

Comments2

  • 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 7, 2025

    Hey Josh! Thanks for the detailed feature request.

    I understand the use case - you want to avoid variable collisions when a stack needs to consume similar variables from multiple environment-specific Contexts.

    You've already identified the solution we recommend: prefixing variables at the Context level. While this might feel less elegant for single-environment stacks, it has several advantages:

    1. Explicit is better than implicit - anyone reading the Context can immediately see the namespace
    2. No magic transformations - variables are used exactly as defined
    3. Works today - no waiting for new features

    For the occasional stack that needs multiple environments, the current approach keeps things simple and predictable. We've found that architectural patterns requiring multiple environment contexts in a single stack often indicate an opportunity to rethink the separation of concerns.Given that this addresses an edge case with a functional workaround, we're not planning to add namespace prefixing to Context attachments at this time.

    We believe keeping Context behavior simple and predictable better serves the broader user base. Is there something about your specific use case that makes the current approach particularly painful? Understanding more about your workflow might help us suggest alternative patterns that work with Spacelift's existing features.

    Thanks again for taking the time to share this feedback - it helps us understand how teams are using Spacelift at scale!