Skip to main content

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.

4 comments

This request was merged into another request

Comments4

  • 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.

  • Purple Kangaroo

    •

    Sep 12, 2025

    •

    Merged request

    •

    1 vote

    Dynamic Blueprint Inputs

    Create dynamic input option. I know maps are available to partially solve this problem but the documentation specifically calls out that maps cannot be used in the input section and vice versa.

    For example, if I am provisioning an Azure function app, I can set the runtime in the blueprint. I can create an option field that allows the user to pick "Python - 3.12", "Python - 3.11", "Node - 22", "Node - 20", etc... I also have an option to choose "Docker", however,  I also then want to allow the user to pass a particular image name and tag that cannot be anticipated and included as a dropdown option. Is there a way to make a text field visible to accept user input only if the user has select "Docker" as the run time? Or even more simply, if I choose Python as the runtime, dynamically set the version drop down to 3.12, 3.11, 3.10 vs if I choose Node as the runtime, the version drop down sets to 22, 20, 18.

    • Black Breeze

      •

      May 29, 2025

      Thanks for the request! A few questions to help us understand better: **What's driving this need?** - Are you trying to reduce the number of blueprints you maintain? - Is this about making it easier for non-technical users? - Something else? **How are you solving this today?** - Do you have separate blueprints for each runtime? - Are users confused by too many options? **What would success look like?** - Fewer support requests from users? - Faster time to provision? - Less blueprint maintenance? **One thing to consider:** Instead of dynamic inputs, would a blueprint 'wizard' that helps users find the right pre-built blueprint solve the same problem? That way all logic stays in code (reviewable, testable) but users still get a guided experience.