Workflow
Workflows are automated execution plans that orchestrate the provisioning of multiple resources in the correct dependency order. Workflows are created from Blueprints and handle the complexity of wiring outputs from one resource into the inputs of another.
Workflows are the orchestration layer in your infrastructure kitchen — they take a Blueprint’s definition of what needs to be built and execute it step-by-step, resolving dependencies, passing outputs between resources, and tracking progress throughout the process.
A workflow combines:
- Steps (ordered list of resource provisioning tasks)
- Wiring Snapshot (captured dependency rules from the blueprint)
- Variable Overrides (runtime customizations per template)
- Integrations (cloud credentials shared across all steps)
- Secrets (sensitive data shared across all steps)
- Storage (backend for Terraform/OpenTofu state)
Once executed, workflows provision resources in topological order — ensuring that upstream resources are created before downstream resources that depend on their outputs.
Workflow Lifecycle
Workflows move through these stages: Create → Execute → Complete/Error.
Statuses: pending, in_progress, done, error
Each workflow step also maintains its own status, allowing granular tracking of multi-resource provisioning.
Workflow Properties
Each workflow in InfraKitchen contains the following core properties:
| Property | Description | Notes |
|---|---|---|
| ID | Unique identifier for the workflow | Auto-generated UUID |
| Status | Current execution status | pending, in_progress, done, error |
| Error Message | Description of failure if status is error |
Only present on failure |
| Steps | Ordered list of provisioning tasks | One per template in the blueprint |
| Wiring Snapshot | Copy of blueprint wiring rules at execution time | Immutable after creation |
| Variable Overrides | Runtime variable customizations per template | Merged with blueprint defaults |
| Creator | User who triggered the execution | Used for permissions and audit |
| Started At | Timestamp when execution began | Set when first step starts |
| Completed At | Timestamp when execution finished | Set on success or failure |
| Created At | Timestamp when the workflow was created | Set on creation |
Workflow Step Properties
Each step within a workflow tracks the provisioning of a single resource:
| Property | Description | Notes |
|---|---|---|
| ID | Unique identifier for the step | Auto-generated UUID |
| Template | The template this step provisions | From the blueprint’s template list |
| Resource | The resource created by this step | Populated after successful provisioning |
| Position | Execution order (BFS level) | Steps at the same level can run in parallel |
| Status | Current step status | pending, in_progress, done, error |
| Error Message | Description of failure if step errored | Only present on failure |
| Resolved Variables | Final merged variables for this step | Defaults + wired outputs + overrides |
| Parent Resources | Resources that this step depends on | From template hierarchy or overrides |
| Cloud Integrations | Cloud provider credentials for this step | Shared from workflow request |
| Secrets | Sensitive data for this step | Shared from workflow request |
| Template Version | Specific code version for this step | Can be overridden per template |
| Storage | Backend for Terraform/OpenTofu state | Shared from workflow request |
| Started At | Timestamp when step execution began | Set when step starts |
| Completed At | Timestamp when step execution finished | Set on success or failure |
Creating Workflows
Workflows are created by executing a Blueprint. The system automatically resolves the dependency order and prepares each step.
Creation Flow
Execute
Open a Blueprint and click Execute.
Optionally configure runtime overrides
- Variable overrides per template
- Template version overrides per template
- Parent resource overrides for templates with external parents
Select shared execution context
- Cloud integration(s)
- Secrets
- Storage backend for state management
Create Execution
Click Create Execution.
The system then:
- Resolves dependencies via topological sort of the blueprint’s wiring rules
- Merges variables for each step (blueprint defaults → wired outputs → runtime overrides)
- Creates the workflow with steps in the computed execution order
- Links the workflow to the originating blueprint
Managing Workflows
Workflows support lifecycle actions based on their current state.
| Action | When Available | Description |
|---|---|---|
| Execute | Status: pending |
Start processing the workflow steps |
| Delete | Any status | Permanently remove the workflow and its steps |
Execution Process
When a workflow is executed, the system processes steps in order:
- Pick the next pending step (respecting position/level order)
- Resolve wired variables from completed upstream steps
- Create a resource using the step’s template and resolved variables
- Mark the step as done and record the created resource
- Repeat until all steps are complete or a step fails
Steps at the same position level can execute in parallel, as they have no dependencies on each other.
Wiring and Dependencies
Wiring rules define how outputs from one template’s resource feed into the inputs of another template’s resource. The rules are defined on the Blueprint and captured as an immutable snapshot when the workflow is created.
For example, a blueprint wiring a VPC into EKS and RDS templates produces the following execution order:
Level 0: VPC Template (no dependencies)
Level 1: EKS Cluster Template, RDS Database Template (both depend on VPC)The VPC is provisioned first. Once complete, its vpc_id and private_subnet_ids outputs are automatically wired into the EKS and RDS steps, which can then execute in parallel.
Workflow Status Tracking
Workflows provide real-time visibility into the provisioning process.
Workflow-Level Status
| Status | Description |
|---|---|
pending |
Workflow created but execution not yet started |
in_progress |
One or more steps are currently executing |
done |
All steps completed successfully |
error |
One or more steps failed during execution |
Step-Level Status
| Status | Description |
|---|---|
pending |
Step is waiting to be executed |
in_progress |
Step is currently provisioning a resource |
done |
Step completed successfully, resource created |
error |
Step failed, error message available |
Workflow Permissions
Workflow actions are controlled by role-based access control:
| Action | Permission Required |
|---|---|
| View | Read access |
| Execute | Write access |
| Delete | Admin access |
Workflows vs Direct Resource Creation
Executing a workflow and creating a resource directly are both valid — the difference is orchestration:
- ✅ Use a Workflow (via a Blueprint): “I need to provision a VPC, EKS cluster, and RDS database with automatic wiring” — dependency order, output passing, and parallel steps are computed for you.
- ✅ Use Direct Resource Creation: “I need to create a single S3 bucket” — no wiring, no orchestration overhead.
Note that workflows provide no automatic rollback: resources created by completed steps remain provisioned and are managed individually.
For how Workflows relate to Templates and Executors, see the comparison table on the Blueprint page.
Best Practices
For blueprint design and variable management, see Blueprint — Best Practices.
Execution
- Review resolved variables before executing a workflow
- Start with non-production environments to validate wiring
- Monitor step-by-step progress during execution
- Check step error messages immediately if a workflow fails
Error Recovery
- If a step fails, investigate the error message and fix the root cause
- Re-execute the workflow — completed steps with existing resources will be skipped
- Individual resources created by completed steps can be managed independently
- Use the resource detail page to inspect outputs and state of completed steps