Coolify, Kamal oder einfach Cloud Run? Wie wir Deployment für jeden Kunden auswählen

Drei Werkzeuge, drei Weltbilder

Sie brauchen kein Kubernetes. Die meisten Teams 2026 brauchen es immer noch nicht. Die Frage ist, welche Nicht-Kubernetes-Deployment-Geschichte zu der Anwendung passt, die Sie ausliefern.

Drei Optionen dominieren das Gespräch:

• Coolify ist ein selbstgehostetes PaaS. Sie betreiben einen Docker-Host, bekommen eine Heroku-ähnliche UI und klicken auf Deploy.
• Kamal ist ein Single-Command-Tool, das Ihr Docker-Image auf einen oder viele Server schiebt, SSL verwaltet und Zero-Downtime-Wechsel macht.
• Cloud Run ist Googles Serverless-Container-Plattform. Sie geben ein Image hinein, bekommen HTTPS, Autoscaling und Bezahlung pro Anfrage.

Jedes ist die richtige Antwort für jemanden. Keines ist die richtige Antwort für alle. Wir haben in den letzten zwölf Monaten alle drei für unterschiedliche Kunden ausgeliefert.

So wählen wir.

Was jedes Werkzeug wirklich ist

Coolify ist das, was Heroku gewesen wäre, wenn Heroku Open Source wäre. Betreiben Sie es auf einer einzelnen Hetzner-Box (oder einer Flotte), verbinden Sie ein Git-Repository, und es baut, deployt und serviert Ihre App hinter einem verwalteten Reverse-Proxy mit Let’s-Encrypt-SSL. Hat 2025 die 50.000-GitHub-Sterne-Marke überschritten und gehört zu den wenigen Open-Source-PaaS-Werkzeugen, hinter denen ein bezahltes Team mit klarem Roadmap-Tempo steht.

Das Kernversprechen: Heroku-artige Developer Experience ohne Heroku-artige Monatsrechnungen. Datenbanken, Caches, Cron-Jobs und Preview-Umgebungen leben alle in der Coolify-UI.

Kamal (genauer: Kamal 2, vorgestellt auf Rails World 2024 und mit Rails 8 ausgeliefert) ist das, was 37signals gebaut hat, um für HEY und Basecamp aus AWS auszubrechen. Es nimmt Ihr Dockerfile, schickt das Image auf einen frischen Linux-Server, richtet kamal-proxy ein (37signals’ eigener Reverse-Proxy, der Traefik in Kamal 2 abgelöst hat), kümmert sich um SSL via Let’s Encrypt, fährt Zero-Downtime-Deploys und verwaltet Geheimnisse über 1Password, Bitwarden, AWS Secrets Manager und mehrere weitere Backends. Ein Befehl: kamal setup. Eine YAML-Datei beschreibt das gesamte Deployment.

Es kann weniger als Coolify. Das ist der Punkt. Es gibt keine UI. Kein Dashboard. Eine Konfigurationsdatei, Ihren Code, eine CLI.

Cloud Run ist die GCP-Serverless-Geschichte. Sie bauen einen Container, schieben ihn ins Artifact Registry, führen gcloud run deploy aus und bekommen eine URL mit Autoscaling von null bis 1.000 Instanzen pro Service (per Quota-Antrag erweiterbar), integriertem Load Balancing, IAM und Bezahlung pro 100 ms (oder Instance-based-Billing, wenn Sie eine Pauschale bevorzugen). Azure Container Apps ist auf den anderen Clouds das passendste Pendant; AWS App Runner spielt in der gleichen Liga, hat aber mehr Einschränkungen (kein Scale-to-Zero im Standard-Tier, weniger Regionen, schwächere Autoscaling-Story). Für deutsche Kunden, die auf europäischen Regionen bestehen, gibt es Cloud Run in Frankfurt und Zürich, Container Apps in mehreren EU-Standorten.

Der Trade-off: Cold Starts, kein persistenter Speicher und ein Preismodell, das bei dauerhaftem mittlerem Traffic teuer wird.

Wann wir Coolify wählen

Wir wählen Coolify, wenn:

