Coolify vs. Dokploy vs. Kamal: Die richtige Self-Hosted-PaaS für ein kleines SaaS-Team
Ein kleines SaaS-Team braucht selten Kubernetes, aber es braucht einen wiederholbaren Weg zum Ausliefern. Die Lücke zwischen "git push und es deployed" und "per SSH rein, Image ziehen, Container neu starten, hoffen, dass nichts kaputt ging" ist der Ort, an dem sich eine Self-Hosted-PaaS ihren Platz verdient. Coolify, Dokploy und Kamal versuchen alle, diese Lücke auf Hardware zu schließen, die du kontrollierst, und für ein Team von zwei bis zehn Entwicklern, das eine Handvoll Services betreibt, ist eines davon fast sicher die richtige Antwort statt einer verwalteten Plattform, die pro Sitzplatz und pro Dyno abrechnet.
Die drei Tools sehen in einer Feature-Tabelle ähnlich aus und fühlen sich im täglichen Gebrauch völlig unterschiedlich an. Die Entscheidung dreht sich weniger darum, welches die längste Checkliste hat, als darum, wie viel Abstraktion du zwischen deinem Code und deinem Server haben möchtest, wer im Team es besitzen wird und was an dem Tag passiert, an dem es kaputtgeht. Dieser Beitrag geht durch, wie jedes tatsächlich funktioniert, wo es passt, und einen klaren Weg zur Wahl.
Was eine Self-Hosted-PaaS dir tatsächlich bringt
Bevor wir die drei vergleichen, hilft es, ehrlich darüber zu sein, welches Problem du löst. Eine Self-Hosted-PaaS gibt dir vier Dinge: einen Build-Schritt, der einen git push in einen laufenden Container verwandelt, einen Reverse-Proxy, der Traffic routet und TLS terminiert, einen Ort zum Speichern von Umgebungsvariablen und Secrets und irgendeine Möglichkeit, Logs zu sehen und Dinge neu zu starten, wenn sie sich danebenbenehmen. Verwaltete Plattformen wie Heroku, Render oder Fly bündeln all das und verlangen einen Aufschlag dafür, dass du nicht über die zugrunde liegende Maschine nachdenken musst. Die Self-Hosted-Varianten geben dir denselben Workflow auf einem VPS, der 20 bis 60 Euro im Monat kostet, im Tausch dafür, dass du das Patchen, die Backups und die gelegentliche Wiederherstellung um 2 Uhr nachts besitzt.
Dieser Tausch lohnt sich meist, sobald deine verwaltete Rechnung ein paar Hundert Euro im Monat überschreitet, oder sobald Compliance dich dazu drängt, Daten auf Infrastruktur zu halten, auf die du auf einer Rechnung zeigen kannst. Er lohnt sich selten, wenn du niemanden hast, der sich auf einer Linux-Box wohlfühlt. Das Tool, das du wählst, bestimmt hauptsächlich, wie oft du dich dort wohlfühlen musst.
Coolify: Der vollständige Heroku-Ersatz
Coolify ist das ehrgeizigste der drei. Es ist eine Self-Hosted-Plattform mit einem Web-Dashboard, das Anwendungen, Datenbanken, geplante Jobs und sogar Ein-Klick-Open-Source-Services über einen oder viele Server verwaltet. Du richtest es auf einen frischen VPS, verbindest ein Git-Repository, und es übernimmt den Build (Nixpacks oder dein Dockerfile), den Traefik-basierten Proxy, automatische Let's-Encrypt-Zertifikate und eine UI für Umgebungsvariablen, Logs und Rollbacks. Für ein Team, das die Heroku-Erfahrung ohne die Heroku-Rechnung will, ist es die nächstliegende Entsprechung.
Die Stärke ist die Breite. Du kannst dein Next.js-Frontend, eine Symfony-API, eine Postgres-Instanz, einen Redis-Cache und einen Cron-Worker aus einem Dashboard betreiben und einen Entwickler ohne DevOps-Hintergrund hinzuziehen, der deployen kann, ohne ein Terminal anzufassen. Die Kosten dieser Breite sind ein schwereres bewegliches Teil auf deinem Server. Coolify ist eine langlaufende Anwendung mit einer eigenen Datenbank und Hintergrund-Workern, und wenn sie ein schlechtes Upgrade hat oder ihre Proxy-Konfiguration abdriftet, debuggst du Coolify zusätzlich zu deiner App. Es ist die Option, die am ehesten einen Junior-Entwickler produktiv macht, und die, die dich bei einem größeren Versionssprung am ehesten überrascht. Behandle den Coolify-Host als Produktionsinfrastruktur und halte Backups seiner Konfiguration, nicht nur deiner App-Daten.
Dokploy: Die leichtere, Compose-freundliche Mitte
Dokploy besetzt den Mittelweg. Es bietet eine ähnliche Dashboard-getriebene Erfahrung wie Coolify, mit Anwendungs-Deployments, Datenbanken und einem Traefik-Proxy, lehnt sich aber stärker auf Docker Compose als Deployment-Einheit und behält eine kleinere Oberfläche. Für Teams, die bereits in docker-compose.yml-Dateien denken, fühlt sich Dokploy natürlich an: Du beschreibst den Stack, und es gibt dir die Deploy-Pipeline, TLS und Monitoring drumherum, ohne dich zu bitten, ein neues mentales Modell zu lernen.
In der Praxis ist Dokploy eine gute Wahl, wenn du den Großteil des Coolify-Komforts willst, Coolify aber schwerer findest, als deine Bedürfnisse rechtfertigen, oder wenn deine Services bereits Compose-definiert sind und du sie nicht in eine plattformspezifische Abstraktion neu ausdrücken möchtest. Der Kompromiss ist Reife und Ökosystem. Dokploy ist neuer und bewegt sich schnell, was weniger kampferprobte Randfälle und eine kleinere Community bedeutet, die man durchsuchen kann, wenn sich etwas seltsam verhält. Für ein kleines Team, das sich beim Lesen von Compose-Dateien wohlfühlt und sich gelegentlich die Hände schmutzig macht, ist das ein akzeptabler Preis für ein leichteres, transparenteres System.
Kamal: Kein Dashboard, nur Deploys
Kamal ist der Außenseiter, und das absichtlich. Es ist kein Server, den du installierst und hütest; es ist ein Kommandozeilen-Tool, das von deinem Laptop oder CI läuft und Docker-Container über SSH auf einen oder mehrere Hosts deployed. Es gibt kein Web-Dashboard, keine ständig laufende Control Plane und fast nichts Zusätzliches, das auf deinen Servern läuft, außer deiner App, einem kleinen Proxy und was auch immer du explizit hinzufügst. Du beschreibst dein Deployment in einer einzigen Konfigurationsdatei, führst kamal deploy aus, und es baut das Image, pusht es in eine Registry und macht einen rollenden Neustart ohne Ausfallzeit über deine Hosts.
Der Reiz ist, dass es zwischen Deploys nichts gibt, das kaputtgehen kann. Wenn du nicht deployst, läuft dein Server einfach deine Container, und die Fehlermodi sind die gewöhnlichen, die du ohnehin debuggen würdest. Kamal verlangt vorab mehr von dir: Du schreibst die Konfiguration, du verstehst den Registry- und SSH-Flow, und du bekommst keine Point-and-Click-UI für einen Teamkollegen, der keine will. Im Gegenzug bekommst du das transparenteste und am wenigsten Lock-in-anfällige der drei. Wenn du bereits unsere Sicht auf Kamal gegen Kubernetes für Indie-SaaS gelesen hast, gilt dieselbe Philosophie hier: Es gewinnt, indem es Dinge weglässt.
Wie man tatsächlich wählt
Der ehrliche Entscheidungsbaum ist kurz. Wenn du willst, dass ein Nicht-Entwickler oder ein Frontend-fokussierter Entwickler über eine UI deployed und Datenbanken verwaltet, und du akzeptierst, eine schwerere Control Plane zu betreiben, wähle Coolify. Wenn du bereits in Docker Compose lebst und ein leichteres, transparenteres Dashboard als Coolify willst, ohne komplett auf die Kommandozeile zu gehen, wähle Dokploy. Wenn dein Team sich auf der Kommandozeile wohlfühlt, Wert darauf legt, nichts Zusätzliches zwischen Deploys laufen zu haben, und die geringste langfristige Wartungsoberfläche will, wähle Kamal.
Ein paar sekundäre Faktoren kippen knappe Fälle. Die Teamzusammensetzung zählt am meisten: Ein Dashboard ist viel wert, wenn die Person, die deployed, kein Backend-Entwickler ist, und fast nichts wert, wenn alle es sind. Lock-in zählt als Nächstes: Kamal lässt dich mit reinem Docker und SSH zurück, während Coolify und Dokploy mehr deiner Konfiguration besitzen, also wäge ab, wie schmerzhaft eine Migration weg vom Tool wäre. Zähle schließlich den Wirkungsradius. Bei Coolify und Dokploy ist die Control Plane etwas, das unabhängig von deiner App scheitern kann; bei Kamal gibt es keine Control Plane, die scheitern kann, aber auch keine UI, wenn du um 2 Uhr nachts eine willst.
Was du auch wählst, der Teil, den Teams unterschätzen, ist die operative Verantwortung rund um das Tool, nicht das Tool selbst. Backups, Server-Patching, Secret-Rotation und ein getestetes Wiederherstellungs-Runbook sind dieselbe Arbeit, unabhängig davon, welcher Deployer obendrauf sitzt, und sie sind der Unterschied zwischen einer Self-Hosted-PaaS, die Geld spart, und einer, die still zur Belastung wird. Den Deployer zu wählen ist die einfachen 20 Prozent; die dauerhaften 80 Prozent sind die Tech-Stack-Strategie und operative Disziplin, die du darum herum aufbaust.
Wo Wolf-Tech hineinpasst
Wir helfen kleinen SaaS-Teams, genau diese Art Entscheidung zu treffen, ohne sich in Infrastruktur zu verrennen, für die sie personell aufstocken müssten. Manchmal bedeutet das, Coolify aufzusetzen, damit ein schlankes Team ausliefern kann, ohne einen dedizierten Platform-Engineer, manchmal bedeutet es ein in CI verdrahtetes Kamal-Setup für ein Backend-lastiges Team, und manchmal bedeutet es, einen Schritt zurückzutreten und zu hinterfragen, ob das Deployment-Tool überhaupt der eigentliche Engpass ist. Wenn du diese Optionen für einen Custom-Software-Build abwägst oder eine zweite Meinung möchtest, bevor du dich festlegst, fördert ein kurzes Code- und Infrastruktur-Review die Antwort meist schneller zutage als eine weitere Woche Test-Deploys.
Wenn das nützlich klingt, schreib uns unter hello@wolf-tech.io oder besuche wolf-tech.io. Wir schauen uns gern dein aktuelles Setup an und sagen dir klar, welches dieser drei zu deinem Team passt und welches nur ein neues Ding zum Warten wäre.