Cloudron vs CasaOS vs Coolify Vergleich

Was Sie aufbauen

Die Auswahl eines Tools ist ebenso wichtig wie die Installation selbst. Drei Panels versprechen, einen nackten VPS in einen Point-and-Click-App-Host zu verwandeln: Cloudron, CasaOS und Coolify. Dieser Leitfaden installiert jedes Tool auf einer frischen Ubuntu 24.04 Instanz, installiert eine erste App und analysiert anschließend die Aspekte, die selten dokumentiert werden: TLS, Backups, Updates, Arbeitsspeicherverbrauch und die Schwierigkeit eines Wechsels. Am Ende wissen Sie, welches Tool geeignet ist oder ob die ehrlichste Antwort „keines von ihnen, nutzen Sie einfach Docker Compose“ lautet.

Keines dieser Tools ist magisch. Unter allen drei Systemen läuft dieselbe Docker Engine, die Sie auch manuell steuern könnten. Was ein Panel Ihnen verkauft – sei es durch Kosten, RAM-Verbrauch oder Vendor Lock-in – sind vier automatisierte Aufgaben: Ein-Klick-App-Installationen, automatische TLS-Zertifikate, geplante Backups und Benutzerverwaltung. Wenn diese vier Funktionen den zusätzlichen Overhead für Sie rechtfertigen, lohnt sich die Nutzung eines Panels. Wenn Sie nur ein oder zwei Dienste betreiben und genau wissen möchten, was auf Ihrem System läuft, lesen Sie zuerst den Abschnitt „Alle drei überspringen“, um sich die Arbeit zu ersparen.

Gemeinsame Voraussetzungen und bekannte Fallstricke

Alle drei Optionen setzen einen KVM VPS voraus, keine Container-Virtualisierung. Docker benötigt einen echten Kernel; Cloudron unterstützt OpenVZ und LXC nicht. Prüfen Sie dies mit systemd-detect-virt: kvm oder qemu ist zulässig, openvz oder lxc ist nicht zulässig. Bei einem KVM-Tarif gibt der Befehl kvm aus, bei Bare Metal none; in beiden Fällen können Sie fortfahren.

Danach unterscheiden sich die Anforderungen, was das primäre Entscheidungskriterium darstellt.

• RAM. CasaOS läuft mit 1 GB problemlos; es wurde für Raspberry Pi Hardware entwickelt und bleibt ressourcensparend. Coolify benötigt mindestens 2 GB RAM und zwei CPU-Kerne, wobei etwa 600 MB allein für Coolify reserviert sind. Cloudron benötigt mindestens 2 GB RAM und läuft mit 4 GB deutlich stabiler, da bereits vor der Installation einer App ein Mailserver und eine Datenbank laufen.
• Eine Domain und DNS-Kontrolle. Sowohl Cloudron als auch Coolify benötigen eine echte Domain mit funktionierendem DNS. Cloudron benötigt idealerweise API-Zugriff auf Ihren DNS-Anbieter, um Einträge und Wildcard-Zertifikate selbstständig zu erstellen. CasaOS läuft auch über eine reine IP, aber dann ist kein TLS verfügbar.
• Ports. Alle drei benötigen die offenen Ports 80 und 443 für HTTP und HTTPS. Coolify nutzt zusätzlich den Port 8000 für das Dashboard, 6001 für den Realtime-Kanal und 6002 für das Terminal im Browser. Lassen Sie den Port 22 für SSH bei allen Systemen offen.

Konfigurieren Sie das DNS für den Server, bevor Sie beginnen. Ein Panel, das seinen eigenen Hostnamen nicht auflösen kann, kann keine Zertifikate anfordern. Sie würden die erste Stunde mit der Fehlersuche verbringen, anstatt die Software zu nutzen. Erstellen Sie einen A-Record auf die Server-IP. Fügen Sie für Coolify einen Wildcard-Eintrag (*.apps.example.com) hinzu, damit jede installierte App eine eigene Subdomain erhält.

Cloudron: das optimierte, spezialisierte Appliance

Was es ist. Cloudron ist eine kommerzielle Plattform, die einen gesamten Server in ein verwaltetes Appliance verwandelt. Es betreibt einen eigenen Reverse Proxy, eine Datenbank und einen Mail-Stack sowie einen kuratierten App Store mit vorinstallierten Apps (Nextcloud, WordPress, Gitea, Mattermost und weitere). Es richtet sich an Nutzer, die eine verwaltete Umgebung mit automatischen Updates, automatischen Zertifikaten und automatischen Backups suchen und bereit sind, dafür zu bezahlen.

