Proxmox VE: updates, repositories and major upgrades

Updated November 2026

On Proxmox VE, install updates with apt update followed by apt full-upgrade, never plain apt upgrade. As of November 2026 the supported release is Proxmox VE 9 on Debian 13; Proxmox VE 8 reached end of life in August 2026. In a cluster, update and reboot one node at a time, and keep the web interface on port 8006 off the internet.

Supported releases

Proxmox VE support as of November 2026 (from the Proxmox VE FAQ and roadmap)
Release	Debian base	First release	Latest version	Proxmox end of life
Proxmox VE 9	Debian 13 “trixie”	August 2025	9.2 (May 21, 2026)	To be announced (supported)
Proxmox VE 8	Debian 12 “bookworm”	June 2023	8.4	August 2026 (end of life)
Proxmox VE 7	Debian 11 “bullseye”	July 2021	–	July 2024 (end of life)

Check what a node runs:

pveversion
cat /etc/os-release

A Proxmox VE 9 host shows pve-manager/9.x and VERSION_CODENAME=trixie. Anything older is out of support and needs a major upgrade (see below).

Choose the right repository

Proxmox VE gets packages from Debian (base system and security fixes) plus one Proxmox repository. You always need the Debian repositories, including trixie-security. For the Proxmox part there are three choices:

Enterprise (pve-enterprise): Enabled by default. Proxmox calls it the recommended, most stable repository for production. It needs a valid subscription key; without one, apt update fails on this repository.
No-subscription (pve-no-subscription): Free and needs no key. Proxmox describes it as suitable for testing and non-production use and says it is not recommended for production servers, because its packages are less tested than enterprise ones.
Test (pve-test): For developers and testing only. Never use it on a server you care about.

On Proxmox VE 9 the repositories use the deb822 format in /etc/apt/sources.list.d/. The enterprise file is pve-enterprise.sources:

Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Without a subscription, disable that entry by adding the line Enabled: no to it, which also stops the error messages, and add /etc/apt/sources.list.d/proxmox.sources instead:

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Ceph users need a matching ceph.sources file (enterprise or no-subscription). Old one-line entries in /etc/apt/sources.list still work, but apt on Debian 13 warns about them; apt modernize-sources converts most of them.

A broken repository means no fixes. If apt update prints any error (often a 401 from the enterprise repository on a host with no subscription), fix it first. Proxmox says to continue with the upgrade only when apt update finished without errors.

Apply updates now

Use the web interface (the Updates panel of each node) or a shell as root:

apt update
apt full-upgrade

Why not apt upgrade? Proxmox VE is a rolling release on top of Debian, and its documentation warns that apt upgrade “may result in a partially upgraded or broken package state”. full-upgrade can install new dependencies and remove packages when needed, so read the summary before you confirm. Proxmox documents updates as a manual step, not as unattended installation. A fixed weekly window, plus an extra run when an urgent advisory appears, keeps hosts current. See Update schedules.

Kernel updates and reboots

Proxmox ships its own kernel packages. A new kernel, and any CPU microcode update, only takes effect after a reboot; the admin guide notes that known CPU vulnerabilities only show up correctly once the host “has at least been rebooted since the last kernel update”. Compare the running kernel with the kernels set up for booting:

uname -r
proxmox-boot-tool kernel list

If a newer kernel is listed than the one uname -r shows, plan a reboot. Avoid pinning an old kernel with proxmox-boot-tool kernel pin for longer than needed: Proxmox says a pin should be removed as soon as possible so the latest kernel's security fixes apply.

Clusters: one node at a time

The admin guide says to update cluster nodes “one node after the other, never all at once”, and to check each node before moving on. A safe rolling update:

Finish and verify one node before you touch the next.

Check the cluster is healthy and quorate: pvecm status (and ceph -s if you run Ceph).
Move guests off the node. With HA, put the node in maintenance mode, which migrates its HA services away and stays on across reboots until you turn it off:
```
ha-manager crm-command node-maintenance enable pve1
```
Run apt update and apt full-upgrade on that node.
Reboot the node if a new kernel or microcode was installed (reboot, as root).
When it is back, check pvecm status, wait for Ceph to report healthy, then end maintenance mode:
```
ha-manager crm-command node-maintenance disable pve1
```
Repeat on the next node.

Migrating guests from an older to a newer version works; the reverse generally does not, so do not move guests back to a node that is still waiting for updates. For planned reboots you can also set the HA shutdown policy to migrate under Datacenter → Options → HA Settings.

Major upgrades (pve8to9)

Proxmox VE 8 stopped getting updates in August 2026. Move every remaining 8.x node to 9 using the official “Upgrade from 8 to 9” guide. The short version:

Have a tested backup of every guest and reliable console access (IPMI or physical), not just SSH.
Update to the latest 8.4 first; pveversion must show at least 8.4.1.
Ceph clusters must already run Ceph Squid 19.2.
Run the read-only checker and fix what it reports, then run it again: pve8to9 --full
Switch the Debian and Proxmox repositories from bookworm to trixie, then apt update and apt dist-upgrade (the same as full-upgrade).
Run the upgrade over SSH inside tmux or screen, never from the GUI's virtual console, which is cut off during the upgrade.
Run pve8to9 once more, then reboot, one node at a time.

Proxmox VE 7 and older are far behind. Plan an upgrade one major version at a time (7 to 8, then 8 to 9) or a fresh install of 9 with a restore of guests from backup. See Is my OS supported?.

Never expose port 8006

The web interface listens on TCP port 8006. A cluster also uses SSH (22), SPICE proxy (3128), VNC consoles (5900–5999), corosync (UDP 5405–5412) and live migration (60000–60050). None of these should be reachable from the internet. Reach the interface over a VPN or from a management network only.

The built-in Proxmox VE firewall is completely disabled by default. If you turn it on, open an SSH session first, and add your admin IPs to an IPSet named management, which creates the rules needed for GUI access.
Turn on two-factor authentication (MFA: TOTP or WebAuthn) for every admin account.
Keep the hosting provider's or edge firewall in front of the host as a second layer. See Firewall basics.

Security advisories

Proxmox publishes security advisories (numbered PSA-YYYY-NNNNN) in a pinned thread in its community forum, “Proxmox Virtual Environment - Security Advisories”. Watch that thread with a forum account. Because the base system is Debian, also follow Debian's security announcements (see Debian). For more ways to track advisories, see Security advisories.