The virtualization world has been quietly moving sideways for years. x86-64 (the dominant 64-bit PC architecture) is not going anywhere in the data center, but ARM64 (the 64-bit architecture that powers everything from phones to Ampere Altra servers) has been taking share in chunks. AWS Graviton, Azure Cobalt, the NVIDIA Grace platform, every major cloud has an ARM64 instance type now. Local hardware is following. Until recently, Proxmox VE (Virtual Environment, an open-source hypervisor that combines KVM virtualization with LXC containers under one web UI) was the one notable holdout. It ran on x86-64 only.
That changed this month. Proxmox shipped a full ARM64 build of VE alongside its existing x86-64 line. Same codebase, same release cadence, same support window. The official image boots on real ARM servers. It does not boot on the Raspberry Pi sitting on your desk, and the reason why is more interesting than the headline.
What the new build actually is
The ARM64 image is not a port. It is the same codebase compiled for a different target. The release runs on Debian 13.5 “Trixie” with a 7.0-series Linux kernel and ships the same set of virtualization primitives that the x86-64 build does: QEMU 11.0 for virtual machines, LXC 7.0 for system containers, and ZFS 2.4 for the storage layer the Proxmox installer sets up by default. Ceph (an open-source distributed storage system Proxmox supports for cluster-wide redundancy) is in there too, with the same feature parity it has on x86-64.
That last detail matters more than it sounds. Storage parity is the part of the stack most likely to diverge between architectures. The fact that ZFS and Ceph both work the same way means a workload you have already dialed in on x86-64 will behave the same way on ARM64 with no surprises in the storage path.
The build is available two ways: as a bare-metal ISO installer that you boot on real hardware, and through the package repositories for existing Debian or Proxmox hosts that want to switch architectures. Enterprise users get the pve-enterprise repository, same as on x86-64. Proxmox recommends it for production deployments, which is the company telling you that ARM64 is a tier-one target now, not an experiment.
What the supported hardware list actually says
The official support list is short and the names are specific: NVIDIA Grace and NVIDIA Vera. These are the data-center-grade ARM platforms NVIDIA has been shipping for the last two years. Proxmox validated the build jointly with NVIDIA and Supermicro, and the validation target was Grace Hopper Superchip servers. If you are running an Ampere Altra or an AWS Graviton instance, you are in adjacent territory.
Two broader buckets cover everything else:
- UEFI-based ARMv9-A hardware gets best-effort support. ARMv9-A is the current-generation ARM architecture that adds features like SVE2 (Scalable Vector Extension 2, used for high-throughput numerical work) and improved memory tagging. Most modern server-class ARM chips implement it. Proxmox has not certified every one but the boot path is the same.
- ARMv8-A hardware “generally works too.” ARMv8-A is the previous-generation 64-bit ARM architecture that ARMv9 inherits. Older Ampere Altra, most of the AWS Graviton 1/2/3 line, and a long list of dev boards sit here.
What does not work is any board that relies on a device tree blob (a small firmware file the bootloader hands to the kernel so the kernel knows what hardware exists on the board) instead of ACPI (Advanced Configuration and Power Interface, the standard x86-64 firmware table that describes hardware to the kernel). That is the Raspberry Pi. That is the Orange Pi. That is the Radxa ROCK line. That is most of what people call “single-board computers.” The device tree path is a different boot story from the ACPI path, and Proxmox chose ACPI for the ARM64 build.
Why the Pi is the wrong target anyway
Pi fans are going to push back on this. The Pi 5 has 8 GB of RAM, four Cortex-A76 cores, and a real PCIe (Peripheral Component Interconnect Express, the high-speed bus that connects CPUs to NVMe storage, network cards, and accelerators) lane for NVMe storage. On paper it looks like it should run a hypervisor. In practice it cannot run this one, and the reason is not raw capability. It is the firmware interface.
The Pi boots via a custom bootloader chain that hands the kernel a device tree. Proxmox expects ACPI tables. There is no clean bridge between the two without losing the things people buy the Pi for: low cost, low power, instant boot. By the time you write a device-tree to ACPI shim for Proxmox on the Pi, you have spent more engineering effort than the hardware is worth.
For the workloads people actually run on a Pi, LXC on Raspberry Pi OS or Debian is the right answer. You get container isolation without paying the virtualization tax. Proxmox is overkill for a single-board computer and the company is right not to pretend otherwise.
When ARM64 Proxmox is the right buy
The use case that justifies ARM64 Proxmox is the same one that justified the cloud’s move to Graviton: density per watt, and price per core. ARM cores are cheaper than equivalent x86-64 cores at the same workload, and they draw less power under load. If your workload is embarrassingly parallel, meaning many independent jobs run side by side without talking to each other much: web frontends, build servers, container workloads, edge nodes. The savings show up in the electricity bill.
Five concrete scenarios where ARM64 Proxmox earns its keep:
- A homelab operator who already runs Proxmox and wants to retire a noisy x86 box in favor of a fanless ARM server.
- A small business moving from a single VM host to a cluster and watching the per-VM cost as it grows.
- A research lab running a workload that scales horizontally and would rather pay for cores than for licensing.
- An edge-deployment shop that wants the same Proxmox web UI on-site as it has in the central data center.
- A vendor evaluating ARM64 as a build target who would rather validate on Proxmox than on bare QEMU.
None of these are workstation-class use cases. ARM64 Proxmox is for headless servers, not for the desktop.
What is still rough
Two caveats worth knowing about.
The Proxmox Backup Server ARM64 build is in internal testing but is not shipped yet. If your plan was to roll out ARM64 Proxmox and back it with Proxmox Backup Server on the same architecture, you are out of luck for now. The development team says backup server support depends on enterprise customer demand, which is a polite way of saying “if you need it, tell them.”
The validation target was NVIDIA Grace specifically. Other ARM server platforms should work but the Proxmox support team will ask you to reproduce on Grace first if you file a bug. The community has a long history of running Proxmox on hardware the company has not blessed, so this is not a hard wall, just a slower path to a fix when something breaks.
Trade-offs
Density per watt is the headline benefit. ARM cores draw meaningfully less power than x86-64 cores at the same workload. For a 24/7 server, that adds up across a year of electricity bills. For a homelab, it means a smaller UPS (uninterruptible power supply) and a quieter room.
Software maturity is the cost. ARM64 support across the Linux server space is mature but still uneven for desktop and edge use cases. If your stack has any binary-only dependencies that lack ARM64 builds, the move is a non-starter. Check before you commit.
Hardware choice is narrower. The Proxmox blessed path is NVIDIA Grace and Vera. The next tier is “best effort on UEFI ARMv9-A.” That is still a smaller menu than the x86-64 world, where any consumer motherboard from the last decade will run Proxmox.
Validation coverage is thinner. If you hit a bug on Ampere Altra, the Proxmox team will ask you to reproduce on Grace. Bug fixes land faster when the team has a hardware target in front of them.
Bottom line
If you are running Proxmox on x86-64 today and your workload is embarrassingly parallel, ARM64 Proxmox is a real option and the maturity is finally there. The same codebase, the same web UI, the same ZFS and Ceph. You get the cost savings without giving up the toolchain.
If you are running a Raspberry Pi homelab and hoping to upgrade to Proxmox on the same hardware, this is not that announcement. The Pi does not boot the ARM64 image and the company is not pretending it will. Stick with LXC on Pi OS for that setup. It is the right tool for the Pi class.
For everyone in between, the practical move is to spin up an ARM64 Proxmox test instance on a cloud Graviton box, migrate a non-production workload, and see what breaks. Most workloads will be boring. The few that break will teach you something useful about how the move will land in your environment.