Installation. Cloudron erfordert ein sauberes System und übernimmt dieses vollständig. Führen Sie dies nur auf einem frischen Ubuntu 24.04 (Noble) Server aus:

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Das Skript installiert Docker, nginx, eine Datenbank und den Mail-Stack und startet den Server anschließend neu. Wenn der Server wieder verfügbar ist, öffnen Sie https://<your-ip>, akzeptieren Sie das temporäre selbstsignierte Zertifikat und schließen Sie die Einrichtung im Browser ab: Geben Sie Ihre Domain an, wählen Sie Ihren DNS-Provider aus, und das Dashboard wird unter my.example.com bereitgestellt.

Hinzufügen der ersten App. Öffnen Sie im Dashboard den App Store, wählen Sie beispielsweise Nextcloud, geben Sie die Subdomain files.example.com an und klicken Sie auf Install. Cloudron erstellt den DNS-Eintrag, fordert das Let's Encrypt-Zertifikat an, stellt die Datenbank bereit, konfiguriert Single Sign-On und plant ein Backup. Dies geschieht alles, ohne dass eine Konfigurationsdatei manuell bearbeitet werden muss. Dies ist das Kernversprechen, das eingehalten wird.

TLS und Backups. Dies ist eine der wichtigsten Funktionen. Jede App-Subdomain erhält ein automatisches Let's Encrypt-Zertifikat, das automatisch erneuert wird. Backups sind integriert und werden nach Plan erstellt. Als Ziel dienen lokale Verzeichnisse, S3 oder andere Remote-Speicher. Es sind Wiederherstellungen pro App sowie ein Ein-Klick-Cloning einer App auf eine neue Subdomain möglich.

Kosten und Lizenzierung, lesen Sie dies vor der Entscheidung. Cloudron ist ein kostenpflichtiges Produkt mit einer limitierten kostenlosen Version: Der kostenlose Plan erlaubt zwei Apps. Wenn Sie eine dritte App installieren, erscheint eine Paywall; ein kostenpflichtiges Abonnement (Pro oder Max, monatlich oder jährlich abrechenbar, beide mit unbegrenzten Apps) schaltet weitere Funktionen frei. Dies ist die wichtigste Information über Cloudron. Die hohe Qualität resultiert aus dem Geschäftsmodell; die kostenlose Version ist eher als erweiterte Testversion zu verstehen und nicht für einen wachsenden App-Stack gedacht.

Fehlermodus, die Clean-Box-Regel. Der Versuch, Cloudron auf einem Server zu installieren, auf dem bereits Dienste laufen, führt zum Abbruch der Einrichtung, bevor Änderungen vorgenommen werden:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

Die Ursache ist keine unnötige Kompliziertheit. Cloudron nutzt spezifische Versionen von nginx, Docker und Node und integriert diese tiefgreifend. Daher können diese nicht mit Ihren eigenen Installationen koexistieren. Die Lösung ist ein frisches Ubuntu 24.04 Image und nichts anderes: kein Webserver, kein Docker und nicht einmal eine manuell konfigurierte Firewall. Falls ein falsches Image verwendet wurde, verweigert die Einrichtung zudem alles, was kein unterstütztes Ubuntu LTS (22.04 oder 24.04) auf x86-64 ist; ARM, LXC und OpenVZ werden nicht unterstützt.

Zweiter Fehlermodus, Wildcard-Zertifikate benötigen DNS-API. Wenn Sie während der Einrichtung die Option "Manual" für DNS wählen, anstatt Cloudron einen API-Token zu geben, kann das System keine Einträge oder Wildcard-Zertifikate erstellen. Bei jeder neuen App müssen Sie dann manuell einen DNS-Eintrag hinzufügen, bevor das Zertifikat ausgestellt werden kann; das Dashboard wartet auf diesen Eintrag. Wenn Sie Cloudron API-Zugriff für einen unterstützten DNS-Provider (Cloudflare, Route 53, DigitalOcean und andere) gewähren, erfolgt der gesamte Prozess mit nur einem Klick.

CasaOS: das kostenlose Home-Lab-Dashboard

