Se você já tentou criar uma instância ARM (Ampere A1) na Oracle Cloud recentemente, sabe do que estamos falando: na prática, hoje é uma loteria. Você tenta, recebe “Out of Capacity”, tenta de novo em outro horário, em outra região, e às vezes leva dias até conseguir provisionar. Por isso, este guia assume o cenário mais realista para a maioria das pessoas em 2026: a instância AMD x86 (VM.Standard.E2.1.Micro), com 1 OCPU e 1 GB de RAM, que está praticamente sempre disponível na hora que você cria a conta.
Isso não é um prêmio de consolação. Uma VPS de 1 GB bem planejada continua sendo capaz de hospedar sites, APIs e serviços leves com estabilidade — o segredo está em uma palavra: simplicidade.
Resumo Rápido
| Item | Detalhe |
|---|---|
| Provedor | Oracle Cloud Infrastructure (OCI) |
| Instância foco deste guia | VM.Standard.E2.1.Micro (AMD, x86) |
| Recursos | 1 OCPU, 1 GB de RAM, 47 GB de boot volume |
| Quantidade disponível | Até 2 instâncias desse tipo por conta |
| Disponibilidade | Alta — normalmente provisiona na hora, sem fila de capacidade |
| Instância ARM (A1.Flex) | Existe, mas a disponibilidade de capacidade é muito instável e o limite Always Free foi reduzido em 2026 — tratamos como “bônus”, não como base do planejamento |
| Armazenamento em bloco (total da conta) | 200 GB |
| Tráfego de saída | 10 TB por mês |
| Cartão de crédito | Exigido na criação da conta, para verificação (sem cobrança em recursos Always Free) |
Por Que Focar na Instância AMD
A instância ARM (Ampere A1) é, no papel, mais poderosa — mas depender dela como base de um projeto é arriscado. A disponibilidade de capacidade varia por região e horário, e não é incomum passar dias tentando provisionar sem sucesso. Além disso, em 2026 a Oracle reduziu o teto Always Free do pacote ARM, o que tornou o recurso ainda menos previsível para quem está começando agora.
A instância AMD Micro, por outro lado, tem uma vantagem que vale mais do que RAM extra: previsibilidade. Você cria a conta, provisiona e, na grande maioria dos casos, a instância sobe sem fila de capacidade. Para quem quer algo funcionando hoje — não “quando a sorte ajudar” — essa é a base mais confiável.
A recomendação prática é: planeje toda a sua infraestrutura em torno de 1 GB de RAM. Se, no futuro, uma instância ARM aparecer disponível, trate-a como capacidade extra para crescer — nunca como pré-requisito.
O Erro Que Quase Todo Mundo Comete em 1 GB de RAM
Quando alguém cria a primeira VPS, o instinto comum é instalar um painel completo logo de cara — aaPanel, CyberPanel, HestiaCP, Webmin, CasaOS. Esses painéis facilitam muitas tarefas, mas foram pensados para máquinas com bem mais memória disponível.
Em uma VPS de apenas 1 GB de RAM, um painel completo costuma instalar automaticamente:
- Servidor web (Apache ou Nginx)
- PHP
- Banco de dados
- FTP
- Servidor DNS
- Mail Server
- Interface Web própria
- Agentes de monitoramento do próprio painel
Mesmo quando você usa metade disso, a memória fica comprometida antes mesmo de rodar sua aplicação. O resultado, em 1 GB, é sentido rápido: swap sendo usado o tempo todo, containers sendo encerrados pelo kernel por falta de memória (OOM killer) e uma VPS que parece “travada” mesmo sob pouco tráfego.
Como Funciona na Prática: A Arquitetura Para 1 GB
A filosofia para uma instância AMD de 1 GB é o oposto de um painel completo: o sistema operacional cuida apenas do básico, e tudo o mais roda em containers Docker, ligados por um proxy reverso leve e protegidos por uma camada como o Cloudflare na frente.
Internet
│
Cloudflare
│
Caddy
│
Docker
│
Aplicações
Essa arquitetura reduz o consumo de memória do sistema, facilita backups e torna futuras migrações muito mais simples — mesmo dentro do limite apertado de 1 GB.
Sistema Operacional
Ubuntu Server 24.04 LTS é a escolha recomendada: estável, com suporte de longo prazo e ampla documentação. Logo após instalar, o ideal é limitar a instalação inicial ao essencial:
sudo apt update
sudo apt upgrade -y
sudo apt install \
curl \
wget \
git \
unzip \
ufw \
fail2ban -y
Nada além disso no sistema base. Quanto menos pacotes instalados diretamente no Ubuntu, menor a manutenção e menor o consumo de RAM ocioso.
Docker Como Base de Tudo
Em vez de instalar serviços diretamente no sistema, o Docker Compose organiza cada aplicação em sua própria pasta, por exemplo:
/opt/compose
├── caddy
├── portainer
├── uptime-kuma
└── (sua aplicação)
Isso facilita backup, atualização, migração, restauração e versionamento no Git — importante quando os recursos são escassos e qualquer erro de configuração precisa ser revertido rápido.
Principais Recursos (O Que Realmente Cabe em 1 GB)
| Serviço | Função | Cabe junto em 1 GB? |
|---|---|---|
| Caddy | Proxy reverso com HTTPS automático | Sim — consumo muito baixo |
| Portainer CE | Gerenciamento visual dos containers | Sim, mas consome memória extra; opcional |
| Uptime Kuma | Monitoramento de disponibilidade | Sim, para 1–2 sites monitorados |
| Redis | Cache | Só se a aplicação realmente precisar |
| MariaDB/MySQL | Banco de dados | Avaliar caso a caso — é um dos maiores consumidores de RAM |
| Dozzle | Visualização de logs | Sim, consumo mínimo |
Em 1 GB de RAM, a regra prática é: rode simultaneamente apenas o que sua aplicação realmente precisa. Se o site é estático, nem faz sentido manter um banco de dados ativo o tempo todo.
Vantagens da Instância AMD de 1 GB
- Disponibilidade muito mais previsível do que a instância ARM
- Suficiente para sites leves, APIs pequenas e automações, se a stack for enxuta
- Combinada com Cloudflare, reduz bastante a carga que chega até a VPS (cache, proteção contra DDoS)
- Arquitetura baseada em Docker facilita expandir depois, inclusive migrando para uma instância ARM se ela aparecer disponível
Desvantagens
- 1 GB de RAM é pouco para rodar banco de dados, painel completo e aplicação ao mesmo tempo
- Qualquer serviço mal dimensionado pode gerar OOM kill (processo encerrado por falta de memória)
- Swap ajuda, mas não substitui RAM física — picos de tráfego mais fortes ainda podem exigir ajustes finos
- Não é ambiente adequado para IA local, edição de mídia ou cargas pesadas
Para Quem é Indicado
✔ Perfis que se beneficiam
- Quem quer uma VPS funcionando hoje, sem depender de conseguir capacidade ARM
- Projetos pessoais, landing pages, portfólios e APIs de baixo tráfego
- Quem está aprendendo Docker e quer praticar com restrição real de recursos
- Quem já usa Cloudflare e quer um back-end simples atrás dele
✖ Perfis que não se beneficiam
- Projetos que dependem de banco de dados grande rodando o tempo todo
- Sites com tráfego alto e necessidade de folga de memória
- Quem precisa de várias aplicações pesadas simultâneas na mesma instância
Segurança Desde o Primeiro Dia
Antes de expor qualquer serviço, vale configurar:
- Login SSH por chave pública, com senha desabilitada
- Firewall UFW liberando apenas as portas necessárias
- Fail2ban para mitigar tentativas de força bruta
- Atualizações automáticas de segurança do sistema
Colocar o domínio atrás do Cloudflare também ajuda bastante: além do DNS gratuito, ele oferece CDN, SSL, proteção contra DDoS, cache e regras de firewall — o que reduz a exposição direta da VPS de 1 GB à internet.
Swap: Pequeno Ajuste, Grande Diferença em 1 GB
Configurar entre 2 GB e 4 GB de swap não substitui RAM física, mas ajuda bastante a evitar que o kernel encerre containers em momentos de pico de uso. Em uma instância de apenas 1 GB, esse é um dos ajustes mais simples e com maior retorno.
O Que Eu Evitaria Nesta Configuração
Mesmo sendo excelentes projetos, aplicações como Nextcloud, Immich, Jellyfin, GitLab, OpenWebUI, Ollama, Stable Diffusion e ComfyUI não são recomendadas em uma instância AMD de 1 GB. Não porque sejam ruins, mas porque foram desenvolvidas pensando em máquinas com muito mais memória disponível.
E Se a Instância ARM Aparecer Disponível?
Vale tentar de tempos em tempos, sim — só não vale planejar seu projeto assumindo que ela vai estar lá. Se conseguir provisionar uma instância ARM, o caminho mais simples é usar a mesma estrutura de containers já criada para a instância AMD e simplesmente migrar (ou replicar) os serviços que exigem mais memória, mantendo a AMD como base estável e a ARM como capacidade extra.
Perguntas Frequentes
A instância AMD de 1 GB ainda vale a pena em 2026, mesmo sendo menor que a ARM?
Sim. Para a maioria dos projetos pessoais e pequenos, a previsibilidade de conseguir provisionar na hora compensa a diferença de recursos, especialmente com uma stack enxuta baseada em Docker.
Por que a instância ARM é tão difícil de conseguir hoje?
A capacidade disponível varia por região e horário, e a demanda por instâncias ARM gratuitas é alta. Em 2026, a Oracle também reduziu o teto Always Free desse tipo de instância, o que tornou o recurso ainda mais concorrido.
Docker é pesado para rodar em apenas 1 GB de RAM?
Não. O Docker em si tem baixo consumo de memória; o que pesa são os containers que você escolhe rodar. Por isso a recomendação é manter a stack mínima e evitar rodar vários serviços grandes ao mesmo tempo.
Dá para rodar um banco de dados junto com a aplicação em 1 GB?
Depende do banco e do volume de dados. Para bancos pequenos e uso leve pode funcionar com ajustes de configuração, mas é um dos maiores consumidores de RAM e deve ser avaliado caso a caso.
Vale a pena instalar aaPanel, CyberPanel ou HestiaCP em 1 GB de RAM?
Geralmente não é o ideal. Esses painéis instalam vários serviços automaticamente e consomem memória que, em 1 GB, faz falta para a própria aplicação.
Qual proxy reverso escolher para uma VPS tão pequena?
O Caddy costuma ser a escolha mais simples: configuração enxuta, HTTPS automático e baixíssimo consumo de recursos, ideal para poucos sites em uma máquina pequena.
Dá para rodar IA local (LLMs, geração de imagem) nessa instância?
Não é recomendado. Modelos de IA modernos exigem GPU dedicada e muito mais memória do que 1 GB. O ideal é usar um computador com GPU própria e deixar a VPS responsável apenas por publicar o acesso aos serviços.
Preciso de cartão de crédito para criar a conta, mesmo usando só a instância AMD gratuita?
Sim, a Oracle exige cartão para verificação de identidade na criação da conta, mesmo que você use apenas recursos Always Free sem cobrança.
Compensa configurar tudo manualmente em vez de esperar conseguir uma instância ARM maior?
Sim, na maioria dos casos. Esperar pela ARM significa depender de sorte de capacidade; configurar bem a instância AMD de 1 GB coloca o projeto no ar hoje, com espaço para crescer depois.
Conclusão
Em 2026, tentar depender da instância ARM Always Free como base de um projeto é assumir uma variável fora do seu controle: capacidade de região, horário de tentativa e, agora, um teto Always Free menor do que antes. A instância AMD de 1 GB de RAM, por outro lado, está disponível na hora em praticamente todos os casos — e, com uma stack enxuta baseada em Docker, Caddy e Cloudflare, ela é suficiente para colocar no ar sites leves, APIs pequenas e automações com estabilidade real.
A recomendação final é simples: planeje tudo assumindo 1 GB de RAM como recurso permanente, e trate qualquer capacidade ARM que aparecer como bônus para expandir depois — nunca como pré-requisito para começar.
Para criar a conta e começar a provisionar, o ponto de partida é a página oficial da Oracle Cloud Free Tier.
Gerenciando contas na nuvem ou enfrentando problemas de acesso?
