Proxmox VE 8 goes end of life in August: Debian will keep patching you, the hypervisor will not

The day Proxmox VE 8 falls out of support, nothing will go down: not a node, not a virtual machine, not the web interface on 8006. An expired parking meter does not immobilise the car either. The difference is that the meter at least says EXPIRED on its display, and your node will carry on telling you everything is up to date. Debian will keep sending it security patches until June 2028; Proxmox stops sending them this month.

The official table says 2026-08. It does not say which day

The source is the support lifecycle table maintained by Martin Maurer, the Proxmox VE project leader, and the row for version 8 has four cells: first release 2023-06, Debian 12 "Bookworm" as its base, Debian end of life 2026-07 and Proxmox VE end of life 2026-08. The policy that goes with it fits in one sentence: Proxmox VE versions are supported "at least as long as the corresponding Debian version is oldstable".

Half the internet has spent weeks writing "31 August". We treat it as a working date too — it is the last day of the month the table gives — but it is worth knowing that Proxmox never published that specific day: it published the month. And for planning purposes it matters less than it seems, because end of life is not a switch someone flips at midnight. It is the point after which, if a bug shows up in that branch, there is no longer anyone on the other side fixing it.

Why apt will not warn you

A Proxmox VE 8 node is fed from two places at once. On one side, the Debian repositories, security included (bookworm-security). On the other, the Proxmox repository, whether enterprise or pve-no-subscription. They are two independent taps, and they do not shut off on the same day.

The Debian tap does not shut off in August. On 12 July 2026, three years after the initial release, regular support for Debian 12 "Bookworm" came to an end and the LTS team took over from the Security and Release teams; Bookworm LTS runs until 30 June 2028. What matters is how that handover is delivered: the Debian project describes it plainly as "just a responsibility handover" that "reuses the same mirror infrastructure" as the regular teams. Translated: you do not have to change a single line of sources.list. If you already follow security.debian.org, LTS updates simply arrive.

So in September you will run apt update && apt full-upgrade on an unsupported node and much the same thing will happen as in August: packages download, real security patches install, and the system ends up current. apt is not there to tell you one of the two taps has been turned off; it reports what is available, and Debian will keep providing for nearly two more years. The signal you trust keeps working, and that is why you stop looking at it.

The half that freezes

What stops getting fixed is precisely the layer that turns that Debian into a hypervisor: pve-manager — the web interface on port 8006 and its API — plus qemu-server, pve-qemu-kvm, pve-container, the cluster tooling and the Ceph packages Proxmox builds. It is also the layer that tends to be exposed: the admin interface and the cluster management plane.

And the kernel, which deserves its own paragraph because it is the most repeated confusion: Proxmox VE is Debian, but it does not boot Debian's kernel. The proxmox-kernel-* package is built from the Ubuntu kernel. We worked through this with two specific CVEs in Zapscape and SCTPhantom: your Proxmox does not run Debian's kernel, and the consequence here cuts both ways. Debian LTS does not cover that kernel — it never has, because it is not theirs — and from September Proxmox does not cover it on the 8 branch either.

A Linux kernel advisory in October will be closed in Debian, closed in Proxmox VE 9, and left open on your 8 node. With apt having nothing to say about it.

A command that knows half the truth

Debian ships a tool for this. The debian-security-support package installs check-support-status, which reviews what you have installed and tells you which packages have fallen outside security coverage, because LTS does not cover the whole Debian archive and that list shifts.

It is worth running. But you need to understand its limit before trusting the output: it only knows about Debian packages. About pve-manager or proxmox-kernel it will say nothing, good or bad, because they are not Debian's. It is an honest tool with a blind spot that happens to be exactly the one that matters to you.

What is on the other side

Version 9.2 shipped on 21 May 2026. It runs on Debian 13 "Trixie" (13.5), with Linux kernel 7.0 as the new stable default, QEMU 11.0, LXC 7.0, ZFS 2.4 and Ceph in two flavours, Squid 19.2.3 and Tentacle 20.2.1. In August Proxmox also added the official arm64 edition within that same family. All the engineering is over there.

Of what it brings, two things change daily life for anyone running a cluster. One is dynamic load balancing in the resource scheduler, which migrates HA-managed guests based on each node's actual utilisation; read that qualifier carefully, because anything not under HA stays where it is. The other is WireGuard and BGP as new SDN fabric protocols, with route maps and prefix lists for filtering.

There is a third one that looks minor and, for this particular window, is the most useful: high availability can be disarmed and re-armed cluster-wide with two new CRM commands, disarm-ha and arm-ha, so you can do maintenance without triggering a fencing event. Anyone who has upgraded a node by hand with HA active knows why those are welcome. We picked apart HA's real limits in Proxmox HA does not prevent downtime, it shortens it.