Was es ist. CasaOS von IceWhale ist ein kostenloses Open-Source-Dashboard, das auf Docker aufbaut. Es bietet einen Startbildschirm, einen App Store und einen Dateimanager. Es wurde für den Home-Server-Bereich entwickelt. Die Schwerpunkte liegen auf schneller Einrichtung, einer benutzerfreundlichen UI und geringem Konfigurationsaufwand. Es richtet sich an Bastler, die eine grafische Oberfläche für Docker ohne Kosten suchen.

Installation. Ein Befehl genügt, und ein sauberes Betriebssystem ist nicht erforderlich:

curl -fsSL https://get.casaos.io | sudo bash

Der Installer fügt mehrere systemd-Services hinzu (casaos, casaos-gateway, casaos-app-management und weitere). Bestätigen Sie, dass das Gateway bereit ist, bevor Sie einen Browser öffnen:

systemctl status casaos-gateway

Im laufenden Betrieb ist das Dashboard unter http://<your-ip> erreichbar (einfaches HTTP, Port 80). Erstellen Sie ein lokales Konto, um den Zugriff zu erhalten.

Hinzufügen der ersten App. Öffnen Sie den App Store, wählen Sie eine App und klicken Sie auf Install. CasaOS erstellt im Hintergrund ein Docker Compose Projekt und stellt die App auf einem Host-Port bereit, zum Beispiel http://<your-ip>:8080. Der Store enthält gängige Home-Server-Anwendungen. Ein Jellyfin Media-Server auf einem VPS oder eine selbst gehostete Immich Fotobibliothek ist mit wenigen Klicks installiert. Sie können auch beliebige docker-compose.yaml importieren. Das ist die eigentliche Stärke: Die Apps sind Standard-Container und kein proprietäres Format.

TLS und Backups, die Schwachstellen. Hier zeigt sich der Preis für die kostenlose Nutzung. CasaOS überträgt standardmäßig alles über einfaches HTTP, einschließlich des eigenen Dashboards. Es gibt kein integriertes Let's Encrypt und keine integrierten geplanten Backups. Ihre Daten liegen in Docker-Volumes unter /DATA. Die Sicherung der Daten liegt in Ihrer Verantwortung (z. B. via cron mit restic oder tar).

Fehlermodus: Kein TLS und keine Fehlermeldung. Es treten keine Fehler auf. Sie installieren eine App, öffnen http://<your-ip>:8080 und sie funktioniert über eine unverschlüsselte Verbindung, die Ihr Browser als "Nicht sicher" markiert. Passwörter und Session-Cookies werden im Klartext übertragen. Schlimmer noch: CasaOS wies Sicherheitslücken für Remote-Code-Execution im Dashboard auf (CVE-2023-37265 und CVE-2023-37266, ein Authentication Bypass, der zur vollständigen Kompromittierung des Hosts führte). Das direkte Öffnen des HTTP-Ports im Internet stellt daher ein echtes Risiko dar. Die Lösung besteht darin, CasaOS niemals direkt zu exponieren. Schalten Sie einen Reverse Proxy davor, der TLS terminiert, wie zum Beispiel nginx mit einem Let's Encrypt Zertifikat von Certbot, Caddy oder einen Cloudflare Tunnel, und leiten Sie die Anfragen nur im lokalen Netzwerk an CasaOS weiter. Beachten Sie, dass CasaOS bereits Port 80 belegt. Ihr Proxy und CasaOS werden um diesen Port konkurrieren, sofern Sie CasaOS nicht vorher auf einen anderen Port verschieben.

Kosten. Echte Kostenlosigkeit ohne Limitierung der App-Anzahl. Der Aufwand liegt in der Administration: Sie müssen TLS, Backups und das Hardening selbst verwalten.

Coolify: das selbst gehostete PaaS

Was es ist. Coolify ist ein Open-Source, selbst gehostetes Platform-as-a-Service, ähnlich wie Heroku oder Vercel, jedoch auf der eigenen Hardware. Die grundlegende Einheit ist nicht „installiere diese App-Paket“, sondern „deploye dieses Git-Repository“: Verbinden Sie ein Repository, und Coolify baut es (via Nixpacks oder das eigene Dockerfile) und stellt es bereit. Bei jedem Push erfolgt ein erneutes Deployment. Es bietet zudem Datenbanken und Services mit One-Click-Installation. Es richtet sich an Entwickler, die ihren eigenen Code deployen und Push-to-Deploy nutzen möchten, ohne ein kommerzielles PaaS zu mieten.

