Proxmox VE Release History: Debian Bases, Kernels and Support Dates

Proxmox VE has shipped nine major versions since its first stable release on 29 October 2008, and each one sits on a single Debian stable release: 7.x on Debian 11 Bullseye, 8.x on Debian 12 Bookworm and 9.x on Debian 13 Trixie. Proxmox VE 8 reached end of life in August 2026, so 9.2 is the only supported line today.

The Debian base decides how long a major version gets security updates, the kernel decides which hardware boots, and the Ceph release decides whether a hyper converged cluster can upgrade at all. Everything below comes from the Proxmox VE roadmap, FAQ, upgrade guides and Debian's release index, read on 25 October 2026.

This goes one level deeper than our Proxmox VE homelab guide; for the Debian side, see our Debian release history.

Key takeaways

• Nine major versions, nine Debian bases. Proxmox VE 1 through 9 map to Debian 5 Lenny through Debian 13 Trixie in the Proxmox FAQ table. (1.0 itself sat on Debian 4.0 Etch; 1.2 moved to Lenny.)
• Support follows Debian's regular security support, not Debian LTS. The FAQ promises support "at least as long as" the Debian Security Team supports the base, roughly three years. Proxmox VE 8 ended in 2026-08 even though Debian 12 LTS runs to 30 June 2028.
• Only 9.x is supported on 25 October 2026. The current release is 9.2 (21 May 2026), with an arm64 build added on 5 August 2026. The 9.x end of life is still listed as "tba", while Debian 13's regular security support ends on 9 August 2028.
• Kernels are Proxmox builds derived from Ubuntu kernels. The default kernel moves forward inside a major version (8.x went 6.2, 6.5, then 6.8), and a newer kernel is often offered as opt in before it becomes the default.
• Ceph has its own clock. Each Proxmox major needs a minimum Ceph release before you upgrade: Octopus before 7.0, Quincy before 8.0, Squid before 9.0. Proxmox lists Ceph Squid's estimated end of life as 2026-09 and Tentacle's as 2027-11.
• Major upgrades use a checker script. pve5to6 through pve8to9 only report problems; run the full check before and after, one node at a time.
• Repositories differ by maturity, not by software. Enterprise, no-subscription and test are all signed with the Proxmox archive key; no-subscription is not recommended for production.

What is Proxmox VE and when did 1.0 ship?

Proxmox Virtual Environment is a server virtualization platform delivered as a complete Debian based operating system. The administration guide's introduction says the project "started in 2007, followed by a first stable version in 2008", and the roadmap page fills in the exact dates. Proxmox VE 0.9 was the first public release on 15 April 2008, 0.9beta2 followed on 22 July 2008, and Proxmox VE 1.0, the first stable release, came out on 29 October 2008.

The FAQ describes the platform's core facts directly: it is based on Debian GNU/Linux, the code is licensed under the GNU AGPL version 3, and it runs only on 64 bit CPUs. The supported host architectures are x86_64 and, since 2026, arm64 on specific server platforms.

What Proxmox VE bundles has changed over 18 years, but the current stack looks like this:

The 1.0 release notes list KVM and OpenVZ live migration, support for up to 16 CPUs, kvm-75 and a base of Debian 4.0r5, a detail that matters in the next section.

How does each Proxmox VE version map to Debian?

Each major version is built on exactly one Debian stable release. A new Proxmox major follows a new Debian stable by weeks or months, then lives for as long as that Debian release receives regular security updates.

Here is the support table from the Proxmox VE FAQ, next to the dates Debian publishes on its own release index. The "Debian EOL" column in Debian's table is the end of regular security support, before LTS.

Three quirks show up whenever someone compares the two tables.

