Create icon
Create icon
AssignIpAddress icon
Create icon
Webhook icon

Provision a VM and Register It in NetBox

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.

Categories
Infrastructure

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.

How it works

  1. A 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

What you get

  • A running Proxmox VE VM created from a single request.
  • A NetBox device record created in the correct site, type, and role.
  • The next free IP automatically allocated from a prefix, with a DNS name.
  • An owning contact assigned so accountability is captured from day one.
  • A repeatable, auditable provisioning path instead of manual clicks.

Who it's for

  • Platform and infrastructure engineers standardizing VM provisioning.
  • NetOps teams keeping NetBox accurate as the network source of truth.
  • Self-service and ITSM owners wiring portal requests to real provisioning.

Why orchestrate this with Kestra

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.

Prerequisites

  • A reachable Proxmox VE cluster with a free vm_id and a node to place the VM on.
  • A NetBox instance with an existing device type slug, device role slug, site slug, a prefix to allocate from, and a contact plus contact role.

Secrets

  • 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.

Quick start

  1. Set the secrets above in your Kestra namespace.
  2. Create the NetBox prefix, contact, and contact role, and note their IDs.
  3. POST to the webhook (or run manually) with vm_name, vm_id, prefix_id, contact_id, and contact_role_id.
  4. Confirm the VM in Proxmox VE and the device, IP, and contact assignment in NetBox.

How to extend

  • Tune cores, memory, and disk on provision_vm or read them from inputs for per-request sizing.
  • Swap the prefix allocation for an explicit address on AssignIpAddress if you prefer fixed IPs.
  • Add a notification task (Slack, email) to confirm provisioning back to the requester.
  • Add cleanup or rollback logic on errors so a failed NetBox step does not leave an orphaned VM.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.