Installation.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Das Skript installiert Docker und startet den Coolify-eigenen Container-Stack. Prüfen Sie den Status der Container, bevor Sie fortfahren:

docker ps --format 'table {{.Names}}\t{{.Status}}'

Sie sollten sehen, dass coolify, coolify-db, coolify-redis, coolify-realtime und coolify-proxy alle den Status Up melden. Das Dashboard ist unter http://<your-ip>:8000 erreichbar. Erstellen Sie sofort Ihr Admin-Konto, da die Registrierungsseite offen bleibt, bis das erste Konto erstellt wurde. Wer zuerst die Seite erreicht, kontrolliert den Server. Setzen Sie anschließend Ihre Instanz-Domain und richten Sie einen Wildcard-DNS-Eintrag (*.example.com oder *.apps.example.com) auf den Server, damit Coolify jeder deployten App eine eigene Subdomain zuweisen kann.

Hinzufügen der ersten App. Verbinden Sie eine Git-Quelle (GitHub, GitLab oder eine einfache Repository-URL), wählen Sie einen Branch, legen Sie die Domain fest und starten Sie das Deployment. Der integrierte Traefik-Proxy von Coolify routet die Subdomain und fordert das Zertifikat an. Für Standardsoftware ermöglicht der Services-Katalog das Deployment mit wenigen Klicks: Der n8n workflow-automation stack, den man sonst manuell konfigurieren müsste ist ein Eintrag, ebenso wie Uptime Kuma für das Status-Page-Monitoring.

TLS und Backups. Automatische Let's Encrypt-Zertifikate pro App über den enthaltenen Traefik sorgen dafür, dass jede deployte Subdomain ein Zertifikat erhält. Backups konzentrieren sich primär auf Datenbanken: Sie können Postgres- und MySQL-Dumps auf S3-kompatiblen Speicher planen. Ein Backup der gesamten Instanz (die Coolify-Konfiguration selbst unter /data/coolify) erfolgt manueller; exportieren und speichern Sie diese daher selbst.

Kosten und Lizenzierung. Die selbst gehostete Edition ist vollständig Open-Source und kostenlos, ohne Limitierung der App-Anzahl. Es gibt eine optionale Coolify Cloud (kostenpflichtig), die die Control Plane für Sie hostet, während Ihre Apps weiterhin auf Ihren eigenen Servern laufen. Dies ist komfortabel, aber nicht erforderlich.

Fehlerszenario: Die App wird deployt, aber die Domain lädt nicht. Das Dashboard funktioniert unter http://<ip>:8000 einwandfrei und der Build ist erfolgreich (grün), aber die URL der App liefert einen Verbindungsfehler oder einen Traefik 404 page not found. Dies deutet auf den Proxy oder DNS hin, nicht auf die App. Es gibt zwei häufige Ursachen. Erstens: Die Ports 80 oder 443 waren bereits belegt, als der Proxy starten wollte, wodurch der Container mit einem Docker-Fehler beendet wurde:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Zweitens fehlt der Wildcard-DNS-Eintrag, sodass Traefik nie eine Anfrage für diesen Hostnamen erhält. Wenn hingegen die gesamte Server-Karte in Coolify "Server is not reachable" anzeigt, liegt ein anderer Fehler vor: Coolify kann nicht mit dem Docker-Socket des Servers kommunizieren, meist aufgrund eines gestoppten Docker-Daemons oder eines ungültigen SSH-Keys. Lesen Sie den genauen Grund in den Logs, bevor Sie raten:

docker logs coolify-proxy --tail 100

Beheben Sie den Fehler auf der Proxy-Seite: Klicken Sie auf Restart Proxy oder setzen Sie die Proxy-Konfiguration auf Standard zurück und starten Sie sie neu. Warten Sie etwa zwei Minuten, bis der Prozess abgeschlossen ist. Halten Sie Port 8000 nur für Ihre eigene IP erreichbar (oder öffnen Sie ihn temporär, falls der Proxy Fehler verursacht), anstatt ihn für die ganze Welt offen zu lassen. Der Port dient der Bereitstellung des Dashboards über HTTP; in der Coolify-Dokumentation heißt es, dass die Ports 8000, 6001 und 6002 geschlossen werden können, sobald das Dashboard über die eigene Domain erreichbar ist.

