New to Kestra?
Use blueprints to kickstart your first workflows.
Provision a Proxmox VE VM via webhook and register it in NetBox with Kestra, allocating an IP, device record, and owning contact in one flow.
Automate end-to-end VM provisioning and IPAM source-of-truth registration. This blueprint turns an inbound provisioning request into a fully documented infrastructure asset: it creates and powers on a Proxmox VE virtual machine, then updates NetBox in lockstep so the device record, an allocated IP address, and an owning contact all exist the moment the VM does. It closes the gap between spinning up compute and keeping your network source of truth accurate, eliminating the manual NetBox data entry and stale records that follow ad-hoc provisioning.
io.kestra.plugin.core.trigger.Webhook trigger (provision_request) fires the flow when an ITSM system or self-service portal POSTs a provisioning request, guarded by a secret webhook key.provision_vm (io.kestra.plugin.proxmox.vm.Create) creates and powers on the VM on Proxmox VE with 2 cores, 4096 MB memory, and a local-lvm:32 disk, using the supplied vm_id and vm_name.register_device (io.kestra.plugin.ee.netbox.device.Create) creates the NetBox device record with the given device_type, device_role, and site, set to status: active.allocate_ip (io.kestra.plugin.ee.netbox.ipam.AssignIpAddress) allocates the next available IP from prefix_id and sets its dnsName to the VM name.assign_contact (io.kestra.plugin.ee.netbox.contactassignment.Create) attaches the owning contact to the new device, referencing {{ outputs.register_device.id }} as a primary contact assignment on dcim.device.Proxmox and NetBox each have their own API, but neither orchestrates the cross-system workflow that ties a new VM to its IPAM record and owner. Kestra coordinates the whole sequence as declarative YAML: event-driven webhook triggers start provisioning the instant a request lands, task outputs flow downstream (the device ID feeds both the IP allocation and contact assignment) to give you lineage across systems, and built-in retries plus full execution history make every provisioning run observable and replayable. This is the multi-tool, request-driven flow that neither tool's own scheduler can express.
vm_id and a node to place the VM on.PROXMOX_HOST, PROXMOX_NODE, PROXMOX_USERNAME, PROXMOX_PASSWORD: Proxmox VE connection details.NETBOX_URL, NETBOX_API_TOKEN: NetBox base URL and API token.NETBOX_PROVISION_WEBHOOK_KEY: webhook key that guards the trigger.vm_name, vm_id, prefix_id, contact_id, and contact_role_id.cores, memory, and disk on provision_vm or read them from inputs for per-request sizing.AssignIpAddress if you prefer fixed IPs.errors so a failed NetBox step does not leave an orphaned VM.