Tutoriais de VPS
Vale a pena comprar um VPS ARM (2026)? Como escolher entre VPS ARM e x86 e como verificar a compatibilidade
O VPS ARM costuma ser mais barato, consumir menos energia e ser adequado para contêineres e serviços web, mas não é todo projeto que deve comprá-lo sem pensar. Este artigo explica, de um jeito que o usuário comum consegue acompanhar, as diferenças entre VPS ARM e VPS x86, os cenários adequados para cada um, a compatibilidade com Docker, os comandos de verificação antes da compra e quando vale mais a pena gastar um pouco mais e escolher x86.
Ultimamente, quando olho planos de VPS, sempre encontro uma nova pergunta: com os mesmos 2 núcleos e 4 GB, a versão ARM é claramente mais barata e a x86 custa um pouco mais — então qual devo comprar?
A primeira reação de muita gente é:
- ARM é barato, então não tem custo-benefício melhor?
- x86 é o veterano, então não é mais estável?
- Dá para rodar Docker?
- WordPress, Node.js, Python e bancos de dados vão ter problemas de compatibilidade?
- Se eu comprar ARM, migrar depois para um VPS comum vai ser complicado?
Este artigo não exalta ARM nem menospreza x86. Meu critério é simples: dá para comprar um VPS ARM, mas primeiro confirme se a sua stack de software consegue lidar com arm64.
Se você só roda Nginx, Docker Compose, uma API pequena, site estático, monitoramento ou ferramentas pessoais, o VPS ARM é ótimo. Mas se você roda software antigo de código fechado, servidores de jogos, programas binários estranhos, ou simplesmente não sabe o que há nas dependências do projeto, o x86 continua sendo mais seguro.
| Caso de uso | O VPS ARM é adequado? | Motivo |
|---|---|---|
| Nginx / Caddy / sites estáticos | Muito adequado | As imagens e pacotes de sistema principais quase sempre têm arm64 |
| Ferramentas auto-hospedadas com Docker Compose | Adequado, mas verifique a imagem | Veja se a imagem suporta linux/arm64 |
| Aplicações Node.js / Python / Go | Na maioria, adequado | O ecossistema já é bem maduro |
| WordPress / PHP / MySQL | Normalmente adequado | As imagens oficiais têm bom suporte; verifique os plugins à parte |
| Bancos de dados leves / Redis | Adequado | Os serviços comuns têm versão ARM |
| Servidores de jogos | Com cautela | Muitos binários de servidor só existem para x86 |
| Painéis de código fechado / software pirata | Não recomendado | É onde a compatibilidade mais falha |
| Tarefas de alto desempenho por núcleo | Depende | Veja o modelo específico de CPU, não só a arquitetura |
Meu conselho pessoal é:
- Projetos novos, conteinerizados e principalmente de código aberto: pode priorizar ARM;
- Projetos antigos, programas de código fechado, sem paciência para verificar compatibilidade: escolha x86;
- Cargas de produção que já rodam bem em x86: não force uma troca de arquitetura só para economizar alguns dólares.
Não precisa tratar ARM como algo misterioso. Para o usuário comum de VPS, ele afeta principalmente duas coisas:
- O conjunto de instruções da CPU é diferente;
- Os pacotes de software, imagens Docker e arquivos binários que você baixa precisam ter a arquitetura correspondente.
VPS x86 comuns usam amd64 ou x86_64. VPS ARM costumam usar arm64 ou aarch64. Você pode verificar no servidor assim:
uname -m
O resultado será mais ou menos:
x86_64 # 常见 x86 VPS
aarch64 # 常见 ARM VPS
Se você normalmente só usa apt install nginx e docker compose up -d, muitas vezes não vai sentir diferença. Os problemas costumam aparecer nestes pontos:
- Alguma imagem Docker não tem versão arm64;
- Algum script de instalação tem um link de download x86 fixo no código;
- Algum software de código fechado só publica pacotes amd64;
- Algum plugin antigo depende de compilação local e a compilação falha;
- O README de algum projeto só foi testado em x86.
Então não é que você não possa comprar um VPS ARM — é que você precisa fazer um passo a mais em relação ao x86: verificar a compatibilidade primeiro.
O motivo principal é bem prático: custo e consumo de energia.
Os provedores de nuvem usam servidores ARM normalmente para obter melhor desempenho por watt. Para o usuário, a sensação mais direta é que, com a mesma memória e quantidade de núcleos, os planos ARM costumam ser um pouco mais baratos ou oferecer mais núcleos.
Coisas como o Ampere A1 da Oracle Cloud e a série CAX da Hetzner são a porta de entrada pela qual muita gente conhece o VPS ARM. Instâncias de nuvem como o AWS Graviton também tornaram o ARM cada vez mais comum em servidores na nuvem.
Mas atenção: barato não significa necessariamente rápido.
O desempenho de um VPS também depende de:
- O modelo específico de CPU;
- Se o provedor faz overselling;
- O I/O de disco;
- A rota de rede;
- Se há limite de CPU sustentada;
- Se o seu software suporta ARM nativamente.
Prefiro ver o VPS ARM como "uma nova opção de bom custo-benefício", não como um substituto universal.
Se você pretende comprar um VPS ARM, não olhe só o preço. Passe primeiro por esta lista.
Este é o ponto mais importante.
Muitos projetos auto-hospedados hoje são implantados via Docker. O suporte oficial do Docker a imagens multiplataforma já é maduro; a mesma imagem pode suportar tanto linux/amd64 quanto linux/arm64. Mas não é toda imagem de terceiros que é feita para múltiplas arquiteturas.
Você pode verificar a arquitetura de uma imagem com:
docker buildx imagetools inspect nginx:latest
Você quer ver algo assim no resultado:
linux/amd64
linux/arm64
Se aparecer só linux/amd64, então em um VPS ARM vai dar trabalho. Não é totalmente impossível rodar, mas normalmente exige emulação ou compilar você mesmo, e nem o desempenho nem o custo de manutenção compensam.
Muitos scripts de um clique baixam pacotes automaticamente conforme a arquitetura do sistema, e esses geralmente não dão problema.
Mas alguns scripts têm fixo no código:
linux-amd64.tar.gz
x86_64.rpm
amd64.deb
Esses scripts costumam falhar direto no ARM. Você pode primeiro procurar no README do GitHub ou no script de instalação por:
arm64
aarch64
amd64
x86_64
Se o projeto não menciona ARM de jeito nenhum, não leve para produção com pressa.
Os serviços comuns geralmente não dão problema:
- MySQL / MariaDB
- PostgreSQL
- Redis
- MongoDB
- Nginx
- Caddy
- Node.js
- Python
- Go
Esses componentes principais já são muito comuns em Linux ARM.
O que realmente exige atenção é "um painel de gerenciamento antigo envolvendo tudo" ou "algum plugin que traz um binário de código fechado". Por exemplo, algumas versões antigas de painéis comerciais, sondas de monitoramento e ferramentas de gerenciamento de servidores de jogos podem oferecer só pacotes x86.
Se o projeto é seu e você mesmo vai compilar as imagens Docker, é melhor suportar múltiplas arquiteturas desde o início.
O Docker Buildx pode compilar assim:
docker buildx build \
--platform linux/amd64,linux/arm64 \
-t yourname/yourapp:latest \
--push .
Assim, com a mesma tag de imagem, tanto o VPS x86 quanto o VPS ARM conseguem baixar a versão correspondente.
Se você não quer lidar com múltiplas arquiteturas, pelo menos confirme que o seu destino de implantação é ARM e não fique alternando entre ARM hoje e x86 amanhã.
Os dados em si geralmente não se importam com diferenças de arquitetura. Por exemplo, dumps de banco de dados, arquivos estáticos, armazenamento de objetos e arquivos de configuração podem ser movidos de ARM para x86 sem problema.
O complicado é o ambiente de execução:
- Se a imagem ainda pode ser baixada após trocar de arquitetura;
- Se os artefatos compilados precisam ser recompilados;
- Se os binários locais precisam ser substituídos;
- Se alguns plugins estão vinculados a uma arquitetura.
Então não faça backup só do diretório do contêiner. Uma forma mais segura é:
# 数据库导出
mysqldump -u root -p app_db > app_db.sql
# 配置文件和 compose 文件打包
tar -czf app-config.tar.gz docker-compose.yml .env nginx/
Assim, quando você migrar de ARM para x86 mais tarde, não vai ficar preso por causa de algum contêiner antigo.
Eu priorizaria o uso do VPS ARM nestes cenários.
Nginx, Caddy, Hugo, Astro, exportação estática do Next.js — todos são muito adequados.
Se você só tem um blog, um site de documentação ou um site de links, as vantagens do VPS ARM são evidentes: barato, economiza recursos e tem baixo custo de manutenção.
Por exemplo:
- Uptime Kuma
- Vaultwarden
- Gitea
- FreshRSS
- NocoDB
- n8n
- Miniflux
- Umami
Muitos desses projetos têm imagens ARM. Verifique a arquitetura da imagem antes de comprar e normalmente não haverá problema.
Se você pretende implantar o n8n, talvez valha a pena ler este artigo: Montando fluxos de automação com n8n em um VPS (2026)
Backends como Node.js, Python FastAPI, Go e Rust já têm suporte a ARM bem maduro.
Principalmente Go e Rust, se você mesmo compilar, são mais práticos entre arquiteturas. O que realmente exige atenção é se as dependências incluem extensões nativas.
Serviços de monitoramento normalmente não exigem muito desempenho por núcleo; valorizam mais estabilidade e custo.
Para coisas como Prometheus + Grafana, Node Exporter e Uptime Kuma, usar um VPS ARM como nó de monitoramento leve é bem adequado.
Aqui vou ser mais conservador, porque comprar a arquitetura errada para economizar é mais chato do que gastar alguns dólares a mais no começo.
Minecraft Java Edition está tranquilo, mas muitos binários de servidores de jogos, componentes antichat e plugins de gerenciamento podem oferecer só arquitetura x86.
Se a documentação oficial não indica claramente suporte a ARM, em geral não recomendo usar um VPS ARM para um servidor de jogos em produção.
Por exemplo, certos painéis licenciados, agentes de monitoramento e ferramentas de gerenciamento antigas só oferecem pacotes amd64. É chato comprar ARM e só então descobrir que não instala.
Para esses projetos, priorize x86.
Não é que ARM não rode bancos de dados, mas o desempenho de um banco de dados depende mais de disco, memória, CPU, parâmetros e carga real.
Para um banco de dados de produção, eu não migraria só porque ARM é mais barato. No mínimo, faria testes de carga e um simulado de backup e restauração antes de decidir.
Se você ainda não fez um simulado de restauração, pode ler este artigo: Como fazer um simulado de backup e restauração em um VPS (2026)
Este é o erro mais comum.
Se o projeto foi passado por outra pessoa, cheio de scripts, plugins e arquivos binários, e você não tem certeza de onde vieram, não compre ARM primeiro só para economizar.
O x86 deixa mais margem para erro.
Quando recebo uma máquina, faço três coisas primeiro.
uname -m
lscpu
cat /etc/os-release
Confirme se é aarch64 e se o sistema é a versão de Ubuntu / Debian que você esperava.
docker image inspect nginx:latest --format '{{.Architecture}}'
Se a saída for:
arm64
significa que a imagem ARM foi baixada.
YABS e Geekbench servem de referência, mas eu valorizo mais as cargas reais:
- Se o painel do WordPress está fluido;
- Se a API Node.js responde de forma estável;
- Se os contêineres Docker reiniciam normalmente;
- Se as consultas ao banco de dados têm oscilações evidentes;
- Se a rota de rede piora no horário de pico da noite.
Se você olhar só a pontuação de CPU, é fácil ignorar disco e rede. As vezes em que um VPS realmente incomoda não costumam ser por falta de CPU, mas por I/O oscilando, rota instável e vizinhos consumindo recursos.
Se você não quer ficar em dúvida, pode escolher conforme esta tabela.
| Sua situação | Escolha recomendada |
|---|---|
| Projeto novo, implantação com Docker, imagem suporta arm64 | VPS ARM |
| Principalmente Nginx, Caddy, Node.js, Python, Go | Vale a pena testar primeiro o VPS ARM |
| Precisa rodar software antigo, de código fechado ou servidores de jogos | VPS x86 |
| O projeto já roda de forma estável em x86 | Não migre para ARM sem pensar |
| Orçamento apertado, mas disposto a verificar compatibilidade | VPS ARM |
| Não entende de Linux e só quer evitar problemas | O VPS x86 é mais tranquilo |
| Quer um ambiente de produção de longo prazo | Teste primeiro com pouco tráfego e depois decida |
Meu hábito pessoal é:
- Ambientes de teste e projetos novos: com ARM você pode testar sem medo;
- Serviços de produção leves: ARM pode ser usado, mas faça antes backup e plano de reversão;
- Negócio principal e projetos que você não conhece: priorize x86.
Se a página não deixa claro, você pode perguntar em um ticket assim:
Hi,
Before ordering this ARM VPS, could you please confirm:
1. Is the CPU architecture arm64 / aarch64?
2. Can I reinstall Ubuntu 22.04 or 24.04 arm64 from the panel?
3. Are snapshots and backups supported for ARM instances?
4. Can I migrate or rebuild this instance to an x86 plan later if needed?
5. Are there any limitations compared with your x86 VPS plans?
Thank you.
Ou seja:
- Se é arm64 padrão;
- Se dá para reinstalar sistemas comuns;
- Se há suporte a backup por snapshot;
- Se dá para migrar para x86 mais tarde;
- Se o plano ARM tem limites ocultos.
Se o suporte não consegue responder nem isso com clareza, eu seria mais cauteloso.
Se vale a pena comprar um VPS ARM não depende de "se ARM é bom", mas de "se o seu projeto combina com ARM".
Eu avaliaria assim:
- As imagens e o software suportam arm64;
- A carga é um cenário convencional como web, API, auto-hospedagem ou monitoramento;
- Você está disposto a fazer uma verificação de compatibilidade;
- Você tem um plano de backup e reversão;
- O preço é realmente melhor do que o de um x86 da mesma faixa.
Cumprindo essas condições, vale muito a pena testar um VPS ARM.
Mas se você se jogar só porque é barato, sem verificar imagens, sem olhar a arquitetura do software e sem preparar backup, o dinheiro que o ARM economizar provavelmente vai ser pago depois com tempo.
Resumo em uma frase:
Se você entende um pouco de Docker e Linux, o VPS ARM é uma opção de alto custo-benefício; se você só quer instalar software sem pensar, o VPS x86 continua mais estável.