Ressourcenverbrauch auf demselben VPS

Gemessen im Leerlauf auf demselben 4GB-System, bevor eine tatsächliche Arbeitslast bereitgestellt wird. Überprüfen Sie Ihren Verbrauch mit free -m und docker stats --no-stream, anstatt sich auf einen einzelnen Wert zu verlassen, da der Gesamtverbrauch je nach App-Mix variiert.

• CasaOS ist am leichtesten. Das Panel besteht aus einer kleinen Anzahl von Go-Services; rechnen Sie mit etwa 150 bis 300 MB Overhead zusätzlich zu den von Ihnen ausgeführten Containern.
• Coolify führt mehrere eigene Support-Container aus (die App, Postgres, Redis, einen Realtime-Service und Traefik). Der Verbrauch liegt im Leerlauf bei etwa 600 MB bis 1 GB, bevor Sie etwas bereitstellen.
• Cloudron ist im Ruhezustand am schwersten, da es ein eigenes nginx, eine Datenbank, einen Mail-Stack und Monitoring ausführt, unabhängig von deren Nutzung. Planen Sie 1 bis 1,5 GB im Leerlauf ein. Aus diesem Grund fordert Cloudron mindestens 2GB und arbeitet bei 4GB effizienter.

Auf einem kleinen 2GB VPS lässt CasaOS den meisten Platz für tatsächliche Apps, während Cloudron den wenigsten Platz lässt. Wenn Ihr Plan 2GB vorsieht und Sie Cloudron mit dem laufenden Mailserver nutzen möchten, planen Sie ein Upgrade des Systems ein.

Updates, Backups und Vergleich des Lock-in-Effekts

Updates. Cloudron aktualisiert die Plattform und jede App nach einem getesteten Zeitplan: dies erfordert minimalen Aufwand und bietet maximale Unterstützung. Coolify aktualisiert sich selbst über das eigene Dashboard mit einem Klick. CasaOS aktualisiert das Panel über das Install-Script oder apt, aber die installierten Apps müssen manuell aktualisiert und neu gestartet werden.

Lock-in, das Problem im zweiten Jahr. CasaOS bietet die geringste Abhängigkeit: Die Apps sind gewöhnliche Compose-Projekte. Sie können die docker-compose.yaml und die Volumes unter /DATA auf einen anderen Host kopieren und den Betrieb fortsetzen. Coolify liegt im Mittelfeld: Ihre Deployments bestehen aus eigenen Dockerfiles und Repositories, aber die Konfiguration wird in der Datenbank von Coolify gespeichert. Ein Host-Wechsel erfordert daher die Neuerstellung der Projekte auf dem Zielsystem. Cloudron weist die höchste Abhängigkeit auf: Die Apps sind Cloudron-spezifisch verpackt. Während Ihre Daten durch die exzellenten Backups problemlos exportiert werden können, ist dies bei der Paketierung nicht der Fall. Daher müssen Sie die Apps auf der Zielplattform neu bereitstellen. Die Daten sind portabel, die Infrastruktur nicht.

Welche Option Sie wählen sollten

Zuerst die Kurzfassung, dann die Details. Wählen Sie Cloudron, wenn Sie die geringste manuelle Serververwaltung benötigen, mehrere Pakete ausführen möchten und eine jährliche Gebühr für verwaltetes TLS, Backups und Updates zahlen möchten. Wählen Sie CasaOS, wenn dies ein Home-Lab hinter Ihrem eigenen Netzwerk oder ein Reverse Proxy ist, Sie eine benutzerfreundliche Docker-Oberfläche suchen und keine Kosten verursachen möchten. Wählen Sie Coolify, wenn Sie eigenen Code von Git deployen und Push-to-Deploy mit automatischem TLS ohne die Kosten eines gehosteten PaaS nutzen möchten. Falls keine dieser drei Optionen auf Sie zutrifft, finden Sie im nächsten Abschnitt die ehrliche Antwort.

Überspringen Sie alle drei, wenn...

