Proxmox VE 8 End of Life and Your Three Sane Paths Forward

When Proxmox VE 8 reaches end of life, its package repositories stop publishing security patches, so any newly disclosed hole in KVM, QEMU, or the Proxmox manager stays open until you move the workloads off it. In practice your VMs keep running, clustering and live migration still work, but the hypervisor itself becomes a known-bad attack surface — and the sane fix is to upgrade to the current major, isolate and timebox the box if it is a homelab, or stand up a supported node in parallel for production.

Key Takeaways

• Frozen repos — After EOL the pve-no-subscription and pve-enterprise repositories keep resolving but stop publishing new packages or security fixes.
• Still alive, still exposed — VMs, LXC containers, clustering and live migration all keep working; only new patches stop arriving.
• Context is everything — An isolated homelab node is tolerable for months, an exposed production hypervisor is not.
• Three sane moves — Upgrade to the current major, isolate and timebox the box at home, or run a supported node in parallel in production.

What "end of life" actually does to a running hypervisor

Proxmox VE 8.0 shipped in April 2023 on top of Debian Bookworm, and 8.4 was announced as the final release of the 8.x line. Proxmox supports each major release for roughly three years, which is why the 8.x tree is now past its end-of-life date.

When a release goes EOL, its package repositories do not vanish — they freeze. The pve-no-subscription and pve-enterprise lines in the sources.list.d directory still resolve, so the package lists still refresh and your node reports itself as up to date. Nothing is broken, nothing is flashing red, and that is exactly what makes the situation dangerous.

Check what your node is actually running:

pveversion -v

The output pins pve-manager and the Proxmox kernel to the 8.4 line. pve-manager is version-locked to the release, so you cannot install a newer manager or kernel onto VE 8.4. The web GUI will keep showing 8.4.x forever, even after the last CVE fix has been published.

The real cost shows up later. A newly disclosed flaw in the host stack — a QEMU escape, a pve-manager remote code execution, a network-stack bug — simply gets no patch from Proxmox. You are then responsible for backporting fixes yourself, which is never something you want to plan around. Meanwhile your guests keep working: live migration, clustering, and storage all function exactly as before, because that software is already installed. The hypervisor is healthy and useless as a defense; only the patch stream has dried up.

Which repositories survive after end of life

Three repositories back a Proxmox VE install, and all three remain after EOL — they just stop moving:

• pve-no-subscription — the free community repo that most people run. It still resolves, but it is frozen at the last 8.4 snapshot.
• pve-enterprise — the enterprise repo, which needs an active subscription. Same freeze, same resolvability.
• pvetest — the testing repo for early builds. Not a safety net on an EOL node.

See what your node points at:

cat /etc/apt/sources.list.d/pve-no-subscription.list
cat /etc/apt/sources.list.d/pve-enterprise.list

On a healthy VE 8 box those lines look like this:

deb https://repo.proxmox.com/debian/pve bookworm pve-no-subscription

After EOL the standard repositories keep resolving as a frozen snapshot, and Proxmox also publishes a dedicated EOL archive for the retired release. The exact archive URL and suite name are published in the EOL announcement, so open that page before you edit any sources.list.

One trap worth flagging: do not add pvetest in a hope of chasing newer packages. The testing repo pulls libraries built against newer dependencies, and that is a reliable way to break the 8.4 toolchain on a node you were trying to keep alive.

How do you know your node is still getting patches

The tell is the gap between a successful refresh and an actual upgrade:

apt-get update
apt list --upgradable

On a supported release, the upgradable list shows the packages waiting for you. After EOL, the refresh still succeeds but that list comes back empty, because there is nothing new to publish. That empty list is your signal that the node is frozen.

The definitive check is to compare your node's reported version against Proxmox's published lifecycle. If your major version is past EOL, you are on a frozen tree regardless of what the package manager says. A couple of Automate Proxmox VE: Essential Scripts for Homelab Backups, Health Checks & VLANs will print the node version and health at a glance so you are never surprised.

What is the real risk for a homelab versus a production box

The same EOL hypervisor is a very different risk depending on who can reach it.

For a homelab, the node usually sits behind your router's NAT with no direct public exposure. If you need to reach it remotely, a Cloudflare Tunnel on Proxmox for Zero-Trust Remote Access keeps the management port off the public internet and routes traffic through Cloudflare instead. An isolated box with no remote access and no exposed services is a tolerable risk for a defined period — you have the runway to migrate.

For production the math changes completely. The management interface is reachable, third-party clients touch the data, and compliance frameworks like SOC 2, GDPR, or PCI-DSS treat running an unpatched hypervisor as a finding. Here EOL is not a convenience trade-off, it is a liability you cannot sign off on.

Path	Best for	Downtime	Security posture	Effort
Upgrade to the current major	Everyone, the default choice	Low for in-place, moderate for a clean reinstall	Fully supported, keeps receiving patches	Low to moderate
Isolate and timebox VE 8	Homelab, non-exposed node	None	Frozen; you accept the residual risk	None
Run a supported node in parallel	Production	Low, done incrementally	Supported on the live node throughout	High

The honest trade-off is this: staying on VE 8 buys you an afternoon without reconfiguration, and it pays for that afternoon every month a new CVE lands. The EOL archive gives you a working package manager, but it is a photograph of the past, not a life raft.

The three sane paths forward

Path 1 — Upgrade to the current major. This is the default, and it is the easiest thing to do right. First take a backup and prove you can restore it, because an unverified backup is just a slower way to lose data:

qm backup 100 --storage pbs-store

Replace pbs-store with your actual PBS store name. Then either upgrade in place through the GUI or the command line, or do a clean reinstall and restore.

apt-get update && apt-get dist-upgrade

Proxmox supports in-place upgrades between consecutive major releases, so 8.4 to 9.0 will move without a reinstall. For a production node a clean reinstall onto the current major, followed by a PBS restore of a few hundred GB of VM disks, is usually the cleaner outcome. Whatever you choose, Automated Backups with Proxmox Backup Server is the thing that turns a risky upgrade into a reversible one.

Path 2 — Isolate and timebox it at home. If this is a homelab and the node is not exposed, you can legitimately stay on VE 8 for a while. Keep it off the public internet, stop publishing new services onto it, and write a hard sunset date on the calendar. Pair it with a few health-check scripts so you can watch the node's condition without babysitting it. When the date arrives, you migrate — no debate. This is the one scenario where staying is genuinely fine, and only because you have deliberately removed the exposure.

Path 3 — Run a supported node in parallel in production. Never keep an EOL box as the primary production hypervisor, but you do not have to flip a switch overnight. Stand up a VE 9 node alongside, move VMs over with live migration or a PBS restore, and decommission the old box once it is empty. For offsite redundancy on the new store, Configure Parallel Sync Jobs for S3 Offsite Backups keeps a copy of everything beyond the datacenter. The cost is real hardware and effort, but it is the only production path that never sits on unfixed code.

Conclusion

Running Proxmox VE 8 after end of life does not break your VMs, but it does stop the security patches that keep the hypervisor defensible — so the right move is to leave the frozen tree behind. Upgrade to the current major at home, isolate and timebox the node if it is not exposed, or run a supported node in parallel for production. Start today by taking a verified Proxmox Backup Server snapshot and comparing your node's reported version against Proxmox's published lifecycle, then pick the path that matches how the box is actually used.