Kamal ist ein Deployment-Werkzeug, das auf Ihrem eigenen Rechner oder CI-Runner läuft, nicht auf dem Server. „Kamal VPS-Anforderungen” ist also in Wahrheit eine Frage nach der Maschine, auf die Kamal deployt: Sie muss Ihre Anwendungs-Container tragen, dazu kamal-proxy, die deklarierten Accessories und einige Tage alter Images für Rollbacks.
Kamals eigener Ressourcenbedarf auf dem Host ist null. Dimensionieren Sie alles andere.
Was auf dem Host Ressourcen verbraucht
Nach kamal setup laufen auf dem Server drei Dinge:
- kamal-proxy, ein kleiner HTTP-Proxy in Go auf den Ports 80 und 443
- Ihre App-Container, ein Satz pro Rolle aus
config/deploy.yml - Accessories — Postgres, Redis oder was Sie sonst deklariert haben
Für die Dimensionierung zählen nur die beiden mittleren. kamal-proxy ist eine einzelne statische Binärdatei und verschwindet neben jeder echten Anwendung.
Arbeitsspeicher
Die Zahl, die viele überrascht, ist nicht der Normalbetrieb, sondern die Deploy-Überlappung. Kamal startet den neuen Container, während der alte noch Traffic bedient, und stoppt den alten erst, wenn der neue seinen Health-Check bestanden hat. Der Spitzenbedarf ist also der übliche Verbrauch plus grob eine weitere Kopie des App-Containers.
- Praktisches Minimum: 2 GB, für eine kleine App ohne eigene Datenbank
- Bequem: 4 GB, was eine typische Webanwendung samt Postgres und Deploy-Überlappung abdeckt
- Swap einrichten auf 4-GB-Hosts. Ein Host, der mitten im Deploy zu swappen beginnt, kann so langsam werden, dass er das Health-Check-Fenster verpasst — der Deploy rollt dann scheinbar grundlos zurück.
Betreiben Sie Postgres als Kamal-Accessory statt als verwalteten Dienst, dimensionieren Sie ausdrücklich dafür: Nicht Kamal, sondern die Datenbank wird der größte Verbraucher auf der Maschine sein.
CPU
Zwei vCPU sind die sinnvolle Untergrenze, und zwar aus einem Grund, der nichts mit der Dauerlast zu tun hat: Während eines Deploys zieht der Host gleichzeitig ein Image, startet einen Container, führt Health-Checks aus und bedient Traffic aus dem alten Container. Auf einer einzelnen vCPU zieht diese Konkurrenz das Deploy-Fenster in die Länge.
- Minimum: 1 vCPU, brauchbar für eine App mit wenig Traffic, wenn Sie langsamere Deploys hinnehmen
- Empfohlen: 2 vCPU
- Images auf dem VPS selbst zu bauen ist der eine Fall, der wirklich mehr verlangt. Ist Ihr Notebook arm64 und der VPS Ihre einzige amd64-Maschine, nutzt ein Build jeden Kern, den Sie ihm geben.
Speicherplatz
Hier verändert Kamals Verhalten die Zahlen tatsächlich. Kamal behält alte Container und Images auf dem Server, damit kamal rollback eine frühere Version starten kann, ohne aus der Registry zu ziehen, und räumt sie standardmäßig nach drei Tagen auf.
Die Platte muss also fassen:
- Die Daten und Volumes Ihrer Anwendung
- Das aktuelle Image plus etwa drei Tage frühere Versionen
- Gemeinsame Basis-Layer, die unabhängig von der Zahl der Versionen nur einmal gespeichert werden
Ein 1 GB großes Image, mehrmals täglich deployt, passt gut auf 40 GB NVMe. Ein 3 GB großes Image füllt eine 25-GB-Platte binnen einer Woche. Der Fehlerfall lohnt es, sich zu merken: Eine volle Platte bricht den nächsten Deploy ab, nicht den, der sie gefüllt hat — Ursache und Symptom liegen also Tage auseinander.
Wer oft deployt, räumt mit kamal prune all sofort auf, statt auf das Drei-Tage-Fenster zu warten.
VPS-Anbieter und Preise
| Anbieter | Preis pro Monat | Besonderheiten | Affiliate-Link |
|---|---|---|---|
| Contabo | 5,99 EUR | 400 GB Platte, damit ist die Image-Historie nie der Engpass | Contabo |
| Hetzner Cloud | 5,49 EUR | 2 vCPU / 4 GB / 40 GB NVMe, Snapshots vor riskanten Deploys | Hetzner Cloud |
| DigitalOcean | 6 USD | Klarste Dokumentation für die Host-Einrichtung, die Kamal auslässt | DigitalOcean |
| Vultr | 5 USD | Regionsauswahl, nützlich wenn die App nah an ihren Nutzern liegen soll | Vultr |
| Linode (Akamai Cloud) | 5 USD | Kalkulierbare Preise und unkompliziertes Netzwerk | Linode |
Einen umfassenden Überblick gibt der große VPS-Vergleich.
DigitalOcean ist der einfachste Einstieg, weil Kamal den Host bewusst nur bis Docker verwaltet — Firewall-Regeln, Swap und automatische Updates bleiben Ihre Aufgabe, und DigitalOceans Dokumentation deckt alle drei ab. Hetzner gibt Ihnen mehr RAM und Platte pro Euro, wenn Sie diese Einrichtung selbst übernehmen.
Praktische Hinweise
- Öffnen Sie am Server nur die Ports 22, 80 und 443. kamal-proxy terminiert TLS selbst, mehr muss nicht erreichbar sein.
- Prüfen Sie
kamal app containers, bevor Sie sich auf ein Rollback verlassen; das Ziel muss noch auf der Platte liegen. - Überwachen Sie den freien Speicherplatz mit demselben Alarm wie den Arbeitsspeicher. Es ist der Ausfall, der sich leise ankündigt.
- Eine zweite App auf demselben Host unterstützt Kamal 2 — kamal-proxy routet nach Hostname —, das verdoppelt aber Container-Zahl und Image-Historie, dimensionieren Sie die Platte also für beide.
Fazit
Für die meisten Einzel-App-Deployments lassen 2 vCPU, 4 GB RAM und 40 GB SSD oder NVMe Raum für die App, ihre Datenbank, die Deploy-Überlappung und drei Tage Rollback-Images. Erhöhen Sie eher den Speicherplatz als den Arbeitsspeicher: Speicherdruck meldet sich von selbst, angesammelte Images tun das nicht. Weitere Optionen finden Sie im großen VPS-Vergleich.
Frequently asked questions
Wie viel RAM braucht ein VPS als Ziel eines Kamal-Deploys?
Genug für Ihre App, deren Accessories und eine zusätzliche Kopie des App-Containers. Während eines Deploys laufen alter und neuer Container gleichzeitig, der Spitzenbedarf ist also der Normalbetrieb plus ein App-Container. Auf einem 4-GB-Host mit einer 1 GB großen App ist das bequem, sonst richten Sie Swap ein.
Verbraucht Kamal selbst CPU oder Arbeitsspeicher auf dem Server?
Nein. Kamal ist ein Gem, das Sie von Ihrem Rechner oder aus der CI heraus starten und das nach dem Deploy endet. Dauerhaft kommt auf dem Host nur kamal-proxy hinzu, ein kleiner HTTP-Proxy in Go, dessen Verbrauch neben jeder echten Anwendung nicht ins Gewicht fällt.
Warum geht einem Kamal-Host mit der Zeit der Speicherplatz aus?
Kamal behält alte Container und Images, damit Rollbacks ohne Registry-Zugriff auskommen, und räumt sie standardmäßig erst nach drei Tagen auf. Häufige Deploys eines großen Images summieren sich schnell, und die Platte läuft meist mitten in einem späteren Deploy voll, nicht in dem, der sie gefüllt hat.