Create a VM and Register It as a Kestra Asset

Turn VM provisioning into a governed, catalog-aware operation. This blueprint provisions a virtual machine and registers it as a typed io.kestra.plugin.ee.assets.VM asset in the Kestra asset catalog, capturing OS, region, and runtime status as metadata. It is the foundation flow of an asset-driven infrastructure suite: every downstream operation, such as assigning an IP, installing software, taking a snapshot, or onboarding a user, can declare this VM as an input asset, which gives you an automatic dependency and lineage graph for your whole fleet.

How it works

1. The vm_name input (default windows-web-01) names the machine to create.
2. The gcp_create_instance task simulates the provisioning call with io.kestra.plugin.core.log.Log. In production you replace it with your real provisioning task, for example io.kestra.plugin.gcp.cli.GCloudCLI running gcloud compute instances create, a Terraform apply, or an Ansible playbook.
3. The same task declares an assets.outputs entry: the VM is registered under the slugified name ({{ inputs.vm_name | slugify }}) with type io.kestra.plugin.ee.assets.VM and metadata for os, region, status, and name.
4. From that point on the VM exists in the asset catalog, and any flow can reference it with assets.inputs or query it with the assets() Pebble function.

What you get

• A cataloged VM asset per provisioned machine, discoverable in the Kestra UI.
• Metadata (os, region, status) that downstream flows can filter on with assets(metadata={...}).
• The root node of a lineage graph that grows as IPs, certificates, snapshots, and users attach to the VM.
• A minimal, copyable pattern for making any provisioning task asset-aware.

Who it's for

• Platform and infrastructure engineers building a source of truth for their VM fleet.
• SRE and IT operations teams that need dependency tracking between machines and the workflows that touch them.
• Teams evaluating Kestra Assets who want the simplest possible starting point.

Why orchestrate this with Kestra

Cloud consoles and IaC tools create VMs, but they do not record which workflows depend on each machine or what was installed, attached, or snapshotted afterward. Kestra Assets turn every resource into a typed catalog entry with metadata and lineage. Combined with declarative YAML, triggers, retries, and full execution history, you get a living CMDB that updates itself as flows run instead of a spreadsheet that drifts out of date.

Prerequisites

• A Kestra Enterprise Edition instance (Assets are an EE feature).
• A real provisioning mechanism (cloud CLI, Terraform, Ansible) to swap in for the stub task.

Secrets

• None required by the stub. Add your cloud credentials, for example GCP_SERVICE_ACCOUNT, as secrets when you wire in a real provisioning task.

Quick start

1. Import this blueprint into your namespace.
2. Execute it with a vm_name of your choice.
3. Open the Assets view in the Kestra UI and find the new VM asset with its metadata.
4. Run companion flows such as asset-assign-external-ip or asset-vm-snapshot against the same VM and watch the lineage graph grow.

How to extend

• Replace the Log stub with io.kestra.plugin.gcp.cli.GCloudCLI, io.kestra.plugin.aws.cli.AwsCLI, or a Terraform task that actually creates the instance.
• Add more metadata such as owner, cost center, or machine type to power richer assets() queries.
• Trigger the flow from a webhook so an ITSM tool or self-service portal can request VMs.
• Chain a Subflow task to install baseline software right after registration.

Links

• Kestra Assets documentation: https://kestra.io/docs/enterprise/governance/assets
• Core plugin docs: https://kestra.io/plugins/core