Safe Proxmox VE Patching with Snapshot Rollback

Patch a Proxmox VE virtual machine behind a snapshot gate, with automatic rollback when an update goes wrong. OS patching on bare VMs is risky: a broken kernel, a failed package upgrade, or a service that will not restart can leave a guest unbootable with no clean way back. This blueprint wraps the whole cycle in a single declarative Kestra flow that takes a pre-patch snapshot, applies updates over SSH, verifies the application with a health probe, and restores the snapshot the moment anything fails, so a bad patch never leaves the VM in a broken state.

How it works

1. create_snapshot (io.kestra.plugin.proxmox.snapshot.Create) captures a pre-patch snapshot named prepatch-{{ execution.id }}, keyed to the execution id so the rollback always targets the exact snapshot this run created.
2. apply_patch (io.kestra.plugin.scripts.shell.Commands) runs on the io.kestra.plugin.scripts.runner.docker.Docker task runner using an alpine:3.20 image. It installs openssh-client, loads the private key from inputFiles, then SSHes into the guest to run apt-get update and a non-interactive apt-get -y upgrade.
3. health_probe (io.kestra.plugin.core.http.Request) sends a GET to the health_check_url; a non-2xx response fails the task.
4. If the patch step or the probe fails, the errors handler rollback_snapshot (io.kestra.plugin.proxmox.snapshot.Rollback) restores the pre-patch snapshot automatically.

What you get

• A snapshot-gated patch cycle with guaranteed rollback on failure.
• Application-level verification, not just a successful package install.
• Snapshot names tied to the execution id, so rollbacks never hit the wrong restore point.
• A full audit trail of every patch run, its output, and its outcome.

Who it's for

• Platform and infrastructure engineers running Proxmox VE clusters.
• SREs who need unattended, reversible maintenance windows.
• Homelab and self-hosted operators who want safe automated updates.

Why orchestrate this with Kestra

Proxmox has snapshots and a scheduler, but it cannot tie "snapshot, patch over SSH, health-check the app, roll back on failure" into one governed, observable unit of work. Kestra adds the event triggers, retries, error handling, and execution lineage that the Proxmox scheduler cannot: the rollback lives in a declarative errors block, every step is logged and replayable, and the whole flow is version-controlled YAML rather than a brittle cron script.

Prerequisites

The guest must be reachable over SSH from the worker, and the SSH user needs sudo.

Secrets

• PROXMOX_HOST: Proxmox VE host or IP (no scheme, no port).
• PROXMOX_NODE: Cluster node name that scopes the API calls (for example, pve).
• PROXMOX_USERNAME: PAM or PVE user in the form user@realm (for example, root@pam).
• PROXMOX_PASSWORD: Password for ticket-based authentication.
• VM_SSH_PRIVATE_KEY: SSH private key for the patch user on the guest.

Quick start

1. Set the five secrets above in your Kestra namespace.
2. Run the flow with vm_name, vm_host, and health_check_url.
3. The flow snapshots the VM, patches it, and probes the health URL; any failure rolls back to the snapshot.
4. Enable the disabled monthly_maintenance Schedule trigger to run unattended during your maintenance window.

How to extend

• Swap the apt-get commands for yum, dnf, or zypper to patch RHEL, Fedora, or SUSE guests.
• Add a retry policy to health_probe to tolerate slow service restarts before deciding to roll back.
• Fan out across many VMs with a ForEach task driving vm_name and vm_host.
• Notify Slack or email from the errors block so on-call sees every rollback.

Links

• Proxmox plugin documentation
• Proxmox orchestration with Kestra