Install Software on a VM and Track It as an Asset

"What version of nginx is running on that box?" is a question that usually ends in an SSH session. This blueprint installs software on an existing virtual machine and registers the installation as a typed io.kestra.plugin.ee.assets.VM.Ingress asset in the Kestra asset catalog, recording the version and the host it landed on. The VM is declared as an input asset, so the catalog builds a lineage edge from machine to installed component, and fleet-wide questions become metadata queries instead of shell archaeology.

How it works

1. The target_vm input names an existing VM (default windows-web-01).
2. The choco_install_nginx task simulates choco install nginx -y with io.kestra.plugin.core.log.Log. In production you replace it with a remote execution task, for example an SSH command via io.kestra.plugin.fs.ssh.Command or a PowerShell script via io.kestra.plugin.scripts.powershell.Script.
3. The task declares the VM as an assets.inputs entry using its slugified id, creating the dependency edge and requiring the machine to exist in the catalog.
4. It registers the installation as an assets.outputs entry of type io.kestra.plugin.ee.assets.VM.Ingress, keyed nginx-{{ execution.id }}, with metadata for version, installed_on, and component type.

What you get

• A cataloged asset per software installation, with version and host metadata.
• Lineage from VM to installed component, so decommissioning surfaces affected software.
• Queryable install inventory: assets(metadata={"type": "nginx"}) lists every nginx install across the fleet.
• A copyable pattern for making any configuration-management step asset-aware.

Who it's for

• IT operations teams tracking what is installed where across a Windows or Linux fleet.
• Platform engineers building software inventory for vulnerability response.
• Security teams that need to answer "which machines run version X" fast during a CVE scramble.

Why orchestrate this with Kestra

Package managers install software but keep no central inventory; CMDB tools hold inventories that drift because updates happen out of band. Kestra Assets close the loop: the same task that performs the installation registers the result in the catalog, so inventory can never lag behind reality. Declarative YAML, execution history, retries, and the assets() query function make audits and impact analysis first-class operations.

Prerequisites

• A Kestra Enterprise Edition instance (Assets are an EE feature).
• A VM asset already registered, for example by the asset-create-vm blueprint, matching the slugified target_vm value.

Secrets

• None required by the stub. Add SSH keys or WinRM credentials as secrets when you wire in a real remote execution task.

Quick start

1. Run asset-create-vm so the target VM exists in the catalog.
2. Import this blueprint and execute it with the same target_vm.
3. Open the Assets view to see the VM.Ingress asset with its version metadata and lineage.
4. Query assets(type='io.kestra.plugin.ee.assets.VM.Ingress') from another flow to list installations.

How to extend

• Replace the Log stub with io.kestra.plugin.fs.ssh.Command or io.kestra.plugin.scripts.powershell.Script to run the real package manager.
• Parameterize the package name and version as inputs instead of hardcoding nginx.
• Capture the actual installed version from command output and write it into the asset metadata.
• Add a scheduled audit flow that compares installed versions against a minimum baseline and remediates drift.

Links

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