Seien Sie ehrlich bezüglich Ihrer Skalierung. Wenn Sie nur ein oder zwei Apps betreiben oder genau kontrollieren wollen, was auf Ihrem System installiert ist, überspringen Sie die Panels. Der Overhead und der Lock-in stehen bei einem kleinen, stabilen Stack nicht im Verhältnis zum Nutzen. Der DIY-Ansatz besteht aus einem Reverse Proxy vor Ihren eigenen Compose-Files: Traefik mit automatischem TLS vor mehreren Docker Compose Apps bietet Ihnen das Äquivalent zu One-Click-HTTPS ohne den Ballast eines Panels, und Sie erstellen Backups mit einem cron-gesteuerten restic-Job, den Sie tatsächlich verstehen.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

Für eine einzelne Hauptanwendung ist die Situation noch klarer: Eine Nextcloud-Installation auf Docker mit TLS und eigener Backup-Routine besteht aus einer Compose-Datei und einem Zertifikat. Das Aufsetzen eines kompletten Appliances für diesen Zweck wäre mit zu hohen Kosten und ohne entsprechenden Nutzen verbunden. Wenn Sie noch entscheiden müssen, was Sie ausführen sollen, bevor Sie entscheiden, wie Sie es ausführen, ist der Leitfaden dazu, was sich 2026 zum Self-Hosting lohnt der bessere Ausgangspunkt.

FAQ

Benötige ich überhaupt ein Self-Hosting-Panel?

Nur wenn Sie die vier Funktionen nutzen möchten, die ein Panel über verschiedene Apps hinweg automatisiert: One-Click-Installations, automatisches TLS, geplante Backups und Benutzerverwaltung. Für ein oder zwei Dienste bietet Docker Compose hinter Traefik dieselbe TLS-Funktionalität mit deutlich weniger Overhead und ohne Lock-in-Effekt. Panels lohnen sich erst, wenn Sie viele Apps betreiben und Ihre Zeit wertvoller ist als der benötigte RAM.

Welches Panel ist am besten für Anfänger geeignet?

Für ein Home-Lab ohne Internet-Exposition ist CasaOS der einfachste Einstieg: ein Befehl und eine benutzerfreundliche UI ohne Kosten. Sie müssen jedoch einen TLS-terminierenden Reverse Proxy vorschalten, bevor Sie Dienste öffentlich zugänglich machen, da CasaOS nur HTTP ausliefert. Wenn Sie eine verwaltete TLS- und Backup-Lösung suchen und bereit sind, dafür zu bezahlen, ist Cloudron mit seinem Limit von zwei kostenlosen Apps die am einfachsten zu bedienende Option.

Ist Cloudron kostenlos?

Teilweise. Die kostenlose Version erlaubt zwei Apps, was für Testzwecke oder sehr kleine Setups ausreicht. Darüber hinaus ist Cloudron ein kostenpflichtiges Abonnement mit monatlicher oder jährlicher Abrechnung; die kostenpflichtigen Stufen erlauben unbegrenzte Apps. Es handelt sich um ein kommerzielles Produkt mit einem limitierten kostenlosen Plan, nicht um freie Software. Planen Sie entsprechende Kosten ein, falls Ihr Stack wächst.

Kann ich diese Panels neben meinen bestehenden Apps betreiben?

Cloudron: nein. Es erfordert ein sauberes Ubuntu-System und bricht ab, wenn nginx, Docker oder Node bereits installiert sind, da es das gesamte System verwaltet. CasaOS und Coolify sind flexibler, da sie ihren eigenen Docker-Stack installieren und prinzipiell einen Host teilen können. Da beide jedoch die Ports 80 und 443 belegen, kommt es zu Konflikten mit bereits laufenden Webservern oder Proxies. Auf einem bereits genutzten System ist ein Panel meist das falsche Werkzeug; nutzen Sie stattdessen Traefik und Compose.

Wie wechsle ich später von einem Panel weg?

Planen Sie die Migration, bevor sie notwendig wird. Bei CasaOS kopieren Sie das docker-compose.yaml der App sowie die /DATA Volumes auf den neuen Host und starten diese neu. Bei Coolify exportieren Sie die Konfiguration jedes Projekts und verweisen auf die gleichen Repositories auf dem Zielsystem. Bei Cloudron stellen Sie die Daten aus den Backups in frisch installierte Apps auf der neuen Plattform wieder her, da die Cloudron-Paketierung nicht übertragen wird, sondern nur die Daten. Testen Sie die Wiederherstellung in jedem Fall auf einem Testsystem, bevor Sie das alte System abschalten.