• Der Kunde ein selbstgehostetes PaaS mit einer UI will, die seine nicht-entwickelnde Gründerin oder Operations-Leitung nutzen kann.
• Es 5-30 Services zu verwalten gibt (Django-App, n8n-Automatisierung, internes Admin, ein paar Datenbanken, eine Plausible-Instanz).
• EU-Datenresidenz zählt und Hetzner oder ein anderer souveräner Anbieter die richtige Region hat.
• Das Team “in einer UI klicken, um einen Service hinzuzufügen” einer “YAML-Datei bearbeiten und CLI ausführen” vorzieht.

Für solche Kunden betreibt eine Hetzner CCX13 (2 vCPU, 8 GB) Coolify plus eine kleine Konstellation aus Nebendiensten für rund 17 €/Monat, oder etwa 35-50 €, wenn Sie auf eine CCX23 mit 16 GB und ein separates Backup-Volume aufrüsten. Wir haben Kunden geholfen, von einem 1.200-USD/Monat-Heroku-Setup auf ein rund 50-€/Monat-Coolify-Setup umzuziehen, ohne funktionalen Verlust. Ihre Datenbank-Backups landen in S3-kompatiblem Hetzner Object Storage, ihre Slack-Alerts kommen aus Coolifys eingebautem Notifier.

Praktisch wichtig für viele Mittelstandskunden: Coolify lässt sich ausschließlich auf Servern in Deutschland oder einem anderen EU-Land betreiben, ohne dass jemals ein Datenpaket einen US-Cloud-Provider berührt. Das macht den Compliance-Bericht spürbar dünner.

Wo Coolify wehtut: Über eine einzelne starke Box hinaus ist die Multi-Server-Geschichte machbar, aber aufwendiger. Wenn Sie echte Multi-Region oder Zero-Downtime-Datenbankmigrationen über Replicas brauchen, sind Sie aus Coolify herausgewachsen, und das sollten Sie wissen.

Wann wir Kamal wählen

Wir wählen Kamal, wenn:

• Der Kunde auf Rails (8 oder anders) ist und keine UI zwischen sich und sein Deployment haben möchte.
• Das Team klein und technisch ist und lieber fünf Zeilen YAML versteht, als sich durch ein Dashboard zu klicken.
• Die Anwendung im Wesentlichen ein Service plus Datenbank und Cache ist, manchmal mit einem Worker-Prozess dazu.
• Der Kunde vorhandene Infrastruktur-Intuition mitbringt und Dinge minimal halten will.

Für solche Projekte gibt Ihnen Kamal auf einer einzelnen Hetzner CCX13 (oder zwei für HA):

• Eine YAML-Datei, die Sie in einer Minute lesen können.
• Zero-Downtime-Deploys über kamal-proxy-Connection-Draining und Request-Pausing.
• SSL, das einfach funktioniert, via Let’s Encrypt.
• Geheimnisverwaltung über 1Password-CLI-Integration (oder Bitwarden, AWS Secrets Manager, GCP Secret Manager, Doppler).
• Health-Checks, Log-Streaming und Remote-Befehlsausführung als First-Class-Befehle.

Gesamtkosten: 15-30 €/Monat für die kleinste 2-vCPU-/8-GB-Box, je nachdem, ob Sie ein HA-Paar nehmen. Gesamte Deployment-Zeit nach dem initialen Setup: 30-90 Sekunden für eine typische Rails-App.

Wo Kamal wehtut: Wenn Sie viele Services haben, wird der YAML-pro-Service-Ansatz repetitiv. Wenn Ihr Team Nicht-Entwickler einschließt, die deployen müssen, beißt das Fehlen einer UI. Wenn Sie Heroku-artige Preview-Umgebungen pro PR ab Werk brauchen, müssen Sie das skripten.

Wann wir Cloud Run wählen

Wir wählen Cloud Run, wenn:

