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

O que muda ao migrar para uma VPS ARM

Uma VPS ARM executa o mesmo Linux e o mesmo Nginx que uma VPS x86, e geralmente custa menos por núcleo. O risco na migração é a compatibilidade. Um programa compilado para x86-64 não pode ser executado em arm64, portanto, cada componente da sua stack precisa disponibilizar uma versão arm64 ou permitir que você a recompile.

A maioria das stacks modernas passa neste teste sem esforço adicional. As falhas concentram-se em dois pontos: imagens de contentores que foram compiladas apenas para uma arquitetura e software de código fechado sem download para arm64. Os comandos abaixo respondem a ambas as questões para a sua stack antes de pagar por uma instância. Se ainda está a avaliar que tipo de servidor necessita, comece por o que é uma VPS e como difere do alojamento partilhado.

arm64, aarch64, amd64: o que cada nome significa

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

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

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

No arm64, não existe uma linha model name no ficheiro /proc/cpuinfo. Em vez disso, obtém um campo Features, onde a criptografia de hardware aparece sob a forma de flags como aes pmull sha1 sha2. Estas são as extensões criptográficas ARMv8, que desempenham a mesma função que o AES-NI nos processadores Intel e AMD: aceleram o TLS (transport layer security) e a encriptação de disco via hardware. Verificar a aceleração de hardware AES num VPS aborda o teste em ambas as arquiteturas.

Por que contentores falham primeiro e como identificar o erro

Cada manifesto de imagem Docker regista a arquitetura para a qual foi compilado. Se extrair uma imagem que apenas possui um manifesto amd64 para um host arm64, o comando pull terá sucesso. A falha ocorre no momento em que o primeiro processo tenta iniciar:

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 a execução do ficheiro, porque o seu cabeçalho ELF (executable and linkable format) indica um tipo de máquina que este CPU não implementa. Nenhuma configuração resolve isto. As instruções não existem no silício.

Verifique o manifesto antes de efetuar o deploy:

docker buildx imagetools inspect nginx:1.27

O output lista uma linha Platform: por imagem na lista de manifestos, como linux/amd64 e linux/arm64. Se linux/arm64 estiver ausente, essa tag não iniciará num VPS ARM. docker manifest inspect --verbose nginx:1.27 mostra a mesma informação, mas a documentação do Docker refere docker manifest como um comando experimental cujo comportamento pode mudar entre releases, por isso prefira imagetools.

Para imagens que compila por conta própria, compile ambas as arquiteturas num único comando e faça o push de uma lista de manifestos:

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

Compilar para uma arquitetura estrangeira num único host requer que a emulação de modo de utilizador QEMU esteja registada no handler binfmt_misc do kernel:

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

Utilize a emulação para compilar e testar. Não a utilize para servir tráfego. A própria documentação do Docker afirma que a emulação com QEMU "pode ser muito mais lenta do que compilações nativas, especialmente para tarefas intensivas de computação como compilação e compressão ou descompressão", pelo que um serviço x86 emulado numa instância ARM anula a poupança que motivou a sua migração. A configuração do host para o caso nativo é idêntica em ambas as arquiteturas: executar Docker num VPS cobre este tema, e um ficheiro Compose existente funciona sem alterações assim que todas as imagens nele contidas possuírem um manifesto arm64.

Os pacotes de que preciso existem para arm64?

O Ubuntu e o Debian compilam quase todo o arquivo para arm64, portanto o apt install nginx postgresql redis-server comporta-se da mesma forma em ambas as arquiteturas. As lacunas encontram-se nos repositórios de terceiros.

Consulte o apt diretamente, na instância ARM:

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

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

Em seguida, leia a saída do apt update em vez de a ignorar ao fazer scroll. Um repositório de fornecedor que é apenas amd64 indica isso mesmo:

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 fonte. Uma linha fixada com [arch=amd64] é ignorada num host arm64, pelo que o pacote parece inexistente quando a causa real é a fixação (pin).

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

