Kamal VPS-vereisten: RAM, CPU en Opslag

Kamal is een deploytool die op je eigen machine of CI-runner draait, niet op de server. «Kamal VPS-vereisten» gaat dus eigenlijk over de machine waarnaar Kamal deployt: die moet je app-containers dragen, plus kamal-proxy, de opgegeven accessories en een paar dagen aan oude images die voor rollbacks bewaard blijven.

Kamals eigen beslag op de host is nul. Kies de maat voor al het andere.

Wat er op de host resources kost

Na kamal setup draaien er drie dingen op de server:

• kamal-proxy, een kleine HTTP-proxy in Go op poorten 80 en 443
• je app-containers, één set per rol in config/deploy.yml
• accessories — Postgres, Redis of wat je verder hebt opgegeven

Voor de maatvoering tellen alleen de laatste twee. kamal-proxy is één statische binary en valt naast elke echte applicatie in het niet.

Geheugen

Het getal dat mensen verrast is niet het verbruik in rust, maar de deploy-overlap. Kamal start de nieuwe container terwijl de oude nog verkeer bedient, en stopt de oude pas als de nieuwe zijn health check heeft doorstaan. De piek is dus je gewone verbruik plus ruwweg één extra kopie van de app-container.

• Praktisch minimum: 2 GB, voor een kleine applicatie zonder aparte database
• Comfortabel: 4 GB, wat een gangbare webapplicatie met Postgres en de overlap dekt
• Voeg swap toe op hosts met 4 GB. Een host die midden in een deploy gaat swappen kan zo traag worden dat hij het health-checkvenster mist, waarna de deploy schijnbaar zonder reden terugdraait.

Draai je Postgres als Kamal-accessory in plaats van als beheerde dienst, kies daar dan expliciet de maat op: niet Kamal maar de database wordt de grootste verbruiker op de machine.

CPU

Twee vCPU’s zijn de verstandige ondergrens, om een reden die niets met de dagelijkse belasting te maken heeft: tijdens een deploy haalt de host een image op, start een container, voert health checks uit en bedient verkeer vanuit de oude container, allemaal tegelijk. Op één vCPU rekt die concurrentie het deployvenster op.

• Minimum: 1 vCPU, werkbaar voor een applicatie met weinig verkeer als je tragere deploys accepteert
• Aanbevolen: 2 vCPU’s
• Images op de VPS zelf bouwen is het enige geval dat echt meer vraagt. Is je laptop arm64 en de VPS je enige amd64-machine, dan gebruikt een build elke core die je hem geeft.

Opslag

Hier verandert Kamals gedrag de cijfers werkelijk. Kamal bewaart oude containers en images op de server zodat kamal rollback een vorige versie kan starten zonder uit de registry te halen, en ruimt ze standaard na drie dagen op.

De schijf moet dus ruimte bieden aan:

• De eigen data en volumes van je applicatie
• De huidige image plus ongeveer drie dagen aan eerdere versies
• Gedeelde baselagen, die maar één keer worden opgeslagen hoeveel versies je ook bewaart

Een image van 1 GB die je een paar keer per dag uitrolt past prima op 40 GB NVMe. Een image van 3 GB vult een schijf van 25 GB binnen een week. Het foutbeeld is het onthouden waard: een volle schijf breekt de volgende deploy, niet degene die hem vulde, dus oorzaak en symptoom liggen dagen uit elkaar.

Deploy je vaak, dan leegt kamal prune all de achterstand meteen in plaats van op het venster van drie dagen te wachten.

VPS-providers en prijzen

Voor een compleet overzicht van de opties, bekijk de VPS-vergelijking.

DigitalOcean is de makkelijkste instap, omdat Kamal de host bewust alleen tot en met Docker beheert — firewallregels, swap en automatische updates blijven jouw werk, en de documentatie van DigitalOcean behandelt alle drie. Hetzner geeft je meer RAM en schijf per euro als je die inrichting zelf wilt doen.

Praktische tips

• Laat op de server alleen poorten 22, 80 en 443 open. kamal-proxy handelt TLS zelf af, meer hoeft niet bereikbaar te zijn.
• Controleer kamal app containers voordat je op een rollback rekent; het doel moet nog op schijf staan.
• Bewaak de vrije schijfruimte met dezelfde alertering als je geheugen. Dit is de storing die stilletjes aankomt.
• Een tweede applicatie op dezelfde host wordt in Kamal 2 ondersteund — kamal-proxy routeert op hostnaam — maar dat verdubbelt het aantal containers en de imagegeschiedenis: kies de schijf op maat voor beide.

Conclusie

Voor de meeste deploys van één applicatie laten 2 vCPU’s, 4 GB RAM en 40 GB SSD of NVMe ruimte voor de app, de database, de deploy-overlap en drie dagen aan rollback-images. Verhoog eerder de schijf dan het geheugen: geheugendruk meldt zichzelf, opgestapelde images niet. Voor meer opties, verken onze VPS-vergelijking.