1. Proxmox VE 1.0 predates Debian 5. Lenny was released on 14 February 2009, four months after Proxmox VE 1.0, whose notes say "Based on Debian 4.0r5". The 1.2 release on 12 May 2009 moved to Lenny.
2. Some FAQ Debian dates differ slightly from Debian's. The FAQ puts Bullseye's security end at 2024-07; Debian says 14 August 2024. For Lenny the FAQ says 2012-03; Debian says 6 February 2012. Debian's page is the authority for Debian dates, the FAQ for Proxmox's own end of life.
3. Early Proxmox lines outlived their Debian base. Proxmox VE 3 ran to 2017-02, ten months after Wheezy's regular security support ended. From 4 onward, Proxmox's end of life sits within a month or so of Debian's security end.

Why the Debian base drives support dates

The FAQ is explicit: "Proxmox VE versions are supported at least as long as the corresponding Debian version is supported by the Debian Security Team, i.e. approximately 3 years after its initial release." Debian's release page describes the life cycle in the same terms: three years of full support followed by two years of Long Term Support.

The important words are "Security Team". Debian LTS is a separate phase after regular support, listed in its own column on Debian's index, and Proxmox does not tie its support to it. So a Proxmox VE 8 node is out of support even though Debian 12 gets LTS updates until 30 June 2028; its kernel, QEMU and cluster stack no longer get updates.

Inside each major version Proxmox uses "a rolling release model," so an 8.0 install that ran apt full-upgrade regularly simply became 8.4.

Proxmox VE major versions at a glance

This table summarises each major line by its first release. Kernel, QEMU and Ceph values are from the x.0 release notes on the roadmap page; later columns show where the line ended up.

Proxmox VE 2.0 took a while: first public beta on 30 September 2011, release candidate 1 on 16 February 2012, final on 30 March 2012.

Every point release from 5.0 to 9.2

The deeper table below is where the release history becomes useful for operations. If a node reports 7.2 or 8.3, this tells you the Debian point, kernel, QEMU, LXC, ZFS and Ceph versions it shipped with. All values come from the "Based on" and component lines at the top of each release entry on the roadmap page. A dash means the header does not list that component.

Some releases got refreshed ISO images later: 7.0 on 31 August 2021 (final Debian 11.0 base), 8.1 on 7 February 2024 (ZFS 2.2.2 and a newer kernel) and 8.2 on 22 August 2024 (a newer Secure Boot shim). A refreshed ISO is the same release with a newer package set, not a new version.

Where do Proxmox VE kernels come from?

Proxmox VE does not use the stock Debian kernel. It ships its own kernel packages, and the Proxmox VE Kernel wiki page explains where they come from: for most of the platform's history they have been derived from Ubuntu kernels, with ZFS built in.

The kernel page lags the release notes in places. It still calls 6.17 the current 9.x kernel, while the 9.2 notes name 7.0 as the new default, and it says 8.0 "was based on the 6.3 kernel" where the 8.0 notes say 6.2. This post's tables follow the release notes.

How do opt in kernels work?

Proxmox often publishes a newer kernel as an opt in package before it becomes the default: 5.11 on 6.4, 5.19 on 7.3, 6.2 on 7.4, 6.11 on 8.3 and 6.14 on 8.4. The opt in kernel on the last point release of a major line has become the next major's starting kernel three times running: 6.4's 5.11 became 7.0's default, 7.4's 6.2 became 8.0's, and 8.4's 6.14 became 9.0's. That lets you test the next major's kernel on your hardware months early.

You still reboot after a major upgrade, "even if you already used the 6.14 kernel previously," because the kernel is rebuilt with the newer compiler and ABI. The default kernel comes in through the proxmox-default-kernel meta package; the 8.2 notes show pinning it to version 1.0.1 in /etc/apt/preferences.d/ to stay on 6.5 for a while. The host administration chapter documents proxmox-boot-tool kernel pin to choose which installed kernel boots, with a next boot option for a one time test.

Kernel changes that bit people