Runtimes interpretados e baseados em bytecode são portáveis por design. PHP, Python, Ruby e Node.js possuem pacotes arm64 nas principais distribuições. Go e Rust realizam cross-compilation para arm64 definindo um único alvo. 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 durante a execução do programa, por isso necessita de um gerador de código para a arquitetura de destino. As versões atuais possuem este suporte: OpenJDK, .NET, o motor V8 dentro do Node.js e o PyPy suportam arm64 no Linux. Versões antigas fixadas (pinned) são o verdadeiro risco. Um script de deploy que instala uma versão de runtime de vários anos atrás deve ser verificado nas notas de lançamento daquela versão quanto ao suporte a aarch64, em vez de assumir que funcionará.

Bibliotecas que contêm assembly x86 escrito manualmente, ou intrínsecos SSE e AVX, são o caso mais silencioso. A maioria também possui um caminho NEON (NEON é o conjunto de instruções vetoriais ARM) ou um fallback em C puro, portanto compilam e executam. O desempenho pode diferir da compilação x86 em qualquer direção. Meça isso na sua instância em vez de prever com base num artigo.

Software de código fechado é o verdadeiro bloqueador. Um agente de monitorização de um fornecedor, um driver de base de dados licenciado, um painel de controlo comercial ou um daemon de antivírus chegam como um binário compilado, e quando o fornecedor não publica uma versão arm64, não há nada que possa fazer. cPanel e WHM é o caso mais claro em alojamento: os seus requisitos de sistema mencionam x86_64 e não listam ARM, por isso um servidor de painel de controlo permanece em x86 (verificado em agosto de 2026, e vale a pena reler na página de requisitos do próprio fornecedor). Se isso é a única coisa que o impede, as alternativas ao cPanel que vale a pena executar num VPS é por onde começar, e verifique o suporte de arquitetura de cada uma da mesma forma.

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

Servidores x86-64 são quase intercambiáveis. Servidores ARM são menos uniformes, e as diferenças residem abaixo da sua aplicação.

O tamanho de página é o que chega à produção. A maioria dos kernels arm64 usa páginas de 4 KiB, o mesmo que x86-64. Alguns usam 64 KiB. O Red Hat Enterprise Linux 8 para aarch64 distribuía um kernel com páginas de 64 KiB por padrão, e o RHEL 9 retornou o padrão para 4 KiB, mantendo um pacote kernel-64k separado para cargas de trabalho que necessitam do tamanho maior. Um tamanho de página de 64 KiB eleva o consumo mínimo de memória para um processo com muitos mapeamentos pequenos, pois o menor bloco que o kernel pode alocar é dezesseis vezes maior. Execute getconf PAGESIZE na instância e leia o número em vez de assumi-lo.

Algumas diferenças menores valem a pena conhecer. Não existe pacote de microcódigo de CPU do sistema operacional no arm64, portanto, as atualizações de firmware vêm do seu provedor e não do apt. Servidores ARM inicializam via UEFI (unified extensible firmware interface) e descrevem seu hardware via ACPI (advanced configuration and power interface). Alguns recursos x86 não possuem equivalente em ARM, incluindo a criptografia de memória AMD SEV e 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 classe, e as imagens oficiais no Docker Hub são, por padrão, multi-arch.

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

Leia as advertências nesse mesmo anúncio, pois elas mostram o quão restrito o hardware de servidor ARM oficialmente suportado ainda é. 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. Outros hardwares ARMv8-A e ARMv9-A baseados em UEFI recebem suporte de melhor esforço. Computadores de placa única que utilizam apenas device tree, como o Raspberry Pi, não são suportados. Um convidado (guest) só é executado em um nó de sua própria arquitetura, a migração ao vivo (live migration) funciona apenas entre nós da mesma arquitetura, e clusters de arquitetura mista não são oficialmente suportados.

