WZ-IT handles agreed update tasks through Proxmox maintenance or Managed Proxmox. Arrange a discussion.
This guide covers regular package updates within a PVE major release. Moving from PVE 8 to 9 belongs in the major upgrade guide. As of October 2026.
Contents
- Distinguish updates and upgrades
- Check repositories
- Install updates with the GUI or APT
- Prepare reboots and clusters
- Errors and acceptance
- Agree maintenance
- Sources
Distinguish updates and upgrades
Proxmox distributes package updates through APT. The documented installation methods are the web interface and command line. The vendor explicitly warns against using only apt upgrade, which may omit package removals required by dependencies: System Software Updates.
Before approval, we recommend recording three changes separately: regular packages, a new kernel and a major PVE or Ceph release change. This guide is insufficient for the last case. A maintainable procedure starts with an inventory and an available recovery path, including host configuration and backup access.
Check repositories
PVE and Debian sources must match the installed major release. The enterprise repository requires a valid subscription. No-subscription is accessible without a key but is not recommended for production. The test repository is not a production substitute. The repository documentation explains these distinctions.
Recommended check: select the node, open its repository view and compare Debian, PVE and any Ceph sources. Disable old or duplicate entries only after review. Do not change the distribution name merely to address an access error. Running Proxmox without a subscription explains subscriptions and package sources.
Install updates with the GUI or APT
Select the relevant node in the web interface, refresh the update view and open the offered upgrade dialog. Review package changes and prompts. Alternatively, the vendor guide provides these commands for the node's administrative shell:
apt update
apt full-upgrade
Our recommendation: do not add automatic confirmation with -y. If fetching package lists fails, package removals are unexplained or dependencies cannot be resolved, stop and investigate. A successful apt update establishes only that lists were retrieved, not that installation finished.
Prepare reboots and clusters
An installed kernel becomes active only after booting into it; the HA manual therefore discusses reboots after kernel updates separately. This does not imply a mandatory reboot after every individual package.
For clusters, we recommend selecting one node, checking guest capacity and migration eligibility, performing maintenance and fully accepting that node before proceeding. The cluster update guide describes the sequence including HA maintenance mode and return. On a standalone host, a required host reboot must be planned as an interruption for guests running there.
Errors and acceptance
For acceptance, we recommend a short checklist rather than relying solely on the package dialog:
| Check | Result to record |
|---|---|
| Package operation | No unresolved errors; unexpected changes explained |
| Kernel and version | Installed and running versions compared |
| Infrastructure | Network, storage and cluster quorum checked |
| Applications | Owners confirm agreed functional checks |
| Recovery | Backup access and recovery plan available |
Disabling HA does not fix a package error. Stop before the next node if cluster issues occur. A successful job also does not replace a PBS restore test.
Agree maintenance
An update service should define responsibilities, maintenance approval, backups and acceptance. Proxmox maintenance describes the offer; Managed Proxmox explains broader operational responsibility. A subscription alone does not perform the work.
Discuss Proxmox maintenance: review the environment, package sources and operational requirements together.
For update ownership, use the maintenance contract checklist.