The known issues sections show why kernel jumps deserve a test node. With 8.2's move to 6.8, intel_iommu defaulted to on, which the notes warn can upset older hardware or outdated BIOS. With 9.1's 6.17 kernel, users reported boot failures on some Dell PowerEdge servers where 6.14 booted, and the DRBD module could not yet be built. With 9.2's ISO kernel 7.0.2-6, the notes report problems with megaraid_sas RAID controllers and some NVMe drives in JBOD mode. Read the known issues for the version you are moving to, and keep an older kernel installed until the new one boots cleanly.

What changed in each major version?

The roadmap's release notes run to tens of thousands of words. These are the changes that define each major line.

Proxmox VE 1.x (2008 to 2011): KVM plus OpenVZ on a web interface

1.0 brought KVM and OpenVZ live migration and vzdump backups for KVM guests. 1.2 (12 May 2009) moved to Debian Lenny with kvm-85, 1.3 removed the OpenVZ limit of 50 machines, and later 1.x releases offered 2.6.18, 2.6.32 and 2.6.35 kernel branches side by side.

Proxmox VE 2.x (2012 to 2013): the cluster stack arrives

2.0 made Proxmox VE a cluster product. The notes list "New cluster communication based on corosync," the pmxcfs cluster file system "replicated in realtime on all nodes using corosync," and High Availability for KVM guests and OpenVZ containers, on Debian 6 Squeeze with a RHEL 6 based 2.6.32 kernel.

Proxmox VE 3.x (2013 to 2015): Ceph and ZFS appear

3.0 moved to Debian Wheezy. 3.2 (10 March 2014) added a GUI managed Ceph server and a ZFS storage plugin, both as technology previews, plus an optional 3.10 kernel without OpenVZ. 3.4 (19 February 2015) added ZFS, with all RAID levels, to the installer.

Proxmox VE 4.x (2015 to 2016): LXC replaces OpenVZ

4.0 (5 October 2015) moved to Debian 8 Jessie and Linux 4.2 and, in the notes' words, included LXC "and removed OpenVZ." This was the biggest compatibility break in the platform's history: OpenVZ needed the old 2.6.32 kernel, and dropping it let Proxmox move to modern kernels. 4.1 added unprivileged containers as a technology preview.

Proxmox VE 5.x (2017 to 2019): Stretch, Luminous and replication

5.0 (4 July 2017) moved to Debian 9 Stretch, added asynchronous ZFS storage replication as a technology preview, live migration with local storage, and Proxmox packaged Ceph Luminous as a preview. 5.4 introduced pve5to6, the first upgrade checklist tool.

Proxmox VE 6.x (2019 to 2021): Corosync 3 and Kronosnet

6.0 (16 July 2019) moved to Debian 10 Buster and to "Corosync 3.0.2 using Kronosnet as transport," with unicast as the default. Ceph Nautilus brought ceph-volume OSDs and one click OSD encryption. 6.2 moved to the 5.4 LTS kernel and LXC 4.0 with initial full cgroup v2 support; 6.4 brought ZFS 2.0.

Proxmox VE 7.x (2021 to 2024): Bullseye, cgroup v2 and io_uring

7.0 (6 July 2021) moved to Debian 11 Bullseye, made Ceph Pacific the default, made io_uring the default disk I/O engine for new or migrated guests, and added Btrfs root as a technology preview. The 6 to 7 guide has a whole section on cgroup v2 because old containers needed changes. 7.3 added the Cluster Resource Scheduler, guest tags and Proxmox Offline Mirror support for air gapped systems.

Proxmox VE 8.x (2023 to 2026): Secure Boot, SDN and notifications

8.0 (22 June 2023) moved to Debian 12 Bookworm, added a Ceph enterprise repository, PCI and USB resource mappings, and made x86-64-v2-AES the default CPU model for new VMs in the web UI.

