VPS ARM ou x86: o que muda na prática

O que muda quando passa para um VPS ARM

Um VPS ARM utiliza o mesmo Linux e o mesmo Nginx que um VPS x86 e, normalmente, custa menos por core. O risco da mudança está na compatibilidade. Um programa compilado para x86-64 não pode ser executado em arm64, pelo que todos os componentes da sua stack têm de disponibilizar uma versão arm64 ou permitir uma recompilação.

A maioria das stacks modernas passa este teste sem trabalho adicional. Os problemas concentram-se em dois pontos: imagens de contentores que só foram criadas para uma arquitetura e software de código fechado sem download para arm64. Os comandos abaixo respondem às duas questões para a sua própria stack antes de pagar por uma instância. Se ainda estiver a determinar que tipo de servidor precisa, comece por o que é um VPS e em que difere do alojamento partilhado.

arm64, aarch64, amd64: o que significa cada nome

Execute estes comandos em qualquer instância antes de fazer qualquer outra coisa.

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

uname -m exibe aarch64 numa máquina ARM e x86_64 numa máquina Intel ou AMD. dpkg --print-architecture exibe arm64 e amd64 nessas mesmas duas máquinas. As duas respostas estão corretas. O kernel Linux e o sistema de pacotes Debian escolheram nomes diferentes para o mesmo conjunto de instruções. Por isso, aarch64 e arm64 significam uma coisa, enquanto x86_64 e amd64 significam a outra. O Docker usa os nomes no estilo Debian, e é por isso que a plataforma de uma imagem aparece como linux/arm64.

Em arm64, não existe uma linha model name em /proc/cpuinfo. Em vez disso, existe um campo Features, e a criptografia por hardware aparece nele como flags, como aes pmull sha1 sha2. Essas são as extensões criptográficas do ARMv8. Elas fazem o mesmo que o AES-NI nos processadores Intel e AMD: aceleram por hardware o TLS (transport layer security) e a criptografia de discos. Verificar a aceleração de hardware AES numa VPS explica como fazer o teste nas duas arquiteturas.

Porque os contentores falham primeiro e como é o erro

Cada manifesto de uma imagem Docker regista a arquitetura para a qual foi compilada. Extraia para um host arm64 uma imagem que tenha apenas um manifesto amd64. A extração é concluída. A falha ocorre quando o primeiro processo é iniciado:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error é o kernel a recusar executar o ficheiro, porque o cabeçalho ELF (executable and linkable format) indica um tipo de máquina que este CPU não implementa. Nenhuma definição corrige isto. As instruções não existem no silício.

Verifique o manifesto antes de fazer o deploy:

docker buildx imagetools inspect nginx:1.27

A saída apresenta uma linha Platform: por imagem no manifesto, como linux/amd64 e linux/arm64. Se linux/arm64 estiver ausente, essa tag não será iniciada numa VPS ARM. docker manifest inspect --verbose nginx:1.27 apresenta a mesma informação, mas a documentação do Docker classifica docker manifest como um comando experimental cujo comportamento pode mudar entre releases. Por isso, prefira imagetools.

Para as imagens que compila, compile as duas arquiteturas num único comando e faça push de uma lista de manifestos:

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

A compilação para uma arquitetura diferente num único host precisa da emulação QEMU em modo de utilizador, registada no kernel pelo handler binfmt_misc:

docker run --privileged --rm tonistiigi/binfmt --install all

Use a emulação para compilar e testar. Não a use para servir tráfego. A documentação do Docker afirma que a emulação com QEMU "can be much slower than native builds, especially for compute-heavy tasks like compilation and compression or decompression", portanto um serviço x86 emulado numa instância ARM elimina a poupança que motivou a mudança. A configuração do host para o caso nativo é idêntica nas duas arquiteturas: executar o Docker numa VPS explica esse procedimento, e um ficheiro Compose existente funciona sem alterações quando todas as imagens utilizadas têm um manifesto arm64.

Os pacotes de que preciso existem para arm64?

O Ubuntu e o Debian compilam quase todo o arquivo para arm64, por isso apt install nginx postgresql redis-server funciona da mesma forma nas duas arquiteturas. As lacunas encontram-se principalmente nos repositórios de terceiros.

Consulte diretamente o apt na instância ARM:

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

A mensagem apt-cache policy com Candidate: (none) significa que nenhum repositório ativado publica uma compilação desse pacote para esta arquitetura. apt-get install -s simula a instalação e não escreve nada. No mesmo caso, termina com E: Unable to locate package.

Leia também a saída de apt update em vez de a ignorar. Um repositório de fornecedor disponível apenas para amd64 indica isso:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

O repositório está configurado e acessível, mas não contém nada que esta máquina possa instalar. Verifique também a própria entrada da origem. Uma linha fixada com [arch=amd64] é ignorada num host arm64. Nesse caso, o pacote parece estar em falta, mas a causa real é a fixação.

