Provision Servers from a Manifest and Register Them as Assets

Fleet provisioning usually ends with machines running and documentation missing. This blueprint iterates over a JSON server manifest, provisions each machine, and registers every one as a typed io.kestra.plugin.ee.assets.VM asset in the Kestra asset catalog with environment, OS, Python version, and IP address metadata. The result is a fleet whose inventory is generated by the provisioning run itself, ready to drive downstream flows such as targeted upgrades or security audits that select servers by metadata.

How it works

1. The server_manifest flow variable holds a JSON array of servers, each with id, ip, os, env, and python_version. Replace it with your real manifest, or load one from a namespace file or an HTTP call.
2. The provision_servers task (io.kestra.plugin.core.flow.ForEach) iterates over the array, one iteration per server.
3. Inside the loop, parse_server_details (io.kestra.plugin.core.execution.SetVariables) parses {{ fromJson(taskrun.value) }} into named variables for readability.
4. terraform_apply (io.kestra.plugin.scripts.shell.Commands on the Process task runner) simulates the provisioning step. Swap the echo commands for a real terraform apply, Ansible playbook, or cloud CLI call.
5. register_asset (io.kestra.plugin.core.debug.Return) declares an assets.outputs entry per server: type io.kestra.plugin.ee.assets.VM, scoped to the flow namespace, with env, os, python_version, and ip_address metadata.
6. The webhook_trigger (io.kestra.plugin.core.trigger.Webhook), secured by PROVISION_WEBHOOK_KEY, lets a CI pipeline such as GitHub Actions start the run whenever the manifest changes.

What you get

• One cataloged VM asset per manifest entry, with rich, queryable metadata.
• A provisioning loop that scales with the manifest, no per-server YAML.
• A CI-friendly webhook entry point for GitOps-style fleet management.
• The inventory foundation for companion flows like asset-upgrade-servers and asset-fleet-security-audit, which select machines with assets(metadata={...}).

Who it's for

• Platform engineers provisioning fleets from declarative manifests.
• DevOps teams that want inventory as a side effect of provisioning, not a separate chore.
• Teams adopting Kestra Assets as their infrastructure source of truth.

Why orchestrate this with Kestra

Terraform and Ansible provision machines but leave inventory to a CMDB that drifts. Kestra runs the provisioning and writes the catalog in the same execution, so the two can never disagree. ForEach gives per-server task runs with isolated logs and retries, the webhook trigger plugs into any CI system, and the asset metadata immediately powers downstream selection queries for upgrades and audits.

Prerequisites

• A Kestra Enterprise Edition instance (Assets are an EE feature).
• A real provisioning mechanism to replace the stubbed shell commands.
• A caller able to POST to the webhook, or run the flow manually.

Secrets

• PROVISION_WEBHOOK_KEY: shared secret guarding the Webhook trigger.

Quick start

1. Add the PROVISION_WEBHOOK_KEY secret to your Kestra instance.
2. Import this blueprint and adjust the server_manifest variable to your fleet.
3. Execute the flow manually or POST to the webhook URL.
4. Open the Assets view and see one VM asset per server with its metadata.

How to extend

• Load the manifest from a namespace file with io.kestra.plugin.core.namespace.DownloadFiles or from Git or S3.
• Replace the echo stub with io.kestra.plugin.terraform.cli.TerraformCLI or an Ansible task.
• Set concurrencyLimit on the ForEach to provision servers in parallel.
• Chain asset-fleet-security-audit with a Flow trigger so every provisioning run is audited immediately.

Links

• Kestra Assets documentation: https://kestra.io/docs/enterprise/governance/assets
• ForEach task docs: https://kestra.io/plugins/core/tasks/flow/io.kestra.plugin.core.flow.foreach