O Kamal é uma ferramenta de deploy que corre na sua própria máquina ou no seu runner de CI, não no servidor. Falar de «requisitos de VPS para Kamal» é, na verdade, falar da máquina para a qual o Kamal faz deploy: tem de aguentar os contentores da aplicação, o kamal-proxy, os acessórios declarados e alguns dias de imagens antigas guardadas para rollbacks.
O custo em recursos do próprio Kamal no servidor é nulo. Dimensione tudo o resto.
O que consome recursos no servidor
Depois do kamal setup, o servidor corre três coisas:
- kamal-proxy, um proxy HTTP pequeno em Go a ocupar as portas 80 e 443
- os contentores da aplicação, um conjunto por papel em
config/deploy.yml - os acessórios — Postgres, Redis ou aquilo que tiver declarado
Para o dimensionamento contam apenas os dois últimos. O kamal-proxy é um único binário estático e a sua pegada desaparece ao lado de qualquer aplicação real.
Memória
O número que apanha as pessoas desprevenidas não é o consumo em regime normal, é a sobreposição do deploy. O Kamal arranca o contentor novo enquanto o antigo ainda serve tráfego, e só pára o antigo depois de o novo passar a verificação de saúde. O pico é, portanto, o consumo habitual mais, grosso modo, uma cópia adicional do contentor da aplicação.
- Mínimo prático: 2 GB, para uma aplicação pequena sem base de dados à parte
- Confortável: 4 GB, que cobrem uma aplicação web típica com Postgres e a sobreposição
- Acrescente swap nos servidores de 4 GB. Um servidor que comece a fazer swap a meio de um deploy pode ficar tão lento que perde a janela da verificação de saúde, e o deploy reverte sem motivo aparente.
Se estiver a correr o Postgres como acessório do Kamal em vez de serviço gerido, dimensione explicitamente para ele: o maior consumidor da máquina não será o Kamal, será a base de dados.
CPU
Dois vCPU são o mínimo sensato, por uma razão que nada tem que ver com a carga corrente: durante um deploy o servidor descarrega uma imagem, arranca um contentor, executa verificações de saúde e serve tráfego a partir do contentor antigo, tudo ao mesmo tempo. Com um único vCPU essa disputa estica a janela do deploy.
- Mínimo: 1 vCPU, viável para uma aplicação com pouco tráfego se aceitar deploys mais lentos
- Recomendado: 2 vCPU
- Construir imagens no próprio VPS é o único caso que exige mesmo mais. Se o seu portátil for arm64 e o VPS a sua única máquina amd64, uma construção usará todos os núcleos que lhe der.
Armazenamento
É aqui que o comportamento do Kamal altera de facto os números. O Kamal guarda contentores e imagens antigas no servidor para que o kamal rollback possa arrancar uma versão anterior sem descarregar do registo, e limpa-os ao fim de três dias por omissão.
Portanto o disco tem de acomodar:
- Os dados e volumes próprios da aplicação
- A imagem actual mais cerca de três dias de versões anteriores
- As camadas base partilhadas, guardadas uma só vez independentemente de quantas versões mantiver
Uma imagem de 1 GB publicada algumas vezes por dia fica bem em 40 GB NVMe. Uma imagem de 3 GB enche um disco de 25 GB numa semana. Vale a pena conhecer o modo de falha: um disco cheio parte o deploy seguinte, não aquele que o encheu, pelo que causa e sintoma ficam separados por dias.
Se publicar com frequência, o kamal prune all esvazia o acumulado a pedido em vez de esperar pela janela de três dias.
Fornecedores de VPS e preços
| Fornecedor | Preço mensal | Pontos a reter | Ligação de afiliado |
|---|---|---|---|
| Contabo | 5,99 EUR | 400 GB de disco: o histórico de imagens nunca é a limitação | Contabo |
| Hetzner Cloud | 5,49 EUR | 2 vCPU / 4 GB / 40 GB NVMe, snapshots antes de deploys arriscados | Hetzner Cloud |
| DigitalOcean | 6 USD | A documentação mais clara para a configuração do servidor que o Kamal salta | DigitalOcean |
| Vultr | 5 USD | Escolha de regiões, útil quando a aplicação deve ficar perto dos utilizadores | Vultr |
| Linode (Akamai Cloud) | 5 USD | Preços previsíveis e rede simples de configurar | Linode |
Para um panorama completo das opções, veja a comparação de VPS.
A DigitalOcean é a entrada mais fácil, porque o Kamal gere deliberadamente o servidor apenas até ao Docker — as regras de firewall, o swap e as actualizações automáticas continuam a ser consigo, e a documentação da DigitalOcean cobre as três. A Hetzner dá-lhe mais RAM e mais disco por euro se estiver à vontade para fazer essa configuração sozinho.
Sugestões práticas
- Deixe abertas no servidor apenas as portas 22, 80 e 443. O kamal-proxy termina o TLS por si próprio, mais nada precisa de estar acessível.
- Verifique o
kamal app containersantes de contar com um rollback: o destino tem de continuar no disco. - Vigie o espaço livre com o mesmo alerta que usa para a memória. É a falha que chega em silêncio.
- O deploy de uma segunda aplicação no mesmo servidor é suportado no Kamal 2 — o kamal-proxy encaminha por nome de anfitrião — mas isso duplica o número de contentores e o histórico de imagens: dimensione o disco para ambas.
Conclusão
Para a maioria dos deploys de uma só aplicação, 2 vCPU, 4 GB de RAM e 40 GB de SSD ou NVMe deixam espaço para a aplicação, a base de dados, a sobreposição do deploy e três dias de imagens de rollback. Aumente o disco antes de aumentar a memória: a pressão sobre a memória anuncia-se sozinha, a acumulação de imagens não. Para mais opções, explore a nossa comparação de VPS.
Frequently asked questions
De quanta RAM precisa um VPS como destino de um deploy com Kamal?
O suficiente para a sua aplicação, os acessórios dela e uma cópia adicional do contentor da aplicação. Durante um deploy o contentor antigo e o novo correm ao mesmo tempo, por isso o pico é o consumo habitual mais um contentor. Num servidor de 4 GB com uma aplicação de 1 GB fica folgado.
O Kamal consome CPU ou memória no servidor?
Não. O Kamal é uma gem que executa a partir da sua máquina ou da CI e que termina quando o deploy acaba. A única adição permanente ao servidor é o kamal-proxy, um proxy HTTP pequeno escrito em Go cujo consumo é irrelevante ao lado de qualquer aplicação real.
Porque é que um servidor com Kamal fica sem disco com o tempo?
O Kamal guarda contentores e imagens antigas para que um rollback não tenha de descarregar do registo, e só os limpa ao fim de três dias por omissão. Deploys frequentes de uma imagem grande acumulam-se depressa, e o disco costuma encher a meio de um deploy posterior, não naquele que o encheu.