8.1 (23 November 2023) is the security milestone of the line. Its notes say Proxmox VE "now includes a signed shim bootloader trusted by most hardware's UEFI implementations," and the Secure Boot Setup page adds that the bootloader is signed with Microsoft's official Secure Boot certificate since 8.1. 8.1 also made the core SDN stack supported, added the new notification system (SMTP, Gotify, matcher based routing) and made Ceph Reef the default.

8.2 (24 April 2024) added an import wizard for guests from other hypervisors, unattended installation from an answer file, backup fleecing, and an nftables firewall written in Rust as an opt in technology preview. 8.3 added webhook notifications and OVF/OVA import; 8.4 added live migration with mediated devices, a backup provider plugin API and virtiofs.

Proxmox VE 9.x (2025 to now): Trixie, fabrics, OCI and arm64

9.0 (5 August 2025) moved to Debian 13 Trixie and added HA affinity rules that replace HA groups, SDN fabrics (OpenFabric and OSPF), LVM snapshots as volume chains (technology preview) and ZFS RAIDZ expansion. Two security relevant defaults changed: containers are created unprivileged by default, because "Privileged containers lack security features," and the VM.Monitor privilege gave way to finer grained permissions. GlusterFS support was dropped "as it is unmaintained."

9.1 (19 November 2025) added LXC containers created from OCI images, TPM state in qcow2 and a nested virtualization vCPU flag. 9.2 (21 May 2026) added dynamic load balancing in the scheduler, WireGuard and BGP fabrics, custom CPU models in the GUI and Ceph Tentacle.

The arm64 build of 9.2 (5 August 2026) is the "First Proxmox VE release for a CPU architecture besides x86-64." It officially supports the NVIDIA Grace and Vera platforms, other UEFI based ARMv9-A hardware on a best effort basis, and not device tree only boards such as the Raspberry Pi. It shares repositories and lifecycle with x86-64, but live migration works only between nodes of the same architecture.

How do the Proxmox VE repositories and updates work?

Updates reach a node through APT. The Package Repositories page lists three Proxmox VE repositories, and every one of them needs the Debian base repositories as well.

The page says no-subscription packages "are not always as heavily tested and validated," and that Ceph no-subscription versions are later made available in the enterprise repository.

On Trixie, APT "will complain" about the legacy single line format, so 9.x uses deb822 .sources files; apt modernize-sources converts old entries and keeps .list.bak copies. Subscription keys are bound to the host architecture, and new 9.x installs enable Debian's non-free-firmware component so hosts get early CPU microcode updates.

Repository signing keys

Proxmox repository Release files are signed with GnuPG and APT verifies them. An ISO install already has the key. On plain Debian, the Package Repositories page has you download proxmox-archive-keyring-trixie.gpg to /usr/share/keyrings/proxmox-archive-keyring.gpg and compare its checksum with the published value; older Bookworm and Bullseye keys lived in /etc/apt/trusted.gpg.d/. Each deb822 stanza names that keyring in a Signed-By: line, so the key vouches only for the repositories that name it.

How do Ceph versions fit into the Proxmox VE lifecycle?

Hyper converged Ceph means tracking two release trains. Ceph's release index gives first release dates; Proxmox's Package Repositories page gives the Ceph releases each major supports and an estimated end of life.

Two consequences follow. A Proxmox major upgrade has a Ceph prerequisite: the 8 to 9 guide says to "upgrade any Ceph Quincy or Ceph Reef cluster to Ceph 19.2 Squid before you start," and the earlier guides set the same rule for Quincy and Octopus. And the Ceph clock can run out first: on 25 October 2026, Proxmox's Squid estimate (2026-09) has passed while Proxmox VE 9 is still supported, so 9.x clusters on Squid should plan the move to Tentacle.

The Ceph upgrade guides follow a pattern: set the noout flag, upgrade packages on every node, restart monitors, then managers, then OSDs, then unset noout. The Reef to Squid guide requires all nodes on Proxmox VE 8.2 or newer with pve-manager at 8.2.8 or later before starting.

