Blueprint

Blueprints are reusable definitions that combine multiple Templates into a single, executable plan. A Blueprint describes which infrastructure components to provision and how their outputs wire together — turning a multi-resource stack into a one-click operation.

Blueprints are the recipes in your infrastructure kitchen — they define the ingredients (templates), the order of preparation (dependency graph), and the connections between components (wiring rules), so you can reliably reproduce entire environments.

A blueprint combines:

• Templates (ordered list of infrastructure components)
• Wiring Rules (how outputs from one template feed into inputs of another)
• Default Variables (pre-configured values per template)
• Configuration (general settings for the blueprint)
• Labels (tags for organizing and filtering)

When executed, a blueprint creates a Workflow that provisions each resource in the correct dependency order.

Blueprint Lifecycle

Blueprints move through these stages: Create → Enable/Disable → Delete.

Statuses: enabled, disabled

Unlike Resources or Executors, blueprints are configuration entities — they define what to build, not running infrastructure. They can be executed multiple times, each execution creating a new Workflow.

Blueprint Properties

Each blueprint in InfraKitchen contains the following core properties:

Creating Blueprints

Blueprints are created to define repeatable multi-resource infrastructure stacks.

Creation Steps

Wiring Rules

Wiring rules are the core mechanism that makes blueprints powerful. They define how the output of one template’s resource automatically feeds into the input variable of another template’s resource.

Wiring Rule Structure

Each wiring rule contains four fields:

Example

Blueprint: Production Environment
Templates:
  - VPC Template
  - EKS Cluster Template
  - RDS Database Template

Wiring Rules:
  - source: VPC Template.vpc_id → target: EKS Cluster Template.vpc_id
  - source: VPC Template.private_subnet_ids → target: EKS Cluster Template.subnet_ids
  - source: VPC Template.vpc_id → target: RDS Database Template.vpc_id
  - source: VPC Template.database_subnet_ids → target: RDS Database Template.subnet_ids

Dependency Graph

The wiring rules automatically create a directed acyclic graph (DAG) that determines execution order:

Templates with no incoming dependencies execute first. Templates at the same level (no dependencies on each other) can execute in parallel.

Managing Blueprints

Blueprints support lifecycle actions based on their current status.

Executing Blueprints

When a blueprint is executed, the system creates a Workflow that orchestrates resource provisioning.

Execution Options

At execution time, you can customize the workflow with:

What Happens During Execution

1. Topological sort — templates are ordered by their wiring dependencies
2. Variable merge — for each step: blueprint defaults → wired outputs → runtime overrides
3. Workflow creation — a workflow is created with one step per template
4. Blueprint link — the workflow is associated with the originating blueprint
5. Execution — the workflow processes steps in dependency order

Variable Resolution Order

Variables for each step are resolved with this priority (highest wins):

┌─────────────────────────────┐
│  3. Runtime Overrides       │  ← Highest priority
├─────────────────────────────┤
│  2. Wired Outputs           │  ← From completed upstream steps
├─────────────────────────────┤
│  1. Blueprint Defaults      │  ← From blueprint configuration
└─────────────────────────────┘

Blueprint Workflows

Each blueprint execution creates a workflow that can be tracked independently. The blueprint detail page shows all workflows created from it, with their status and step progress.

Workflow Tracking

From a blueprint’s detail page you can:

• View all past and current executions
• See the status of each workflow (pending, in progress, done, error)
• Drill into individual workflows to see step-level progress
• Navigate to resources created by completed steps

Blueprint Permissions

Blueprint actions are controlled by role-based access control:

Blueprints vs Templates vs Executors

Understanding when to use each:

Decision Guide:

• ✅ Use Blueprint: “I need to provision a VPC, EKS, and RDS with automatic output wiring”
• ✅ Use Template: “I need a reusable definition for a VPC that teams can instantiate”
• ✅ Use Executor: “I need to run a one-time database migration”

Best Practices

Blueprint Design

• Keep blueprints focused — one blueprint per logical environment or stack
• Use descriptive names that indicate purpose and scope
• Document the blueprint’s purpose and expected inputs in the description
• Minimize the number of wiring rules — keep the dependency graph shallow

Naming Conventions

Use descriptive names that indicate purpose and scope:

✅ Good:
- production-networking-stack
- eks-with-monitoring
- data-platform-tier

❌ Avoid:
- blueprint-1
- test
- my-stack

Wiring Design

• Wire only the outputs that downstream templates actually need
• Avoid unnecessary transitive dependencies
• Test wiring with a non-production execution first
• Document which outputs each template produces in the template description

Default Variables

• Set default variables for values that are consistent across executions
• Use runtime overrides for environment-specific values (regions, CIDR blocks)
• Document which variables should be overridden at execution time