Decommission VMs Selected from the Kestra Assets Catalog

Close the loop on VM lifecycle management. Instead of asking operators to remember instance names, zones, and projects, this blueprint presents a dropdown populated live from the Kestra Assets catalog. Selecting a VM pulls its full metadata (name, size, zone, project, network) from the asset record, Terraform destroys the instance against the same remote state that created it, and the asset is updated to state: deleted so the catalog reflects reality.

How it works

1. The vmAssetId input uses a dynamic expression with the assets() function to list every asset of type io.kestra.plugin.ee.assets.VM, so the operator picks from real, tracked machines.
2. The vmMetadata task (io.kestra.plugin.core.output.OutputValues) fetches the selected asset and exposes its metadata JSON.
3. The destroyVM task (io.kestra.plugin.terraform.cli.TerraformCLI) reconstructs the original configuration from the asset metadata via fromJson(...), runs terraform init against the shared GCS backend with the VM name as the state prefix, then terraform destroy -auto-approve -json.
4. The task's assets block declares the asset as an input (lineage) and writes it back with state: deleted, keeping the catalog authoritative.

What you get

• A decommissioning form that can only target VMs that actually exist in the catalog.
• Terraform destroy driven entirely by asset metadata, no manual parameter copying.
• Asset lineage: the execution is linked to the VM it removed.
• A catalog that distinguishes active from deleted machines.

Who it's for

• Platform teams using Kestra Enterprise Assets as their source of truth for managed VMs.
• Infrastructure engineers who want teardown to be as governed as provisioning.
• FinOps-minded organizations cleaning up unused instances safely.

Why orchestrate this with Kestra

Terraform state alone does not tell you which VMs exist, who created them, or when they were removed. Kestra's asset catalog does: the dropdown is generated from live asset data, the destroy consumes the exact metadata recorded at provisioning time, and the resulting state change is written back with full execution lineage. Add a Pause task and you have a complete, auditable decommissioning process.

Prerequisites

• Kestra Enterprise Edition with the Assets feature enabled.
• VMs previously provisioned by a flow that registered io.kestra.plugin.ee.assets.VM assets with metadata fields vmName, vmSize, zone, billingAccount, osFlavor, network, subnet.
• A GCS bucket holding the Terraform state written at provisioning time (prefix per VM name).

Secrets

• GCP_SERVICE_ACCOUNT_JSON: JSON key of the GCP service account allowed to delete instances and read the state bucket.

Quick start

1. Add the secret above to your Kestra namespace.
2. Replace the backend.tf bucket with your real Terraform state bucket and align main.tf with your provisioning configuration.
3. Execute the flow and pick a VM from the dropdown.
4. Verify in GCP that the instance is gone and in Kestra that the asset shows state: deleted.

How to extend

• Add a io.kestra.plugin.core.flow.Pause approval gate before destroyVM for production assets.
• Notify the VM owner via io.kestra.plugin.notifications.slack.SlackIncomingWebhook after teardown.
• Chain a DNS cleanup playbook with io.kestra.plugin.ansible.cli.AnsibleCLI to remove A and PTR records.
• Schedule a monthly sweep that lists assets older than N days and proposes candidates for decommissioning.

Links

• Kestra Assets docs: https://kestra.io/docs/enterprise/governance/assets
• Terraform plugin docs: https://kestra.io/plugins/plugin-terraform