When does each Proxmox VE version reach end of life?

Using the FAQ as the authority for Proxmox's own dates:

Proxmox has not published a 9.x end of life. If the pattern since 4.x holds it will land near Debian 13's security end on 9 August 2028, but that is an inference, not a published date.

In practice, end of life means the hypervisor parts (kernel, QEMU, LXC, API daemons, web interface) stop receiving fixes, even if Debian LTS still patches some base packages underneath.

How do major Proxmox VE upgrades work?

The FAQ says major upgrades "are also supported" but "must be carefully planned and tested and should never be started without having a current backup ready." Each upgrade guide offers two routes: a fresh install on new hardware followed by restoring guests from backup, or an in place upgrade with APT, node by node.

Upgrade paths and prerequisites

The checker script "only checks and reports things," and by default it makes no changes. The 8 to 9 guide says to run the full check at least once before the upgrade, and to rerun it after each fix and after the upgrade, because its output changes with the state of the system.

Rolling upgrades in a cluster

The guides describe a rolling process: upgrade one node, check it, then start over at the prerequisites for the next. The 8 to 9 guide says migrating from an older version to a newer one "will always work," while newer to older "may work, but is generally not supported." So move guests off node A, upgrade it, move node B's guests onto A, upgrade B, and never plan on moving guests back down. In 9.x, HA groups become node affinity rules automatically once every node runs Proxmox VE 9.

Known traps in the 8 to 9 upgrade

The 8 to 9 guide lists issues worth knowing before you start:

• Trixie makes /tmp a tmpfs using up to 50 percent of memory and cleans /tmp and /var/tmp regularly, as the Debian Trixie release notes also describe.
• Installs on plain Debian with linux-image-amd64 must remove that package first, or the upgrade may try to remove proxmox-ve.
• Third party storage plugins must be updated by their authors for 9.0.
• UEFI systems with root on LVM need the fixed grub-efi-amd64 package, and the systemd-boot meta package should usually be removed when pve8to9 says so.
• NIC names can change with the new kernel; 9.x ships pve-network-interface-pinning, and the guide recommends out of band console access.
• Newer Ceph point releases add health checks for insecure auth key types that can show HEALTH_ERR after the first monitor node reboots. The guide says to continue and migrate the keys once all nodes run 9.

Decision table: what to do based on your version today

Step by step: check, plan and run a major upgrade on one node

The commands below follow the Proxmox VE FAQ and the 8 to 9 upgrade guide. Run them on a test node first if you can, and have console access that does not depend on the node's own network.

Step 1: record what you are running

# Proxmox and component versions (pve-manager, kernel, QEMU, LXC, ZFS, Ceph)
pveversion -v

# Running kernel and Debian point release
uname -r
cat /etc/debian_version

# Cluster membership and quorum (clusters only)
pvecm status

# Ceph versions across all daemons (hyper converged clusters only)
ceph versions

Save the output as your "before" picture; it also tells you which row of the point release table you started from.

Step 2: check repositories and signing keys

# List every configured APT source
ls /etc/apt/sources.list.d/
cat /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources 2>/dev/null

# Confirm the Proxmox archive keyring exists and check its checksum
ls -l /usr/share/keyrings/proxmox-archive-keyring.gpg /etc/apt/trusted.gpg.d/ 2>/dev/null
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

# Make sure apt update is clean before doing anything else
apt update

Compare the checksum with the published value, and look for leftover repositories for another Debian codename, a backports line, or enterprise and no-subscription enabled together. The FAQ says to continue only if apt update reports no error.

Step 3: bring the node to the latest point release

apt update
apt dist-upgrade
pveversion

For an 8 to 9 upgrade, the guide says pveversion should report at least 8.4.1 before you continue.

Step 4: back up and test a restore

Back up every guest to storage outside the node, copy /etc (especially /etc/pve and /etc/network/interfaces), then restore one guest to a test ID and boot it.

