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:
| Feature | x86-64 | ARM64 |
|---|---|---|
| Máquinas virtuais (KVM) | ✅ | ✅ |
| Containers LXC | ✅ | ✅ |
| Gestão de storage (ZFS, LVM, diretórios) | ✅ | ✅ |
| Ceph (HCI storage) | ✅ | ✅ |
| Software-defined networking | ✅ | ✅ |
| Clustering | ✅ | ✅ |
| Alta disponibilidade (HA) | ✅ | ✅ |
| Backup integrado | ✅ | ✅ |
| Interface web de gestão | ✅ | ✅ |
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:
| Aspecto | x86-64 | ARM64 |
|---|---|---|
| Boot das VMs | UEFI (OVMF) ou SeaBIOS | Sempre UEFI (AAVMF/OVMF ARM). Sem SeaBIOS |
| Criptografia de memória | AMD SEV disponível | Não disponível |
| vGPU mediada | Intel GVT-g disponível | Não disponível |
| Microcode de CPU | intel-microcode / amd64-microcode |
Não existe |
| Migração live | x86 → x86 | Somente ARM → ARM |
| Guest em nó de outra arquitetura | N/A | Não roda |
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:
| Hardware | Status oficial | Notas |
|---|---|---|
| NVIDIA Grace Hopper | ✅ Totalmente suportado | Validado no lançamento (joint testing com NVIDIA/Supermicro) |
| NVIDIA Vera | ✅ Totalmente suportado | Mesma validação |
| Servidores UEFI ARMv9-A (outros fabricantes) | ⚠️ Best-effort | Geralmente funciona, sem garantia oficial |
| Servidores ARMv8-A (ex: Ampere Altra) | ⚠️ Best-effort | Funciona, mas com relatos de instabilidade |
| Raspberry Pi (device-tree) | ❌ Não suportado | Não atende ao requisito UEFI + ACPI |
| Single-board computers (Orange Pi, etc.) | ❌ Não suportado | Idem — device-tree only |
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)
| Categoria | Exemplos | Observação |
|---|---|---|
| DNS / DHCP | Pi-hole, AdGuard Home, BIND, Unbound, Kea | Carga trivial, uso clássico |
| Monitoramento | Zabbix, Prometheus, Grafana, Telegraf | Todos com build arm64 oficial |
| Arquivos | Samba, NFS | Excelente; atenção à placa de rede |
| Containers | Docker, Podman, k3s | Maioria das imagens oficiais é multi-arch |
| Bancos leves | PostgreSQL, MariaDB | Arm64 oficial; suficiente p/ bancos pequenos |
| Filas / mensageria | Redis, RabbitMQ, BullMQ | Arm64 ok |
| VPN | WireGuard, Tailscale, OpenVPN | WireGuard é nativo no kernel — perfeito |
| Web / reverso | Nginx, Caddy, Traefik, Node.js | Sem problema algum |
| Git / CI | Gitea, GitLab, runners arm64 | Ok |
| Backup / sincronização | Restic, Borg, MinIO | Ok |
⚠️ Roda com ressalvas
| Categoria | Exemplos | Ressalva |
|---|---|---|
| Nextcloud | File sync | Funciona, mas performance modesta em ARM de entrada |
| Kubernetes | k3s | Funciona, mas exige RAM e NVMe decentes |
| E-mail completo | MX + webmail | Possível, mas prefiro em VM/cloud dedicada |
❌ Dependem de x86 (não rodam em host ARM)
| Categoria | Exemplos |
|---|---|
| Windows Server / desktop | Qualquer VM Windows em host ARM é inviável |
| ERPs legados on-prem | Sistemas em .NET Framework, ASP clássico, softwares de NFe/PDV Windows |
| SQL Server | Roda em Linux, mas somente x86_64 |
| Softwares de linha / proprietários | Backup corporativo, antivírus, agentes de suporte, integrações com bancos/contadores |
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:
| Papel | Arquitetura | Por quê |
|---|---|---|
| Servidor de escritório Linux (DNS, arquivos, containers, monitoramento) | ARM | Workloads sempre-on, baixo consumo, simplicidade |
| Monitoramento de clientes (perfil consultoria) | ARM | Nó em cada cliente enviando métricas para central — barato e eficiente |
| Edge / filial de varejo | ARM | DNS local + cache + arquivos, tolerante a queda de link |
| VMs pequenas Linux (web, banco leve, filas) | ARM | LXC/VMs arm64 suficientes para a carga |
| Windows, ERP legado, SQL Server | x86 | Não há outra opção realista |
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:
- Comece pelo sempre-on. DNS, monitoramento, filas e containers de apoio são os candidatos naturais — não toque no que é crítico primeiro.
- 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.
- Separe os ambientes. ARM64 e x86 não vivem no mesmo cluster. Planeje os dois como infraestruturas independentes.
- 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. - 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.