• Die Anwendung bursty ist: lange Leerlaufphasen, unterbrochen von Traffic-Spitzen.
• Sie Autoscaling auf null brauchen (der Kostenunterschied zählt für Frühphasen-Produkte mit unregelmäßiger Nutzung).
• Das Team aus anderen Gründen bereits in GCP ist (BigQuery, Vertex AI, Pub/Sub).
• Sie verwaltete Zertifikate, verwaltetes Load Balancing und verwaltetes Compute wollen, ohne darüber nachzudenken.
• Compliance Logs und Audit-Trails auf Cloud-Provider-Niveau verlangt.

Für solche Kunden ist Cloud Run + Cloud SQL Postgres + Cloud Tasks für Hintergrundarbeit ein vollständiger Produktionsstack mit faktisch null Ops-Aufwand. Die Preise für ein Frühphasen-Produkt liegen oft unter 20 €/Monat und skalieren linear mit dem Traffic.

Wo Cloud Run wehtut: Cold Starts auf Gen1 liegen je nach Imagegröße und Memory zwischen 200 ms und 2 s, während Gen2 (microVM-Execution-Environment) etwas mehr Cold-Start-Latenz für bessere CPU-Dauerleistung und volle Linux-Kompatibilität eintauscht. Startup CPU Boost und min-instances=1 sind die Standard-Mittel, wenn Cold Starts Ihrer API wehtun.

Sie können keine lang laufenden Hintergrundjobs ausführen, die das Request-Timeout überschreiten, und Sie können keinen persistenten In-Memory-State halten. Sie sind an Googles Preismodell gebunden, und bei dauerhaft hohem Traffic ist eine Hetzner-Box mit Kamal dramatisch günstiger.

Was wir tatsächlich ausliefern

Ein typischer Entscheidungsbaum für neue Kundenprojekte:

• Eine Rails- oder Django-App, kleines Team, EU-Daten, geringe Ops-Lust: Kamal auf Hetzner.
• Multi-Service-Stack, gemischte Sprachen, Gründer will ein Dashboard: Coolify auf Hetzner.
• Bursty-Traffic, GCP-lastiger Stack, Compliance-getrieben: Cloud Run + Cloud SQL.
• Bereits großes Engineering-Team mit Plattform-Engineers: meist ein verwaltetes Kubernetes, aber nur, weil sie es ausdrücklich verlangt haben.

Wir setzen standardmäßig auf Kamal, weil die meisten B2B-SaaS-Kunden, mit denen wir arbeiten, eine Anwendung betreiben, keine Konstellation. Wenn sich das ändert, befördern wir sie auf Coolify, nicht umgekehrt.

Die Werkzeuge wurden für unterschiedliche Teamformen entworfen, und wir versuchen, das Werkzeug zur Form zu wählen, statt das Team ins Werkzeug zu biegen. Wer mit Standardsoftware noch nie zufrieden war, weiß, dass die Werkzeugwahl das Team über Jahre prägt.

Wir haben das größere operative Bild in DevOps für KMU ohne Plattform-Team und die Pipeline, die diese Ziele speist, in CI/CD-Pipelines erklärt beschrieben.

Das Muster über alle drei Werkzeuge ist gleich: Kubernetes-Komplexität für die Apps, die sie wirklich brauchen, einfachere Werkzeuge für die Apps, die sie nicht brauchen. Die meisten B2B-SaaS in 2026 brauchen sie nicht.

Die Infrastrukturfrage, die wirklich zählt, lautet selten “welches Deployment-Werkzeug”. Sie lautet “was ist das Kleinste, das uns sicher in Produktion bringt, mit einem Pfad, den wir in achtzehn Monaten nicht bereuen?”. Wählen Sie das kleinstmögliche Passende. Wechseln Sie, wenn Sie herauswachsen.

Das ist seit zehn Jahren das Playbook. Coolify, Kamal und Cloud Run haben es nur günstiger gemacht, ihm zu folgen, ohne die Heroku-Steuer zu zahlen oder eine Kubernetes-Plattform zu pflegen, die niemand im Team verstehen will.

Sie wählen eine Deployment-Geschichte für ein neues Projekt oder entwirren ein überfrachtetes Cloud-Setup, das Budget verbrennt? Lassen Sie uns reden. Wir schauen uns Ihren echten Traffic, Ihr Team und Ihre Constraints an und sagen ehrlich, welches dieser drei (oder keines) passt.