The lifecycle table in Proxmox's official documentation is one of the dullest things you can read on a Wednesday, and also one of the most useful: the 8 branch —the one installed on almost everything built between 2023 and 2025— has its end of life set for August 2026. That is, in just over thirty days. The usual reaction is to block out a weekend in August and jump to 9. We're going to say the opposite: for quite a few clusters, upgrading in August is a worse idea than being late.
Not because 9 is bad —we run it in production and we already wrote up the hardening checklist we apply to every 9.2 cluster— but because the deadline pushes people to do in one weekend something that, depending on how your environment is built, is two chained projects. And because the jump has an asymmetry almost nobody talks about, one that wipes out your rollback plan.
What exactly ends (and what doesn't)
It pays to be precise, because there is a lot of fear being sold here. The support table in the Proxmox FAQ says this:
Note that the official documentation talks about a month, not a day: "2026-08". You'll see 31 August quoted very confidently out there; we couldn't find it on any Proxmox page. It gets better: the upgrade wiki itself, in its section on containers using cgroup v1, writes something different —"the remaining Proxmox VE 8 support cycle (estimated EOL is July 2026)"—. If the vendor's own documentation disagrees with itself by a month, you shouldn't be planning to the day either. Nothing switches off on 1 September, no licence expires and your cluster keeps booting the same. What stops arriving are new packages: fixes for the Proxmox kernel, for QEMU, for the pve-* packages themselves.
And here's a nuance almost nobody gets right. Debian 12 (bookworm) ended regular security support on 12 July 2026 and moved to the LTS team, which maintains it until 30 June 2028. That sounds like a safety net, and for Debian packages it is. But Debian LTS maintains Debian packages, and the hypervisor isn't one: pve-manager, qemu-server, the Proxmox kernel or the Ceph packaging come from Proxmox's own repositories. When branch 8 falls, that part —the one running your machines— stops getting fixes. You still get OpenSSL patches; not hypervisor ones.
The asymmetry that leaves you with no way back
The official 8→9 upgrade wiki says it without any drama, in a line that reads fast and sinks in late: migrating a VM or container from an older version to a newer one will always work; the other way round "may work, but is generally not supported". Translated into Saturday night: the moment you upgrade the first node and move workloads onto it, you can no longer count on moving that workload back to the node still on 8. It might work. But "it might work" isn't a rollback plan.
That changes the nature of plan B. Plenty of people walk into the window thinking their rollback is "I migrate the VMs to the other node and we're done". It isn't: your rollback is restoring from backup, with the restore time that implies and the hours of data you lose in between. If you've never timed how long a full restore of the three machines that actually matter takes, you don't have a plan B: you have a hope.
If you run Ceph, it is not one window: it is two
The requirement is in the wiki, in bold and where it belongs: if you run hyperconverged Ceph on Quincy or Reef, you must take it to Ceph 19.2 Squid before starting the Proxmox upgrade. Before, not during. And upgrading Ceph on a cluster with live data is a project with its own rhythm: OSD by OSD, checking cluster health between steps, without rushing, because rushing in Ceph is paid for in backfill. Anyone with this still pending while staring at the August calendar already knows the answer: it does not fit. The first half fits, and the second half happens in September.
Checking costs one command and saves an ugly conversation halfway through the window:
pve8to9 ships with recent 8.4 packages and only checks and reports: by default it changes nothing. It's the most underrated tool in the whole process. Run it today, not on the night of the window: its value is handing you the homework list while there's still time to do it.
The containers that are not going to start
This is the blocker that always shows up late. Proxmox VE 9 does not support containers running systemd 230 or older —a 2016 release— which in practice means CentOS 7, Ubuntu 16.04 and friends. The wiki says so plainly. And those containers exist: they are precisely the ones nobody wants to touch, running the application whose author has since retired.
Sorting it out means moving that application onto a new operating system, with the testing and the sign-off from whoever uses it that this implies. If you find out at eleven on Saturday night, your realistic option is to leave that container where it is, on a node you do not upgrade, and end up with a half-upgraded cluster. If you find out today, you have a month to decide whether that application deserves a migration, a dedicated virtual machine or retirement.
Six signs that August is not the moment
Our rule is simple: if a single one of these six is true, the upgrade moves to September and we set up a containment plan for the month left without patches. Being late with the cluster standing is recoverable; being on time with a node that will not boot, in August and with half the team on holiday, is not.
- ✗Ceph is still on Quincy or Reef. Squid first, in its own window. Chaining both in one night is like changing the engine and the wheels at once, while driving.
- ✗There are containers with old systemd and no decision about where they go. They won't start, and deciding that in the middle of the night is expensive.
- ✗You have no out-of-band access to the node (IPMI, iDRAC, iLO or a physical console you can reach). The wiki recommends it explicitly, and for a reason: the new kernel can rename network interfaces, and a node with broken networking is only fixed from the console.
- ✗Your last tested restore is "the usual one", with no date and no stopwatch. Here plan B runs through restoring, and a restore nobody has timed yet doesn't count as a plan.
- ✗
pve8to9 --fullreturns warnings you don't understand. Every unresolved warning is a postponed surprise, and the distance between "I don't understand this" and "this won't boot" is a few hours. - ✗The window lands next to a month-end close, a payroll run or a business peak, or the people who know this system are on holiday. August is August. People's availability is part of the window design, just like quorum is.
How we do it
When there is spare hardware and capacity, we do not do in-place upgrades: we prefer to drain the node —migrate its workload onto the others—, leave it empty, upgrade or reinstall it, give it work back and move on to the next one. It is slower and duller, and in exchange the node you are touching has nothing on it when it breaks. Same old logic: separate the change from the risk. When there is no headroom to drain a whole node, the wiki's in-place path is perfectly fine and works; what changes is that then you really do need everything above sorted out beforehand.
The rest of the discipline, briefly — all of it from the official wiki plus what the trade has taught us:
- ✓Every node on the latest 8.4 first (the wiki asks you to be on the latest 8.4, and for repositories it mentions
pve-manager8.4.1 or newer). A cluster with mismatched versions gets sorted out before you start, not during. - ✓Free space on root: the wiki asks for 5 GB and recommends more than 10. You check it with the cluster quiet, well before launching the
dist-upgrade. - ✓Run inside
tmuxorscreen. A major upgrade is not done over a bare SSH session that dies with your laptop's connection. - ✓One node, verify, breathe. If the first one fights back, the window closes there and the cluster carries on with the majority on 8. There is no prize for finishing at dawn.
- ✓Never two clusters on the same weekend. If something odd shows up, you want it showing up once, not three times.
And two specific wiki warnings worth their weight: on UEFI plus LVM systems you may need to install the grub-efi-amd64 meta-package, and some LVM thin pools need an lvconvert --repair after the jump. Neither is serious if you know they exist; both look very serious at two in the morning.
If you are not going to make it: an honest containment plan
Deciding "in September" is legitimate, but it is not free and it is not decided by staying quiet. What we do with a cluster that will spend a few weeks out of support:
- 1.A date written in the calendar, with a name attached. Postponements left without a date end up lasting years — we wrote about that same trap when covering monitoring silences with no expiry date.
- 2.The management panel off the Internet. With no hypervisor patches, exposed surface matters twice as much.
- 3.Verified backups with a genuinely timed restore before the new window. It is the work you are going to need either way.
- 4.And August's job is preparation:
pve8to9 --full, container inventory, Ceph to Squid. You reach September with the window practically already done.
There is one case where we do say "don't do it now, buy it properly": if the plan involves replacing hardware to make room for the migration, memory prices are not on your side this year. We covered it with the market numbers in what AI has done to RAM prices. And if the bottleneck is storage, the Ceph design decision weighs more than the version: it is broken down in replica 3 versus erasure coding with the full math.
The thirty days left, laid out
If you are going for it, here is the split that looks realistic to us counting from today, 29 July. This week: pve8to9 --full on every node, an inventory of containers by OS version, check the Ceph version and free space on root. All of it is read-only, touches nothing, and can be done on a Tuesday afternoon. First half of August: fix whatever came out —Ceph to Squid, old containers, checker warnings— and run a timed restore. Second half: the jump, starting with the lowest-risk node, one node per window, with the rest of the cluster still standing. If at any point along the way something is missing, you stop and move to September. That is the important part of the plan.
In short
The August date is real and deserves to be taken seriously: without it, this upgrade would sleep for another two years. But a date is not a plan, and this summer's expensive mistake will not be arriving in September: it will be walking into the window without having run the checker, without knowing which containers will not start, and believing you can roll back by moving a VM. That last one is the only part you genuinely cannot undo.
Sources (verified): version lifecycle table (PVE 9 / Debian 13 / 2025-08; PVE 8 / Debian 12 / 2023-06 / end of life 2026-08; PVE 7 / 2024-07) — official Proxmox VE FAQ. Upgrade requirements and known issues (being on the latest 8.4 with pve-manager 8.4.1 or newer for repositories, Ceph 19.2 Squid before starting, 5 GB free on root with more than 10 recommended, containers with systemd 230 or older unsupported, network interface renaming, grub-efi-amd64 on UEFI+LVM, lvconvert --repair, pve8to9 --full, live migration guaranteed only from older to newer version) — official "Upgrade from 8 to 9" wiki. The vendor's own contradiction ("estimated EOL is July 2026", in the cgroup v1 removal section of that same upgrade wiki). Debian 12 dates (regular support ended 12-07-2026, three years after the initial release; LTS until 30-06-2028) — official Debian announcement and Debian LTS wiki. The exact end-of-life day (31 August) circulates in media and aggregators, but we could not confirm it in Proxmox documentation: hence we talk about a month. The six-signal rule, the thirty-day split and the drained-node way of working are ours.
Need to jump to Proxmox VE 9 and would rather not do it alone?
At everyWAN we run Proxmox VE infrastructure with Ceph in production, spread across several datacenters, since the 3.x branches. We review the real state of your cluster, tell you whether it makes August, and plan the window with you — including the part where we tell you not to do it yet.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN