Proxmox ARM64: o que muda para PMEs e o que ainda depende de x86

“O hipervisor segue a arquitetura, mas o problema da sua PME não mudou de arquitetura.”

Em 05 de agosto de 2026, a Proxmox anunciou o que a comunidade pedia há quase uma década: a primeira release oficial do Proxmox VE para 64-bit ARM (arm64/aarch64). Não é um experimento, não é um port comunitário — é a arquitetura oficialmente suportada, com o mesmo ciclo de vida das builds x86-64.

E aqui vai a pergunta que interessa para quem trabalha com micro e pequena empresa: isso muda alguma coisa para você?

A resposta curta: sim, mas não da forma que os títulos de blog sugerem. Enquanto o hype fala em “Raspberry Pi rodando Proxmox”, a realidade é que o suporte oficial é para servidores enterprise ARM. A boa notícia é que, para a PME certa, essa release abre um caminho real de economia energética e simplicidade — desde que você saiba exatamente o que roda e o que não roda em ARM.

Eu vou te mostrar os fatos, as tabelas comparativas e o cenário real para a PME brasileira. Sem promessa mágica, com os pés no chão — como sempre faço aqui no blog.

O que é oficial de verdade

Deixa eu começar desfazendo o mal-entendido mais comum: o suporte ARM64 do Proxmox não é o “Proxmox no Raspberry Pi”.

O Proxmox VE 9.2 para arm64 é uma release completa, construída sobre Debian 13.5 “Trixie”, com Linux kernel 7.0 como padrão estável, QEMU 11.0, LXC 7.0 e ZFS 2.4. Compartilha o mesmo código-fonte, repositórios e ciclo de releases da versão x86-64.

A validação de lançamento foi feita em hardware NVIDIA Grace Hopper, em colaboração com a própria NVIDIA e a Supermicro — ou seja, plataforma de datacenter de verdade, não placa de desenvolvimento.

E o ponto central que muita gente não lê: a Proxmox garante suporte total em duas plataformas ARM específicas (NVIDIA Grace e NVIDIA Vera). Todo o resto é “best-effort”. Isso muda completamente a conversa para quem está pensando em produção.

Paridade completa de features

A primeira pergunta que qualquer administrador de Proxmox faz: “vou perder recurso por rodar em ARM?”

Não. Essa é a parte mais impressionante da release. A Proxmox não entregou uma versão capada. A paridade de features com a build x86-64 é completa:

Em outras palavras: você gerencia um nó ARM64 com a mesma interface, mesmos conceitos e mesmos workflows que um servidor x86 da Dell ou da Supermicro. A arquitetura embaixo muda; a experiência de gestão não.

Para quem já é acostumado com o ecossistema, vale lembrar que ZFS e Ceph receberam um destaque especial no anúncio — foram otimizados e validados para entregar a mesma performance e confiabilidade das implantações x86. Se você acompanha o blog, sabe o quanto eu bato nessa tecla de storage: ver ZFS e Ceph funcionando em ARM no primeiro release oficial é um sinal forte de maturidade.

O que muda na arquitetura

Aqui é onde a engenharia aparece. O ARM64 tem diferenças reais de arquitetura que você precisa conhecer antes de planejar qualquer coisa:

Dois pontos merecem atenção especial para quem planeja produção:

1. Migração live é restrita por arquitetura. Você só consegue migrar a quente entre nós ARM64. Não existe migração cross-architecture (x86 → ARM) e, na prática, clusters mistos x86 + ARM não são suportados oficialmente. Se você tem um cluster Proxmox hoje em x86, o ARM64 não entra nele — é um ambiente separado.

2. A VM precisa ser reinstalada/reconfigurada. Os dados de um guest podem ser movidos via migração offline, backup e restore ou storage compartilhado — mas o sistema operacional precisa ser reinstalado para a nova arquitetura. Não existe “só mover a VM para o ARM”. Isso é decisivo para quem sonha em migrar o parque atual para ARM.

Hardware: o que é suportado (e o que não é)

Essa tabela é a mais importante de todo o artigo, porque alinha expectativa com realidade:

O requisito técnico é simples e implacável: o host precisa bootar via UEFI e descrever o hardware via ACPI. SBCs como Raspberry Pi usam device-tree e boot legado — por isso ficam de fora oficialmente.

A comunidade, como sempre, já está furando essa bolha: há relatos de instalação manual no Raspberry Pi 5, no Orange Pi 5 Plus (com firmware UEFI EDK2) e até no Raspberry Pi 4. Funciona para laboratório e POC, mas eu não colocaria um negócio de cliente em cima disso. O Jeff Geerling, que testou num Ampere Altra Max de 128 núcleos, relatou que a instalação foi tranquila mas encontrou instabilidade com VMs Ubuntu em ARMv8. Ou seja: best-effort é exatamente isso — pode funcionar, mas você está por sua conta.

Workloads de PME: o que roda em ARM (a tabela que importa)

Vamos ao que realmente interessa para micro e pequena empresa. Depois de separar hype de realidade, o que sobra de útil?

✅ Roda nativamente em ARM (ecossistema maduro)

⚠️ Roda com ressalvas

❌ Dependem de x86 (não rodam em host ARM)

Aqui vale uma nuance importante do mercado brasileiro: muitos ERPs de PME hoje são SaaS (Omie, Bling, Tiny, Conta Azul). Esses rodam no navegador e são agnósticos de arquitetura — o que facilita adotar ARM para a infraestrutura por trás deles. O problema concentra-se no legado on-prem Windows e nas integrações com DLL/EXE de bancos e contadores. É exatamente onde a consultoria precisa ser honesta com o cliente.

O cenário da PME brasileira

Com as tabelas acima, o desenho para uma PME brasileira começa a fazer sentido. E ele não é “substituir tudo por ARM” — é usar ARM onde a conta fecha.

O argumento da energia

Se você acompanha meus artigos sobre failover inteligente e redundância de link para escritório e loja, sabe que eu vivo falando de infraestrutura que funciona sem dor de cabeça. Energia é um capítulo novo e silencioso desse livro.

A física é simples: um servidor torre ou 1U x86 ocioso puxa 150-250W médios, enquanto um nó ARM de entrada roda na faixa de 10-20W. Em 24/7/365, isso é a diferença entre 1.000 a 2.000 kWh por ano. Com a tarifa brasileira — que continua subindo com bandeiras tarifárias — é a diferença entre centenas e mais de mil reais por ano, por servidor, só de energia.

A honestidade técnica, porém, exige o contraponto: um nó ARM não substitui um Xeon em capacidade. A economia grande não está em trocar um servidor parrudo por uma placa — está em consolidar ou eliminar servidores x86 ociosos e hospedar os workloads sempre-on em ARM. DNS, monitoramento, filas, VPN, containers pequenos: esses rodam 24/7 e não precisam de potência — precisam de eficiência.

O sinal que vem da nuvem

Se você ainda acha que ARM é nicho, olhe para as maiores clouds do planeta: AWS Graviton, Oracle Ampere A1, Azure Cobalt, Google Axion. Todos os quatro gigantes têm linha ARM em produção, e a Oracle oferece o famoso Always Free com 4 OCPU + 24 GB de RAM — uma infraestrutura off-site de custo praticamente zero para backup remoto, monitoramento ou site institucional.

Quando os quatro maiores provedores de nuvem têm ARM em produção há anos, o ecossistema de software Linux/arm64 já está maduro: Ubuntu, Debian, Rocky e AlmaLinux têm builds arm64 oficiais, e o Docker Hub é multi-arch na maioria das imagens. O gargalo não é mais falta de imagem — é Windows e software proprietário.

O caminho realista (híbrido)

Para a PME brasileira, o cenário que eu considero defensável hoje:

O anti-padrão — e eu preciso ser direto aqui — é tentar usar ARM como plataforma única que substitui o servidor Windows/ERP do cliente. Isso quebra no primeiro software de linha. ARM é complemento estratégico, não substituto universal.

Se você está avaliando migração de virtualização, vale ler meu guia de análise de custos e ROI VMware vs Proxmox — o mesmo rigor de análise vale aqui, somado à questão da arquitetura.

Como começar (sem gastar com o que não precisa)

Se você se convenceu que ARM faz sentido para algum workload da sua PME, o caminho prático é este:

1. Comece pelo sempre-on. DNS, monitoramento, filas e containers de apoio são os candidatos naturais — não toque no que é crítico primeiro.
2. Valide num SBC primeiro. Um Raspberry Pi 5 ou Orange Pi 5 Plus serve para POC e aprendizado — com a ressalva de que é laboratório, não produção.
3. Separe os ambientes. ARM64 e x86 não vivem no mesmo cluster. Planeje os dois como infraestruturas independentes.
4. Use a nuvem para aprender ARM — mas não para o Proxmox. A free tier da Oracle (Ampere A1) é ótima para rodar workloads ARM64 reais sem custo: containers, Zabbix, backup remoto. Porém, o OCI não expõe virtualização aninhada (/dev/kvm) nem boot UEFI/ACPI, então o Proxmox VE não roda na nuvem da Oracle — nem em ARM, nem em x86. Para testar o Proxmox ARM64, você precisa de hardware físico: um servidor UEFI ARMv9 ou um SBC como laboratório.
5. Mantenha o x86 para o que precisa. Windows, ERP e softwares de linha continuam em x86 — sem culpa, sem drama.

E aqui vai o lembrete que vale para qualquer decisão de infraestrutura: a arquitetura muda, mas o princípio não. Você não decide por hype; decide por workload, por custo total e por capacidade de sustentar. O planejamento de redundância que eu defendo para qualquer projeto se aplica do mesmo jeito — ARM ou x86, sem pular etapas.

Conclusão

O Proxmox ARM64 é uma das mudanças mais relevantes no mundo da virtualização open source em anos. É uma release madura, com paridade de features e suporte oficial em hardware enterprise de verdade.

Mas para a PME brasileira, a leitura correta é outra: ARM não é o futuro que substitui tudo — é uma ferramenta a mais para fazer mais com menos. No momento certo, para os workloads certos, ele reduz energia, simplifica e corta custo. Usado como “substituto universal”, vira dor de cabeça.

O papel de quem entrega tecnologia para PME — e eu incluo aqui qualquer consultor que atenda o mercado brasileiro — é saber separar as duas coisas. É olhar para a tabela de workloads, não para o título do hype.

A infraestrutura certa não é a mais nova. É a que você consegue sustentar com a conta no azul.