Step 5: run the checker

pve8to9 --full

Fix each warning and rerun until the output is clean or every remaining warning is understood. On older lines the command is pve7to8, pve6to7 or pve5to6.

Step 6: upgrade Ceph first (hyper converged only)

ceph versions
ceph osd set noout
# follow the Proxmox Ceph upgrade guide for your release here
ceph osd unset noout
ceph -s

Every daemon must report the Ceph release the target Proxmox major requires (Squid 19.2 for Proxmox VE 9) before you touch the Proxmox packages.

Step 7: move guests off the node

Migrate any guest that must stay running to another node. Remember the direction rule: old to new always works; new to old is not supported.

Step 8: switch the repositories to the new Debian release

For 8 to 9, the guide uses these commands for the legacy files, then adds the Proxmox VE 9 repository in deb822 format:

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

No-subscription example from the guide (use the enterprise stanza instead if you have a subscription):

cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

If you run Ceph, replace any ceph.com repository with the Proxmox ceph-squid repository for Trixie, as shown in the guide. Then:

apt update
apt policy

apt update must finish without errors, and apt policy should show only Trixie suites.

Step 9: run the upgrade

Use a terminal multiplexer such as tmux so a dropped SSH session does not kill the upgrade.

apt dist-upgrade

The guide says this takes under five minutes on fast SSDs and 60 minutes or more on a slow spinning disk. For changed config files it suggests keeping your /etc/issue, taking the maintainer's /etc/lvm/lvm.conf if you never edited it, and reviewing /etc/default/grub carefully.

Step 10: reboot and verify

pve8to9 --full
reboot

After the reboot:

pveversion -v
uname -r
pvecm status
qm list
pct list
pvesm status

Confirm the new kernel, quorum, active storage and that test guests start. Clear your browser cache before using the web interface. Optionally run apt modernize-sources, then start on the next node.

Common mistakes

• Upgrading Proxmox before Ceph. Each guide requires the minimum Ceph release first: Octopus before 7, Quincy before 8, Squid before 9.
• Mixing repositories. A Bookworm line left behind after switching to Trixie, a backports line, a ceph.com repository instead of the Proxmox Ceph one, or enterprise and no-subscription enabled together.
• Skipping the point release step. The checker scripts ship in the last point release (pve8to9 is in the latest 8.4 packages). Jumping straight from 8.1 to 9.0 skips both the checker and the prerequisite versions.
• Running past end of life because "Debian still gets LTS." Proxmox support follows Debian's regular security support. Debian LTS updates do not cover the Proxmox kernel, QEMU or management stack.
• No backup, or a backup never restored. Every upgrade guide puts a tested backup first.
• Upgrading over SSH with no console. NIC names can change with a new kernel. Without IPMI, iKVM or physical access, a node with a renamed interface can become unreachable.
• Ignoring the known issues list for your hardware. Kernel changes have broken specific RAID controllers, NVMe drives and server models.

FAQ

What is the latest version of Proxmox VE?

On 25 October 2026 the latest release is Proxmox VE 9.2, released on 21 May 2026 on Debian 13.5 Trixie with kernel 7.0, QEMU 11.0, ZFS 2.4 and Ceph Squid 19.2.3 or Tentacle 20.2.1. An arm64 build of 9.2 followed on 5 August 2026.

What version of Debian is Proxmox VE 9 based on?

Proxmox VE 9 is based on Debian 13 Trixie. 9.0 shipped on Debian 13, 9.1 on 13.2 and 9.2 on 13.5. Proxmox VE 8 was based on Debian 12 Bookworm and Proxmox VE 7 on Debian 11 Bullseye.

When did Proxmox VE 8 reach end of life?

The Proxmox VE FAQ lists the Proxmox VE 8 end of life as 2026-08, one month after Debian 12 Bookworm's regular security support ended on 11 July 2026. Nodes still on 8.x should move to 9.