The path, in the order that matters

The upgrade is in place and node by node; nothing needs reinstalling. The order in the official guide matters, quite a lot:

1. Get every node onto the latest 8.4, with pve-manager at 8.4.1 or newer. You do not jump straight from 8.2.
2. If you run hyper-converged Ceph, move it to Squid 19.2 first, before touching Proxmox. Check with ceph --version on every node, not on one.
3. Make sure there are 5 GB free on the root mount, ideally more than 10.
4. Run pve8to9 and then pve8to9 --full. It only checks and reports: it changes nothing on its own. Whatever comes out is your actual task list.
5. Node by node: migrate the critical guests away, switch the repositories, apt dist-upgrade, reboot into the new kernel and confirm that node is healthy before moving to the next.

The repositories change name and also format. Trixie uses deb822, with multi-line .sources files instead of the familiar single-line sources.list entries, and apt complains if you stay on the old format. There is a shortcut: apt modernize-sources.

What breaks

This is not us talking: it is in the known-issues and changes list of the official upgrade guide itself. We are reproducing it because this is where a maintenance window actually goes.

• "The upgrade wants to remove the proxmox-ve package." This happens if linux-image-amd64 is installed. Remove it first, with apt remove linux-image-amd64. It is the classic scare and the fix is one line.
• GRUB can fail on LVM plus UEFI systems. Fixed with apt install grub-efi-amd64. Worth knowing before the reboot, not after.
• Network interface names can change. If your /etc/network/interfaces says enp3s0 and the card comes up called something else, the node returns with no network. That is what pve-network-interface-pinning is for.
• /tmp becomes tmpfs, using up to half of RAM. If any of your processes writes large things there, you will find out.
• cgroup v1 is gone. Containers running systemd 230 or older — from 2016 — are no longer supported. If you have old distributions inside LXC, check them before the window.
• /etc/sysctl.conf is no longer honoured. Whatever you keep there has to move to /etc/sysctl.d/. Silent and easy to miss.
• HA groups are deprecated in favour of HA rules, and migrate automatically once every node is upgraded.
• LVM thin pools may need a manual repair with lvconvert --repair pve/data.

When not to upgrade in August

We build and maintain this kind of infrastructure, so read the following with an eyebrow raised: if today you have three nodes with Ceph and the person who knows them is on holiday, forcing the upgrade into the two weeks left of the month is a worse idea than being late.

Being unsupported is not the same as being compromised. It is a probability that starts climbing, slowly, from the first bug that gets published and does not get fixed on that branch. That clock runs in weeks. A botched cluster upgrade runs in minutes, and it runs with the machines down.

The sensible move in that scenario is to do everything in August that needs no window — get the nodes onto the latest 8.4, move Ceph to Squid, run pve8to9 --full and read the whole output — and perform the upgrade in September with everyone back. That is a few weeks of known, bounded exposure in exchange for not rebooting a node blind. And if you land on 9, the next step is making it decent: we wrote that up in hardening Proxmox 9.2 in production.

What is not an option is letting it drift. The risk of this date is not in September: it is in April 2027, with the node still on the 8 branch, eight months of unfixed hypervisor bugs, and apt having said nothing the whole time because Debian kept holding up its end.

The short version

Log into a node and run two commands. pveversion tells you which branch you are on. pve8to9 --full tells you how much work is ahead. With those two outputs you already know whether this is one September afternoon or a project with a budget.

And if the answer is that you are on 8 and everything looks fine: that is exactly what it will keep looking like next month.

Sources (consulted on 16 August 2026): the support lifecycle table with the Proxmox VE 8 row (first release 2023-06, Debian 12, Debian end of life 2026-07, Proxmox VE end of life 2026-08) and the "at least as long as the corresponding Debian version is oldstable" quote come from the Proxmox VE - Support Lifecycle thread posted by Martin Maurer; the Proxmox VE FAQ states the general policy in different words ("as long as the corresponding Debian version is supported by the Debian Security Team, i.e. approximately 3 years") and does not carry the table. The end of Bookworm's regular support on 12 July 2026, the LTS team taking over and coverage to 30 June 2028 — official Debian announcement. The description of LTS as "just a responsibility handover" over the same mirror infrastructure, plus debian-security-support / check-support-status — Debian wiki, LTS/Using. Prerequisites (pve-manager 8.4.1, Ceph Squid 19.2, 5 GB free on root), pve8to9, the deb822 format and the known-issues list — official 8 to 9 upgrade guide. Version 9.2 components and features, the disarm-ha / arm-ha commands and the arm64 edition of 5 August 2026 — Proxmox VE roadmap. That the Proxmox kernel derives from Ubuntu's — Proxmox VE Kernel. Proxmox publishes the month, not the day: the "31 August" date going around is the last day of that month, not an official figure.