Trigger Proxmox API operations from cron or any HTTP signal. Drain nodes via live migration, snapshot before patching, verify vzdump backups by restoring to a temp VM, and coordinate VMware-to-Proxmox migrations across the cluster.
Run Proxmox like vCenter without the Broadcom tax: a workflow engine that listens to cron or VM state changes, handles VMware-to-Proxmox migration via the ESXi Import Wizard, snapshot-gated patching, and vzdump restore drills, and chains Proxmox with Ansible, Terraform, and NetBox. Drop the vRA subscription; prove backups restore monthly.
What Kestra wraps around your Proxmox cluster: when actions fire, what gets snapshotted first, who drains a node before maintenance, and where the audit lives. The Proxmox API, the ESXi Import Wizard, and vzdump backups stay where they are.
Native cron, fixed intervals, webhooks, and the vm.Trigger that polls Proxmox and fires when a VM enters or leaves a target status (running, stopped). Stateful change detection means a VM that stays stopped doesn't trigger on every poll, only on the transition. The matching VMs reach the flow as trigger.body.
Use Proxmox VE 9's built-in ESXi Import Wizard through the API: register the source ESXi as storage, stop the VMware VM, drive the import via Kestra, then power on in Proxmox. Pre-flight checks (snapshot consolidation, VM stopped) run as flow steps. The original ESXi VM stays as a rollback target until cutover is verified.
snapshot.Create before patches or risky config changes. snapshot.Rollback reverts on a failed health check. The snapshot name flows forward through the execution, so every change has a documented rollback target. Same flow shape works for QEMU VMs and LXC containers via the resourceType field.
vm.List on the target node, then vm.Migrate (or container.Migrate) each guest to other cluster nodes. WaitForTask polls each UPID until completion. Once the node is empty, run maintenance (kernel upgrade, hardware swap), then optionally migrate selected guests back.
backup.Create with snapshot mode and zstd compression. Periodically, backup.Restore writes a backup archive to a temporary VMID, the flow boots and probes it, then deletes the temp VM. A backup that doesn't restore is not a backup, the drill catches that monthly.
Proxmox is the only mainstream hypervisor that runs QEMU VMs and LXC containers side by side. The plugin exposes both: vm.* tasks for VMs, container.* tasks for LXC. One flow can spin up a Postgres VM, a Pi-hole LXC, and a monitoring LXC in parallel, with the same lifecycle semantics.
Patterns Proxmox teams run in production today. Each one shows the flow end to end, with the real plugin classes in play.
Pre-flight: confirm the VMware VM is stopped and all snapshots consolidated (the most common cause of import failure). Drive the Proxmox ESXi Import via the API, wait for the UPID to complete, then start the VM in Proxmox. The original ESXi VM stays as a rollback target until the post-import health check passes.
The flow refuses to import if the source has unconsolidated snapshots, the failure mode that breaks most imports.
The ESXi VM stays available. If the Proxmox health probe fails, the flow alerts and the ESXi VM is still a valid running copy.
Run the same flow per VM in a ForEach to migrate a wave of guests, with the same gate per cutover.
cluster.ListResources finds all VMs and LXC containers on the target node. A ForEach dispatches each guest to a target node via vm.Migrate or container.Migrate. Live migration when supported, offline when not. WaitForTask polls each UPID until done. Once the node is empty, a Pause task gates the actual maintenance work.
QEMU VMs migrate live without downtime. LXC containers migrate with a brief pause (restart on target).
WaitForTask polls Proxmox until each migration finishes, no blind sleeps.
The flow refuses to proceed to the maintenance gate until cluster.ListResources shows zero guests on the node.
A second flow run with the source node as target rebalances guests back after maintenance.
snapshot.Create captures the pre-patch state of a VM or LXC. A Shell task runs the OS update over SSH. An HTTP probe checks the service. On failure, the errors branch fires snapshot.Rollback against the same snapshot name and pages on-call. Works for both QEMU VMs and LXC containers via the resourceType property.
resourceType: vm or resourceType: container on the snapshot tasks, everything else identical.
The pre-patch snapshot name is computed once and reused by the rollback in the errors branch.
An errors branch restores the snapshot if the post-patch HTTP probe fails, no human required.
Re-run the patch on the same host with the same snapshot from the execution UI.
Pick a recent vzdump archive, restore it to a temporary VMID on a target node, boot the VM, probe a known service, then delete the temp VM. A backup that doesn't restore is not a backup, this catches storage corruption, schema mismatches, and config drift before the real disaster.
The restore lands on a throwaway VMID, never the production one, so a corrupted backup can't damage the source.
An errors branch deletes the temp VM even when the drill fails, so the cluster doesn't fill up with restore artifacts.
Every drill posts a pass/fail summary to Slack and writes a row to an audit table.
Kestra allowed us to move from fragmented automation to a unified control plane, secure, scalable, and manageable by all our teams.
| Capability | | | Terraform (telmate/proxmox) | Custom scripts + Proxmox API |
|---|---|---|---|---|
| VMware-to-Proxmox migration coordination | Drives the ESXi Import Wizard, pre-flight checks, per-VM gates | Possible via custom playbooks | Possible via shell + import wizard | Possible, all manual |
| Snapshot rollback as a flow step (VM and LXC) | Native, snapshot name flows forward to <code>errors</code> branch | Ansible modules exist, no native rollback flow | Snapshot resource, no health-gated rollback | Manual via REST |
| Live migration for node drain | ListResources + ForEach + Migrate + WaitForTask in one flow | Possible via playbooks | Not in scope (provisioning tool) | Manual via REST + polling |
| vzdump backup restore drill | List + Restore to temp VMID + probe + cleanup, scheduled | Possible via playbooks | Not in scope | Manual via REST |
| Both VM and LXC lifecycle from the same orchestrator | Native <code>vm.*</code> and <code>container.*</code> tasks side by side | Separate modules per resource type | Separate resource types | Manual API calls |
| Event triggers (webhook, S3, Kafka, VM state) | Native, includes <code>vm.Trigger</code> on Proxmox state changes | Not a trigger framework | Webhook only | Manual |
| Approval gate between waves | Native Pause + resume, named reviewer logged | Not native | Not native | Manual |
| Chain Proxmox with Ansible, Terraform, NetBox, ServiceNow | Native plugin tasks, outputs flow forward | Ansible-centric | Terraform-centric | Glue scripts required |
| Air-gapped / lab deploy | Self-hosted by default, OSS edition free | Self-hosted (with AAP subscription for the UI layer) | Self-hosted (HCP for hosted) | Self-hosted |
| Orchestrate beyond Proxmox | 1300+ plugins, cross-stack | Broad Ansible collections, Ansible-centric | Terraform providers, provisioning-centric | Limited |
Side-by-side breakdown across hypervisor day-2 ops, self-service catalogs, snapshot rollback, and cross-stack orchestration as teams plan VMware exits.
Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.
Automate infrastructure workflows in Kestra
How Kestra orchestrates Proxmox, VMware, Nutanix, Docker, Terraform, OpenTofu, and Ansible in one declarative flow.
Hybrid cloud automation: patterns and platforms
Where Kestra fits alongside Proxmox, vSphere, AWS, Azure, and GCP for hybrid cloud automation, with platform comparisons.
Proxmox plugin reference
Every Proxmox task (VM, LXC, snapshot, backup, cluster, network, task, template) with copy-ready YAML examples.
Drive the ESXi Import Wizard, drain nodes with live migration, snapshot before patching, and verify vzdump backups with a monthly restore drill. Open source, self-hosted, event-driven.