Quais cargas de trabalho são seguras e quais exigem uma verificação prévia

Runtimes interpretados e de bytecode são portáveis por definição. PHP, Python, Ruby e Node.js têm pacotes arm64 nas principais distribuições. Go e Rust fazem compilação cruzada para arm64 com a definição de um único destino. Uma stack LEMP, uma API Node, um binário Go atrás do Nginx ou uma base de dados Postgres são tarefas comuns em arm64.

Um compilador just in time (JIT) produz código de máquina enquanto o programa é executado, por isso precisa de um gerador de código para a arquitetura de destino. As versões atuais têm esse suporte: OpenJDK, .NET, o motor V8 do Node.js e PyPy suportam arm64 no Linux. As versões antigas fixadas são o verdadeiro risco. Um script de deploy que instala uma versão de runtime lançada há vários anos deve ser verificado nas notas dessa versão quanto ao suporte para aarch64, em vez de se assumir que funciona.

As bibliotecas que incluem assembly x86 escrito manualmente, ou intrínsecos SSE e AVX, são o caso menos evidente. A maioria também tem um caminho NEON (NEON é o conjunto de instruções vetoriais do ARM) ou um fallback em C simples, por isso compila e funciona. O desempenho pode ser diferente do da compilação x86 em qualquer direção. Meça-o na sua instância, em vez de o prever com base num artigo.

Software de código fechado é o verdadeiro bloqueio. Um agente de monitorização do fornecedor, um driver de base de dados licenciado, um painel de controlo comercial ou um daemon de antivírus é fornecido como um binário compilado. Quando o fornecedor não publica uma compilação arm64, não há nada que possa fazer. cPanel e WHM é o caso mais claro no alojamento: os requisitos de sistema indicam x86_64 e não listam ARM, por isso um servidor com painel de controlo permanece em x86 (verificado em August 2026 e vale a pena reler na página de requisitos do próprio fornecedor). Se essa for a única coisa que o impede de avançar, as alternativas ao cPanel que vale a pena executar num VPS são o ponto de partida. Verifique o suporte de arquitetura de cada uma da mesma forma.

Kernels e tamanho de página: onde as instâncias ARM ainda diferem

Os servidores x86-64 são quase intercambiáveis. Os servidores ARM são menos uniformes, e as diferenças estão abaixo da aplicação.

O tamanho de página é a diferença que chega à produção. A maioria dos kernels arm64 usa páginas de 4 KiB, tal como o x86-64. Alguns usam 64 KiB. O Red Hat Enterprise Linux 8 para aarch64 incluía por predefinição um kernel com páginas de 64 KiB, e o RHEL 9 voltou a usar 4 KiB por predefinição, mantendo um pacote kernel-64k separado para cargas de trabalho que necessitam do tamanho maior. Um tamanho de página de 64 KiB aumenta o consumo mínimo de memória de um processo com muitos mapeamentos pequenos, porque o menor bloco que o kernel pode fornecer é dezasseis vezes maior. Execute getconf PAGESIZE na instância e leia o valor, em vez de o presumir. O tamanho de página não é a única decisão do kernel que o afeta, porque a versão disponibilizada pelo fornecedor também determina como o trabalho é distribuído pelos núcleos, e o escalonamento consciente da cache adicionado no Linux 7.2 está disponível tanto em arm64 como em x86-64.

Vale a pena conhecer algumas diferenças menores. Não existe em arm64 um pacote de microcódigo da CPU para o sistema operativo, por isso as atualizações de firmware vêm do fornecedor, e não do apt. Os servidores ARM arrancam através de UEFI (unified extensible firmware interface) e descrevem o hardware através de ACPI (advanced configuration and power interface). Algumas funcionalidades do x86 não têm qualquer equivalente em ARM, incluindo a encriptação de memória AMD SEV e as GPUs mediadas Intel GVT-g.

A plataforma de servidores ARM amadureceu?

No lado do software, sim. Debian, Ubuntu, Fedora e RHEL disponibilizam versões arm64 de primeira linha, e as imagens oficiais no Docker Hub são, por norma, multi-arquitetura.

A evidência recente mais clara é o Proxmox. Em 5 August 2026, o Proxmox anunciou a primeira edição arm64 oficialmente suportada do Proxmox Virtual Environment, versão 9.2, partilhando os repositórios de pacotes e o ciclo de lançamento com a edição x86-64. É baseada no Debian 13.5, com Linux 7.0, QEMU 11.0, LXC 7.0 e ZFS 2.4. A configuração e as ferramentas correspondem às da versão x86-64, exceto por um pequeno conjunto de itens específicos da arquitetura.