Essa é a posição honesta em agosto de 2026. Um fornecedor de hypervisor disponibilizando arm64 no mesmo ciclo de vida que o x86-64 é um progresso real para a plataforma. A lista de hardware suportado no primeiro dia resume-se a duas famílias de CPU.

Uma lista de verificação antes de realizar o commit

1. Execute uname -m numa instância de teste e confirme se o resultado é aarch64.
2. Execute docker buildx imagetools inspect em cada imagem no seu ficheiro Compose e confirme a existência de 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 transferência de cada agente de código fechado do qual depende e procure por uma compilação arm64 ou aarch64 pelo nome.
5. Execute getconf PAGESIZE e anote a resposta antes de definir o tamanho da memória.
6. Execute o seu próprio benchmark tanto no plano ARM quanto no plano x86 entre os quais está a escolher.

O que este artigo não pretende afirmar

Não vamos fornecer uma relação preço-desempenho entre ARM e x86. Os preços por núcleo variam conforme o provedor e o plano, e um valor medido no hardware de terceiros não prevê o seu. Meça você mesmo. O nosso guia para realizar benchmarks num VPS aborda o sysbench e o fio com um método que pode repetir, e quanto custa realmente um VPS cobre o lado financeiro da comparação. O armazenamento é uma decisão separada da arquitetura da CPU, e como o NVMe se compara ao SATA SSD num VPS trata dessa parte. Execute o mesmo teste em ambos os planos, com a sua própria carga de trabalho sempre que possível, e deixe que os seus números decidam.

FAQ

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

Eles correm se cada imagem na stack tiver uma entrada linux/arm64 no seu manifesto. Verifique cada uma com docker buildx imagetools inspect <image> e procure por uma linha Platform: linux/arm64. As imagens oficiais no Docker Hub são geralmente multi-arch. Imagens de fornecedores menores, e imagens que construiu você mesmo numa máquina x86, frequentemente não o são. Para as suas próprias imagens, reconstrua com docker buildx build --platform linux/amd64,linux/arm64 ... --push para que uma única 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 nomeia um tipo de máquina diferente e recusou. Num host arm64, isto significa quase sempre um binário ou imagem de contentor x86-64. O Docker imprime um aviso primeiro, dizendo que a plataforma de imagem solicitada linux/amd64 não corresponde à plataforma de host detetada linux/arm64/v8. A solução é uma compilação para a arquitetura correta. Nenhuma alteração de configuração faz um binário x86-64 correr nativamente 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 reporta aarch64 através de uname -m, enquanto o empacotamento Debian e Ubuntu, e as strings de plataforma do Docker, usam arm64. A mesma divisão existe do outro lado, onde uname -m diz x86_64 e o empacotamento diz amd64. Se uma página de download oferece apenas ficheiros aarch64, esses são os ficheiros corretos para uma máquina que dpkg --print-architecture chama de arm64.

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

Essa pergunta não tem uma resposta geral, e qualquer rácio único que leia foi medido em hardware que não é o seu. A velocidade depende do modelo específico de CPU, do número de núcleos que lhe são atribuídos, de como o fornecedor gere a contenção entre inquilinos e de quão bem a sua carga de trabalho utiliza instruções vetoriais. Faça um benchmark aos dois planos entre os quais está realmente a escolher, com a sua própria carga de trabalho se puder, e compare esses números.

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

Quatro verificações, por esta ordem. Confirme que cada imagem de contentor tem um manifesto arm64. Confirme que cada repositório apt de terceiros publica binary-arm64. Confirme que cada agente de código fechado tem um download aarch64. Depois, execute getconf PAGESIZE na instância de destino, porque um kernel com páginas de 64 KiB altera a pegada de memória de processos com muitos mapeamentos pequenos. Qualquer coisa que falhe numa dessas quatro verificações é uma razão para manter esse servidor específico em x86.