Two stories this week. One expands what community infrastructure can run on. The other reminds you what happens when you don't patch it.

Proxmox VE 9.2 for Arm64

On August 5, Proxmox Server Solutions announced the first officially supported Arm64 edition of Proxmox Virtual Environment. This is not a community port. It shares the same codebase, package repositories, and release lifecycle as the x86-64 edition, with full feature parity across KVM, LXC, ZFS, and Ceph. Built on Debian 13.5 "Trixie" with Linux 7.0.

The press release leads with NVIDIA Grace and Vera CPU validation — done in collaboration with NVIDIA and Supermicro. That tells you who funded the engineering work. But the side effect is what matters for community infrastructure: Ampere Altra, and other Arm server boards that use standard UEFI/ACPI boot, now have a serious hypervisor with a real support lifecycle behind them.

Jeff Geerling tested it on an Ampere Altra Max developer platform and the install was straightforward — flash the ISO, boot, run the graphical installer. No device-tree hacking, no SBC-specific builds. The Ampere Altra uses UEFI/ACPI, so Proxmox's standard installer works.

What's officially supported vs. what actually works

Official support is scoped to NVIDIA Grace Hopper and Vera platforms. For everything else:

  • Best-effort support on UEFI-based ARMv9-A or newer hardware (ARMv8-A generally works too, also best-effort)
  • The host must boot through UEFI and describe hardware through ACPI
  • Device-tree-only SBCs (Raspberry Pi, most Rockchip boards) are not supported

"Not supported" is not the same as "doesn't work." Within hours of the announcement, people had it running on Raspberry Pi 4 via the pftf UEFI firmware, and on Pi 5 by installing manually on top of Pi OS 13 (Trixie) with NetworkManager and cloud-init disabled. The UEFI firmware projects for Pi 4 and Pi 5, and the edk2 port for Rockchip RK3588 boards, are the path for SBC enthusiasts. For production community deployments, stick to UEFI/ACPI hardware where the standard installer works.

Why this matters for community infrastructure

Arm servers change the economics of community-hosted infrastructure in three ways:

  1. Power efficiency. Ampere Altra draws significantly less power than comparable x86 hardware. For a fire hall running a server in a closet, or a community center with limited electrical capacity, lower wattage is the difference between "we can run a server here" and "we can't."

  2. Hardware cost. Used Arm server hardware is getting cheaper. Ampere Altra developer platforms, SolidRun Clearfog systems, and even high-end SBC clusters are available at price points well below used Dell R630s. Proxmox on Arm64 means these aren't just Linux boxes — they're hypervisor nodes with LXC, clustering, ZFS, and the same management interface operators already know.

  3. The same operational model. This is the key point. A community operator who learned Proxmox on x86 can operate Proxmox on Arm64 without retraining. The web UI, the clustering, the backup workflow, the LXC container management — it's the same. The only thing that changes is the hardware underneath. For organizations standardizing on Proxmox (which is what we recommend), the architecture choice is now a hardware procurement decision, not a platform migration.

What doesn't work yet

Being honest about the gaps:

  • No x86 VMs on Arm. You can't run x86 guest VMs on an Arm64 host. If your community's existing infrastructure is x86 VM images, you're rebuilding from containers or ARM-native images. LXC containers running ARM Linux are straightforward. VMs need ARM-compatible guest OS images.
  • Software compatibility. Most server software is available for arm64 — Linux distributions, Docker, Nextcloud, Matrix, Postgres, Keycloak, Gitea. But some niche tools, closed-source agents, and older software may lack arm64 builds. Test your stack before committing.
  • Support is NVIDIA-first. If you're running Ampere Altra or a UEFI SBC, you're on best-effort. The forums will sort out what works over the next few weeks. For a community deployment where you control the hardware and can test before committing, best-effort is acceptable. For production with an SLA, buy an enterprise support contract and run on validated hardware.

The practical takeaway

If you're planning a new community infrastructure deployment, Arm64 is now a viable platform for Proxmox. Not a curiosity. A platform with the same feature set, the same management interface, and lower power consumption. The hardware compatibility list will grow. The forum threads over the next month will tell you which boards boot cleanly and which ones need workarounds.

For existing x86 Proxmox deployments: nothing changes. Your clusters keep working. This is additive, not a migration. The value is in the next deployment, not the current one.

Patch Your Gitea: CVE-2026-59774

Same week Proxmox expanded the platform, Gitea disclosed a vulnerability that reminds you why self-hosting means owning the patch cycle too.

CVE-2026-59774, rated CVSS 9.8, was disclosed August 2. An unauthenticated attacker can hit the markup rendering endpoint on any public repository, submit Org-mode markup with an #+INCLUDE directive pointing at an absolute path, and read arbitrary files accessible to the Gitea service account. The root cause: Gitea initialized the go-org library without overriding its default ReadFile callback. Versions 1.22.1 through 1.27.0 are affected. Fixed in 1.27.1.

File read is bad. The escalation path is worse. Gitea's own advisory walks through it:

  1. Read app.ini from the filesystem.
  2. Extract INTERNAL_TOKEN from the config.
  3. Inject a Git hook through the internal logger API using the stolen token.
  4. Trigger the hook during an anonymous clone.

That's remote code execution with three extra steps. If your Gitea instance has even one public repository and a route to the internet, treat this as an active exploit path.

What to do

  1. Update Gitea to 1.27.1 immediately. If you're running 1.22.1–1.27.0, you're vulnerable.
  2. Rotate INTERNAL_TOKEN after patching. If the token was read before you patched, the attacker has it. Rotating it invalidates any stolen token.
  3. Audit access logs for requests to the markup rendering endpoint (/api/v1/markup or similar) from unauthenticated sources. If you see requests with Org-mode #+INCLUDE directives, assume compromise and investigate further.
  4. Restrict network access to Gitea if possible. If Gitea is only used internally, put it behind a VPN or restrict it to LAN access. Public repositories with markup rendering enabled are the attack surface.

The broader point

This is the same point we made about Synapse's 11 CVEs last month. Self-hosting means you own the patch cycle — both the responsibility and the control. When Gitea has a 9.8, you can read the advisory, understand the exploit path, patch on your schedule, and verify the fix. When a vendor has a vulnerability in their hosted Git service, you find out when they tell you, if they tell you, and you take their word that it's fixed.

The operational burden is real. It's also the point.

Two Stories, One Principle

Proxmox on Arm64 expands what you can build. Gitea's CVE reminds you what building it requires. The tools are getting better and the platform is getting wider. The responsibility stays where it's always been: with the operator who chose to own their infrastructure.

For the communities we work with: Arm64 is now a real option for your next Proxmox node. And if you're running Gitea, update it tonight.