Skip to main content

Nested Maps Support in Blueprints (for regional variations in user tiers)

Feature Requests

As a stack author, I want to define map-of-maps in Blueprint inputs so that I can model region → user tier → settings without duplicating large structures.

Why this matters: Today the map type is effectively flat. Real-world setups vary by region and tier. Without nesting, we copy-paste blocks and drift creeps in.

Status: 🔭 Discovery8 comments

Log in to comment and vote

Comments8

  • Black Breeze

    •

    Sep 12, 2025

    Hey all, I’m grouping various requests about smarter, more powerful blueprints. We’re now revisiting some of our assumptions and thinking about what the future for blueprints and self-service more generally may look like over here at Spacelift.

    What’s common behind all these requests is that they’re all reasonable, and all difficult if not impossible to solve cleanly without a substantial change to the core design. Which is something we’re now considering.

    Please bear with us. It may not come tomorrow, but it’s going to be AWESOME.

  • Beige Cascade

    •

    Sep 12, 2025

    •

    Merged request

    •

    5 votes

    Ability to propagate changes from Blueprints + support dynamic templating per stack

    We're managing a multi-tenant infrastructure with 40+ stacks generated from Blueprints. While blueprints are a great starting point, the current model becomes difficult to scale as we grow.

    Once a stack is created, it's disconnected from the Blueprint — so if we need to update something across all stacks (like add a config flag or a new file), we have to do it manually or build internal tooling to handle it. This is both time-consuming and error-prone. What would be helpful:

    1. Blueprint-linking after creation

      • The ability to apply changes from the Blueprint to existing stacks when needed is like syncing changes downstream.

    2. Templating system for dynamic config

      • We'd love to be able to define shared files (like a config file) in the Blueprint and inject stack-specific values dynamically, maybe via a map (e.g. stack ID → values).

    This would help us keep stack behaviour consistent while still supporting tenant-specific differences.

    Why this matters:

    We're growing quickly, and the manual effort to maintain stack configurations is already a burden. The more tenants we onboard, the harder it becomes to keep everything in sync, which slows us down and increases the risk of errors. Having more tooling here would make Spacelift even more powerful for teams like ours who are scaling infrastructure as a platform.

    • Natalia Gazda

      Team•

      Jul 11, 2025

      Hi @Stefano Zanella , thanks for raising this! We’re currently re-evaluating how we approach self-service workflows, we may introduce something far superior to blueprints altogether. Because of that, we’re not planning major updates to the current Blueprints model right now.

      Once we decide whether to move forward with the new direction, I’ll make sure to follow up. If we end up not pursuing it, we may revisit enhancements like this.

      In the meantime, I’ll leave this in ⬆️ Gathering votes so we can gauge broader interest from other customers. Appreciate you sharing the use case!

  • Purple Kangaroo

    •

    Sep 12, 2025

    •

    Merged request

    •

    3 votes

    Blueprint Inputs: Dependent (Cascading) Selects

    As a platform engineer, I want Blueprint input options to dynamically depend on other input values so that end users only see valid combinations (and don’t need to know internal constraints).

    Context: We’re standardizing self-service patterns and want safer, faster stack creation.

    Problem today: Input options are static. If I choose Runtime = Python, I still see Node versions. This leads to invalid selections, retries, and refactors.

    • Blue Orbit

      •

      Sep 12, 2025

      •

      Merged request

      •

      1 vote

      Dynamically Populate Blueprint Selection Options

      I would like the ability for a Blueprint to dynamically populate an input selection dropdown. This would allow us to populate the dropdown selection with options such as all Spacelift Spaces in the account.

      What I’m trying to achieve is being able to populate all Space ID’s as options to select.

      Current Set Up
      If there is a new Space (e.g., team-c-space)created after the Blueprint is published you currently have to create a new Blueprint, manually update the Blueprint with the Space ID, and publish it. This adds a non-trivial amount of work so that Blueprints are up-to-date with items like Space ID’s and IdP teams. 

      inputs:
  - id: space_id
    name: What Space Should The Stack Be Stored In
    type: select
    options:
      - team-a-space-12345678910
      - team-b-space-12345678910

      Ideal Set Up

      inputs: 
  - id: space_id 
    name: What Space Should The Stack Be Stored In 
    type: select 
    options: 
      - ${{ spacelift.space_ids }}

      • Natalia Gazda

        Team•

        Aug 6, 2025

        Thanks @Steve Christian for submitting that! I totally understand why you’re in need for that. We are currently researching a bit different concept to blueprints for service. Something that would be far superior than that, so all blueprints updates are a bit on pause. I will get back to that once we have a decision there and revisit.