Multi-Cloud VM Inventory Updates in the Kestra KV Store

Every provisioning pipeline needs somewhere to record what it built. This blueprint keeps a lightweight, multi-cloud VM inventory directly in the Kestra KV store: a single vmInventory JSON document with one section per provider (gcp, aws, azure, vcf), each mapping hostnames to arbitrary property objects. Call it as a subflow at the end of any provisioning workflow, passing the hostname, the provider, and whatever metadata you want to keep, and the record is merged in without disturbing the rest of the inventory.

How it works

1. The getVMInventory task (io.kestra.plugin.core.kv.Get with errorOnMissing: false) loads the current vmInventory document, tolerating a first run where it does not exist yet.
2. The prepareInventory task (io.kestra.plugin.scripts.python.Script) starts from the stored value or an empty per-cloud skeleton via the Pebble coalesce {{ outputs.getVMInventory.value ?? {...} }}, indexes into the section for {{ inputs.cloudProvider | lower }}, upserts the hostname entry with the vmProps JSON, and emits the merged document with Kestra.outputs.
3. The updateVMInventory task (io.kestra.plugin.core.kv.Set with kvType: JSON) writes the merged inventory back under the same key.
4. The three steps are wrapped in a io.kestra.plugin.core.flow.Sequential container, making the read-merge-write unit easy to lift into larger flows.

What you get

• A zero-infrastructure inventory: no database, no CMDB license, just the KV store.
• Free-form per-VM metadata (vmProps is any JSON object) with per-provider organization.
• Upsert semantics: re-registering a hostname updates its record in place.
• A subflow-shaped building block for provisioning and decommissioning pipelines.

Who it's for

• Teams starting with infrastructure automation before adopting a full CMDB.
• Platform engineers who want provisioning flows to leave a queryable record.
• Demo and lab environments where VM sprawl needs cheap tracking.

Why orchestrate this with Kestra

The inventory lives where the automation lives. Any flow can read kv('vmInventory') in an expression to render dashboards, build Ansible inventories, or drive cleanup jobs, and every mutation is an execution with logs showing exactly which flow added which host. When you outgrow it, swap the KV tasks for database or CMDB API calls without touching the calling flows.

Prerequisites

• A Kestra instance with the KV store available in the target namespace.
• Provisioning flows that can call this flow via io.kestra.plugin.core.flow.Subflow (or run it manually).

Secrets

• None. The flow only touches the namespace KV store.

Quick start

1. Execute the flow with the default inputs to create the vmInventory document.
2. Check the KV store in the Kestra UI to see the merged JSON.
3. Call it from your provisioning flow as a subflow, passing hostname, cloudProvider, and vmProps.
4. Read the inventory anywhere with {{ kv('vmInventory') }}.

How to extend

• Add a remove action input that deletes a hostname entry for decommissioning flows.
• Render an Ansible inventory.ini from the KV document for configuration runs.
• Post a Slack digest of inventory changes with io.kestra.plugin.notifications.slack.SlackIncomingWebhook.
• Replace the KV backend with Postgres or ServiceNow CMDB calls once the fleet grows.

Links

• KV store docs: https://kestra.io/docs/concepts/kv-store
• Python script plugin docs: https://kestra.io/plugins/plugin-script-python