Leia as ressalvas desse mesmo anúncio, porque mostram como o hardware de servidores ARM oficialmente suportado ainda é limitado. O Proxmox validou sistemas NVIDIA Grace e NVIDIA Vera no primeiro dia, após testes conjuntos com a NVIDIA e a Supermicro em hardware Grace Hopper. Os restantes equipamentos UEFI baseados em ARMv8-A e ARMv9-A têm suporte de melhor esforço. Computadores de placa única, como o Raspberry Pi, que dependem exclusivamente de device tree, não são suportados. Uma máquina virtual só é executada num nó da mesma arquitetura. A migração em tempo real funciona apenas entre nós da mesma arquitetura. Clusters com arquiteturas mistas não são oficialmente suportados.

Essa é a situação real em August 2026. Um fornecedor de hipervisores disponibilizar arm64 com o mesmo ciclo de vida de x86-64 representa um avanço concreto para a plataforma. A lista de hardware suportado desde o primeiro dia inclui duas famílias de CPUs.

Uma lista de verificação para executar antes de se comprometer

1. Execute uname -m numa instância de teste e confirme que apresenta aarch64.
2. Execute docker buildx imagetools inspect em cada imagem do seu ficheiro Compose e confirme uma linha de plataforma linux/arm64 para cada uma.
3. Execute apt update na instância ARM e leia todos os avisos Skipping acquire apresentados.
4. Abra a página de download de cada agente de código fechado de que depende e procure pelo nome uma compilação arm64 ou aarch64.
5. Execute getconf PAGESIZE e registe a resposta antes de dimensionar a memória.
6. Execute o seu próprio benchmark tanto no plano ARM como no plano x86 entre os quais está a escolher.

O que este artigo não afirma

Não vamos fornecer uma relação preço/desempenho entre ARM e x86. Os preços por núcleo variam conforme o fornecedor e o plano, e um valor medido no hardware de outra pessoa não permite prever o seu. Meça em vez disso. O nosso guia de benchmarking de um VPS aborda sysbench e fio com um método que pode repetir, e quanto custa realmente um VPS aborda a componente de preços da comparação. O armazenamento é uma decisão separada da arquitetura da CPU, e como o NVMe se compara com um SSD SATA num VPS trata dessa parte. Execute o mesmo teste nos dois planos, usando a sua própria carga de trabalho sempre que possível, e deixe os seus números decidir.

FAQ

Os meus contentores Docker vão funcionar num VPS ARM?

Funcionam se todas as imagens da stack tiverem uma entrada linux/arm64 no respetivo manifesto. Verifique cada imagem com docker buildx imagetools inspect <image> e procure uma linha Platform: linux/arm64. As imagens oficiais no Docker Hub são normalmente multi-arch. As imagens de fornecedores mais pequenos e as imagens que criou num computador x86 muitas vezes não são. Para as suas próprias imagens, faça uma nova build com docker buildx build --platform linux/amd64,linux/arm64 ... --push para que uma tag sirva ambas as arquiteturas.

O que significa exec format error num servidor ARM?

O kernel tentou executar um binário cujo cabeçalho ELF indica um tipo de máquina diferente e recusou a execução. Num host arm64, isto significa quase sempre um binário x86-64 ou uma imagem de contentor x86-64. O Docker apresenta primeiro um aviso a indicar que a plataforma de imagem solicitada, linux/amd64, não corresponde à plataforma detetada no host, linux/arm64/v8. A correção é fazer uma build para a arquitetura correta. Nenhuma alteração de configuração permite executar nativamente um binário x86-64 em ARM.

arm64 é a mesma coisa que aarch64?

Sim. São dois nomes para o conjunto de instruções ARM de 64 bits. O kernel comunica aarch64 através de uname -m, enquanto os pacotes de Debian e Ubuntu e as strings de plataforma do Docker usam arm64. A mesma diferença existe no outro lado: uname -m indica x86_64 e os pacotes usam amd64. Se uma página de downloads disponibilizar apenas ficheiros aarch64, esses são os ficheiros corretos para uma máquina que dpkg --print-architecture identifica como arm64.

Um VPS ARM é mais rápido do que um VPS x86?

Não existe uma resposta geral para essa pergunta. Qualquer proporção que leia foi medida em hardware diferente do seu. A velocidade depende do modelo específico do CPU, do número de cores que lhe são atribuídos, da forma como o fornecedor gere a contenção entre tenants e da eficiência com que a sua carga de trabalho utiliza instruções vetoriais. Faça benchmark dos dois planos que está efetivamente a considerar, usando a sua própria carga de trabalho se possível, e compare os resultados.

O que devo verificar antes de migrar um servidor de produção para arm64?

Faça quatro verificações, por esta ordem. Confirme que todas as imagens de contentores têm um manifesto arm64. Confirme que todos os repositórios apt de terceiros publicam binary-arm64. Confirme que todos os agentes de código fechado disponibilizam um download aarch64. Depois, execute getconf PAGESIZE na instância de destino, porque um kernel com páginas de 64 KiB altera a utilização de memória de processos com muitos mapeamentos pequenos. Qualquer falha numa destas quatro verificações é motivo para manter esse servidor específico em x86.