When does Proxmox VE 9 reach end of life?

Proxmox has not published a date; the FAQ lists it as "tba". Debian 13's regular security support ends on 9 August 2028, and Proxmox support has historically ended near that point, but treat that as a planning estimate until Proxmox publishes the date.

What kernel does Proxmox VE use?

Proxmox VE ships its own kernel packages, derived for many years from Ubuntu kernels with ZFS included. 9.0 used 6.14, 9.1 moved to 6.17, and 9.2 made 7.0 the default. The 8.x line settled on 6.8 from 8.2 onward.

Can I upgrade Proxmox VE 7 directly to 9?

No in place path skips a major version. Each guide starts from the latest point release of the previous major: 7.4 to 8 with pve7to8, then 8.4 to 9 with pve8to9. For small setups, a fresh 9.2 install with guests restored from backup is often simpler.

Is the Proxmox no-subscription repository safe to use?

It is the same software, signed with the same Proxmox archive key, but the documentation says it is for testing and non production use because packages are not always as heavily tested. Many homelabs use it; for production, the enterprise repository is the recommended one.

Do I need to upgrade Ceph before upgrading Proxmox VE?

Yes, for hyper converged Ceph. Proxmox VE 9 requires Ceph 19.2 Squid before the upgrade, Proxmox VE 8 required Quincy 17.2, and Proxmox VE 7 required Octopus 15.2. Upgrade Ceph on all nodes first, then upgrade Proxmox VE node by node.

Where Safeguard fits

Safeguard's fit here is indirect, and we would rather say so plainly. The Proxmox VE host is Debian packages and Proxmox packages that you update with APT, and Safeguard does not scan or patch the Proxmox host, its kernel, its firmware or its Debian packages, and it does not track Proxmox end of life dates for you. Where Safeguard helps is one layer up: the applications and container images you build and run inside Proxmox VMs and containers. Safeguard scans repositories, container images and SBOM files for known vulnerable components, shows which projects contain a given component and version, and can open fix pull requests when a fixed version exists (autonomous remediation ships switched off by default).

A major Proxmox upgrade is often the moment teams rebuild their guests too, and every rebuilt VM or container pulls its open source dependencies and base images again, so the versions you ship after the upgrade depend on what your lockfiles and registries resolve that day. Proxmox and Debian handle the host packages, but the libraries inside your applications are yours to keep current, and that is the part the steps below cover.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, run safeguard to open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. After a Proxmox upgrade, the same flow applies to the application code you redeploy into your VMs and containers.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. A VM on a freshly upgraded Proxmox VE 9 node is a natural home for that runner, so scans of your repositories and images run on hardware you control.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. If you already ask an assistant to help plan upgrades, this is how you let it query the projects you have scanned without handing it more access than it needs.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation. For storage underneath your guests, our home NAS guide covers ZFS, snapshots and backups.

Quick check

Sources

• Proxmox VE Roadmap and release history
• Proxmox VE FAQ
• Proxmox VE: Upgrade from 8 to 9
• Proxmox VE: Upgrade from 7 to 8
• Proxmox VE: Upgrade from 6.x to 7.0
• Proxmox VE Package Repositories
• Proxmox VE Kernel
• Proxmox VE administration guide: Introduction and project history
• Proxmox VE administration guide: Host system administration
• Proxmox VE administration guide: Cluster Manager
• Proxmox VE: Secure Boot Setup
• Proxmox VE: Ceph Reef to Squid upgrade guide
• Proxmox press releases
• Proxmox downloads (current ISO installers)
• Debian releases
• Debian 13 Trixie release notes: issues to be aware of
• Ceph releases index

Last reviewed: 25 October 2026. Proxmox VE point releases, kernels, Ceph support and repository layouts change several times a year; check the release notes and upgrade guide for your exact version before you upgrade, and confirm the end of life table on the Proxmox VE FAQ.