Kamal è uno strumento di deploy che gira sulla tua macchina o sul tuo runner CI, non sul server. Parlare di «requisiti VPS per Kamal» significa quindi parlare della macchina verso cui Kamal fa il deploy: deve reggere i container della tua applicazione, kamal-proxy, gli accessori dichiarati e qualche giorno di vecchie immagini tenute per i rollback.
Il costo in risorse di Kamal sull’host è zero. Dimensiona tutto il resto.
Cosa consuma risorse sull’host
Dopo kamal setup, il server esegue tre cose:
- kamal-proxy, un piccolo proxy HTTP in Go che occupa le porte 80 e 443
- i container della tua applicazione, un gruppo per ruolo in
config/deploy.yml - gli accessori — Postgres, Redis o qualunque altra cosa tu abbia dichiarato
Per il dimensionamento contano solo gli ultimi due. kamal-proxy è un singolo binario statico e la sua impronta sparisce accanto a qualsiasi applicazione reale.
Memoria
Il numero che coglie impreparati non è il consumo a regime, è la sovrapposizione del deploy. Kamal avvia il nuovo container mentre il vecchio sta ancora servendo traffico, e ferma il vecchio solo dopo che il nuovo ha superato il controllo di salute. Il picco è quindi il consumo abituale più, all’incirca, una copia aggiuntiva del container applicativo.
- Minimo pratico: 2 GB, per una piccola applicazione senza database separato
- Comodo: 4 GB, che coprono una tipica applicazione web con Postgres e la sovrapposizione
- Aggiungi swap sugli host da 4 GB. Un host che inizia a fare swap in pieno deploy può rallentare al punto da mancare la finestra del controllo di salute, e a quel punto il deploy torna indietro apparentemente senza motivo.
Se esegui Postgres come accessorio di Kamal invece che come servizio gestito, dimensiona esplicitamente per lui: il consumatore più grande della macchina non sarà Kamal, sarà il database.
CPU
Due vCPU sono la soglia sensata, per una ragione che non ha nulla a che vedere con il carico ordinario: durante un deploy l’host scarica un’immagine, avvia un container, esegue i controlli di salute e serve traffico dal vecchio container, tutto nello stesso momento. Su una sola vCPU questa contesa allunga la finestra di deploy.
- Minimo: 1 vCPU, praticabile per un’applicazione poco trafficata se accetti deploy più lenti
- Consigliato: 2 vCPU
- Costruire le immagini sul VPS stesso è l’unico caso che richiede davvero di più. Se il tuo portatile è arm64 e il VPS è la tua unica macchina amd64, una build userà tutti i core che le dai.
Storage
È qui che il comportamento di Kamal cambia davvero i numeri. Kamal conserva container e immagini vecchie sul server, così kamal rollback può riavviare una versione precedente senza scaricare dal registry, e li rimuove dopo tre giorni per impostazione predefinita.
Il disco deve quindi contenere:
- I dati e i volumi propri della tua applicazione
- L’immagine attuale più circa tre giorni di versioni precedenti
- I layer di base condivisi, memorizzati una volta sola indipendentemente da quante versioni conservi
Un’immagine da 1 GB rilasciata qualche volta al giorno sta bene su 40 GB NVMe. Un’immagine da 3 GB riempie un disco da 25 GB in una settimana. Vale la pena conoscere la modalità di guasto: un disco pieno rompe il deploy successivo, non quello che l’ha riempito, quindi causa e sintomo distano giorni.
Se rilasci spesso, kamal prune all svuota l’arretrato su richiesta invece di aspettare la finestra di tre giorni.
Provider VPS e prezzi
| Provider | Prezzo al mese | Punti di forza | Link affiliato |
|---|---|---|---|
| Contabo | 5.99 EUR | 400 GB di disco: la cronologia delle immagini non è mai il vincolo | Contabo |
| Hetzner Cloud | 5.49 EUR | 2 vCPU / 4 GB / 40 GB NVMe, snapshot prima dei deploy rischiosi | Hetzner Cloud |
| DigitalOcean | 6 USD | La documentazione più chiara per la configurazione dell’host che Kamal salta | DigitalOcean |
| Vultr | 5 USD | Scelta di regioni, utile quando l’app deve stare vicino ai suoi utenti | Vultr |
| Linode (Akamai Cloud) | 5 USD | Prezzi prevedibili e rete semplice da configurare | Linode |
Per una panoramica completa delle opzioni, consulta il confronto VPS.
DigitalOcean è l’ingresso più facile, perché Kamal gestisce deliberatamente l’host solo fino a Docker: regole del firewall, swap e aggiornamenti automatici restano a carico tuo, e la documentazione di DigitalOcean copre tutti e tre. Hetzner ti dà più RAM e più disco per euro, se quella configurazione non ti spaventa.
Consigli pratici
- Lascia aperte sul server solo le porte 22, 80 e 443. kamal-proxy termina TLS da solo, non serve altro raggiungibile.
- Controlla
kamal app containersprima di contare su un rollback: la destinazione deve essere ancora su disco. - Monitora lo spazio libero con lo stesso allarme che usi per la memoria. È il guasto che arriva in silenzio.
- Il deploy di una seconda applicazione sullo stesso host è supportato in Kamal 2 — kamal-proxy instrada per nome host — ma raddoppia il numero di container e la cronologia delle immagini: dimensiona il disco per entrambe.
Conclusione
Per la maggior parte dei deploy di una singola applicazione, 2 vCPU, 4 GB di RAM e 40 GB di SSD o NVMe lasciano spazio all’applicazione, al suo database, alla sovrapposizione del deploy e a tre giorni di immagini di rollback. Aumenta il disco prima della memoria: la pressione sulla memoria si annuncia da sola, l’accumulo di immagini no. Per altre opzioni, esplora il nostro confronto VPS.
Frequently asked questions
Quanta RAM serve a un VPS come destinazione di un deploy Kamal?
Quanta ne basta per la tua applicazione, i suoi accessori e una copia in più del container applicativo. Durante un deploy il container vecchio e quello nuovo girano insieme, quindi il picco è il consumo abituale più un container. Su un host da 4 GB con un'app da 1 GB si sta comodi; aggiungi swap se è al limite.
Kamal consuma CPU o memoria sul server?
No. Kamal è una gem che lanci dalla tua macchina o dalla CI e che termina quando il deploy finisce. L'unica aggiunta permanente sull'host è kamal-proxy, un piccolo proxy HTTP scritto in Go il cui consumo è trascurabile rispetto a qualsiasi applicazione reale.
Perché un host Kamal esaurisce il disco con il tempo?
Kamal conserva container e immagini vecchie perché un rollback non debba scaricare dal registry, e li rimuove solo dopo tre giorni per impostazione predefinita. Deploy frequenti di un'immagine grande si accumulano in fretta, e il disco di solito si riempie durante un deploy successivo, non durante quello che l'ha causato.