Cloudron, CasaOS oder Coolify auf dem VPS im Vergleich

Was Sie aufbauen

Sie wählen nicht nur ein Tool aus, sondern auch den damit verbundenen Installations- und Verwaltungsaufwand. Drei Panels versprechen, einen leeren VPS in einen App-Host mit grafischer Bedienung zu verwandeln: Cloudron, CasaOS und Coolify. Dieser Leitfaden installiert jedes davon auf derselben frischen Ubuntu-24.04-Instanz und richtet jeweils eine erste App ein. Anschließend werden die Aspekte betrachtet, die in Screenshots meist fehlen: TLS, Backups, Updates, Speicherbedarf und die Frage, wie schwierig ein späterer Wechsel ist. Am Ende wissen Sie, welches Panel zu Ihnen passt. Oder die ehrliche Antwort lautet: „Keines davon, verwenden Sie einfach Docker Compose.“

Keines dieser Tools ist magisch. Unter allen drei läuft dieselbe Docker Engine, die Sie auch manuell verwalten könnten. Was Ihnen ein Panel gegen Geld, zusätzlichen RAM-Verbrauch oder durch einen Vendor-Lock-in abnimmt, sind vier Aufgaben: App-Installationen mit einem Klick, automatische TLS-Zertifikate, geplante Backups und Benutzerverwaltung. Wenn Ihnen diese vier Funktionen den tatsächlichen Mehraufwand wert sind, lohnt sich ein Panel. Wenn Sie nur ein oder zwei Dienste betreiben und genau wissen möchten, was auf Ihrem Server läuft, lesen Sie zuerst den Abschnitt „Alle drei überspringen“. So sparen Sie sich unnötigen Aufwand.

Gemeinsame Voraussetzungen und wichtige Einschränkungen

Alle drei setzen einen KVM-VPS voraus, keine Container-Virtualisierung. Docker benötigt einen echten Kernel, und Cloudron lehnt OpenVZ und LXC ausdrücklich ab. Prüfen Sie dies mit systemd-detect-virt: kvm oder qemu ist in Ordnung, openvz oder lxc nicht. Bei einem KVM-Tarif gibt der Befehl kvm aus, auf Bare Metal none. Beide Werte bedeuten, dass Sie fortfahren können.

Darüber hinaus unterscheiden sich die Anforderungen. Das ist der erste entscheidende Punkt bei der Auswahl.

• RAM. CasaOS läuft problemlos mit 1GB. Es wurde für Raspberry-Pi-Hardware entwickelt und bleibt ressourcenschonend. Coolify benötigt mindestens 2GB und zwei CPU-Kerne. Davon entfallen etwa 600 MB auf Coolify selbst. Cloudron benötigt mindestens 2GB und läuft mit 4GB deutlich zuverlässiger, weil es bereits vor der Installation einer einzigen Anwendung einen Mailserver und eine Datenbank betreibt.
• Eine Domain und kontrollierbares DNS. Cloudron und Coolify benötigen beide eine echte Domain mit funktionierendem DNS. Cloudron sollte idealerweise über API-Zugriff auf Ihren DNS-Anbieter verfügen, damit es DNS-Einträge und Wildcard-Zertifikate selbst erstellen kann. CasaOS läuft auch mit einer reinen IP-Adresse. Dann steht Ihnen jedoch kein TLS zur Verfügung.
• Ports. Alle drei benötigen für HTTP und HTTPS die offenen Ports 80 und 443. Coolify stellt sein Dashboard zusätzlich über 8000 bereit und verwendet 6001 für seinen Echtzeitkanal sowie 6002 für das Terminal im Browser. Lassen Sie bei allen drei Systemen Port 22 für SSH geöffnet.

Richten Sie DNS auf den Server, bevor Sie beginnen. Ein Panel, das seinen eigenen Hostnamen nicht auflösen kann, kann kein Zertifikat anfordern. Dann verbringen Sie die erste Stunde mit der Fehlersuche, statt mit der Einrichtung der Software. Legen Sie einen A-Record für die Server-IP-Adresse an. Fügen Sie bei Coolify außerdem einen Wildcard-Record (*.apps.example.com) hinzu, damit jede bereitgestellte Anwendung ihre eigene Subdomain erhält.

Cloudron: die ausgereifte Appliance mit klaren Vorgaben

Was es ist. Cloudron ist eine kommerzielle Plattform, die einen gesamten Server in eine verwaltete Appliance verwandelt. Sie betreibt einen eigenen Reverse Proxy, eine eigene Datenbank und einen eigenen Mail-Stack sowie einen kuratierten App Store mit paketierten Anwendungen (Nextcloud, WordPress, Gitea, Mattermost und weitere). Sie richtet sich an Personen, die ihre Anwendungen verwalten lassen möchten: mit automatischen Updates, automatischen Zertifikaten und automatischen Backups. Dafür wird bezahlt.

Installation. Cloudron setzt ein sauberes System voraus und übernimmt es vollständig. Führen Sie dies auf einem frischen Ubuntu 24.04 (Noble)-Server aus. Es darf nichts anderes installiert sein:

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 führt anschließend einen Reboot durch. 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: Verweisen Sie auf Ihre Domain, wählen Sie Ihren DNS-Provider aus, und Cloudron stellt sein eigenes Dashboard unter my.example.com bereit.

Die erste Anwendung hinzufügen. Öffnen Sie im Dashboard den App Store, klicken Sie beispielsweise auf Nextcloud, wählen Sie die Subdomain files.example.com aus und klicken Sie auf Install. Cloudron erstellt den DNS-Eintrag, fordert das Let's Encrypt-Zertifikat an, richtet die Datenbank ein, konfiguriert Single Sign-on und plant ein Backup. Sie müssen dafür keine Konfigurationsdatei bearbeiten. Das ist der zentrale Vorteil, und er wird erreicht.

TLS und Backups. In diesem Punkt ist Cloudron die stärkste der drei Optionen. Jede App-Subdomain erhält automatisch ein Let's Encrypt-Zertifikat, das für Sie erneuert wird. Backups werden geplant und sind integriert. Als Ziel können ein lokales Verzeichnis, S3 oder ein anderer Remote-Speicher dienen. Für jede Anwendung ist eine Wiederherstellung möglich. Außerdem können Sie eine Anwendung mit einem Klick auf eine neue Subdomain klonen.

Kosten und Lizenzierung – lesen Sie dies vor der Entscheidung. Cloudron ist ein kostenpflichtiges Produkt mit einem begrenzten kostenlosen Tarif: Der kostenlose Tarif erlaubt zwei Anwendungen. Wenn Sie eine dritte Anwendung installieren, erreichen Sie eine Bezahlschranke. Ein kostenpflichtiges Abonnement (Pro oder Max, monatlich oder jährlich abgerechnet; beide mit unbegrenzt vielen Anwendungen) schaltet weitere Funktionen frei. Das ist die wichtigste Tatsache zu Cloudron. Die Plattform ist gerade deshalb ausgereift, weil sie ein Geschäftsprodukt ist. Der kostenlose Tarif ist eher eine verlängerte Testversion als eine dauerhafte Umgebung für einen wachsenden Stack.

Fehlerfall, die Regel für saubere Systeme. Wenn Sie versuchen, Cloudron auf einem Server zu installieren, auf dem bereits etwas läuft, bricht die Einrichtung ab, 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.

Der Grund ist nicht bloße Umständlichkeit. Cloudron legt bestimmte Versionen von nginx, Docker und Node fest und integriert diese Komponenten tief. Deshalb kann es nicht neben eigenen Installationen dieser Komponenten betrieben werden. Verwenden Sie ein frisches Ubuntu 24.04-Image und installieren Sie nichts weiter: keinen Webserver, kein Docker und nicht einmal eine manuell konfigurierte Firewall. Wenn Sie das falsche Image gestartet haben, verweigert die Einrichtung außerdem jedes System, das kein unterstütztes Ubuntu LTS (22.04 oder 24.04) auf x86-64 ist. ARM, LXC und OpenVZ werden grundsätzlich nicht unterstützt.

Zweiter Fehlerfall, Wildcard-Zertifikate benötigen eine DNS-API. Wenn Sie während der Einrichtung die DNS-Option "Manual" auswählen, statt Cloudron ein API-Token zu geben, kann Cloudron keine DNS-Einträge und kein Wildcard-Zertifikat für Sie erstellen. Bei jeder neuen Anwendung müssen Sie dann zunächst manuell einen DNS-Eintrag hinzufügen, bevor das Zertifikat ausgestellt werden kann. Das Dashboard wartet bis dahin auf diesen Eintrag. Gewähren Sie Cloudron API-Zugriff auf einen unterstützten DNS-Provider (Cloudflare, Route 53, DigitalOcean und weitere), wird der gesamte Ablauf mit einem Klick erledigt.

CasaOS: das kostenlose Dashboard für das Home-Lab

Was es ist. CasaOS von IceWhale ist ein kostenloses Open-Source-Dashboard, das auf Docker aufsetzt und einen Startbildschirm, einen App Store und einen Dateimanager bereitstellt. Das Projekt stammt aus der Home-Server-Welt und ist daher auf Home-Labs ausgelegt: schnelle Einrichtung, benutzerfreundliche Oberfläche und wenig Verwaltungsaufwand. Es richtet sich an Anwender, die Docker eine angenehmere Oberfläche geben möchten, ohne dafür zu bezahlen.

Installation. Ein Befehl genügt. Eine leere Systeminstallation ist nicht erforderlich:

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

Das Installationsprogramm fügt mehrere systemd-Dienste hinzu (casaos, casaos-gateway, casaos-app-management und weitere). Prüfen Sie, ob das Gateway gestartet wurde, bevor Sie einen Browser öffnen:

systemctl status casaos-gateway

Nach dem Start ist das Dashboard unter http://<your-ip> erreichbar (unverschlüsseltes HTTP, Port 80). Erstellen Sie ein lokales Konto. Danach können Sie sich anmelden.

Die erste App hinzufügen. Öffnen Sie den App Store, wählen Sie eine App aus und klicken Sie auf Install. CasaOS erstellt im Hintergrund ein Docker-Compose-Projekt und stellt die App über einen Port des Hosts bereit, zum Beispiel http://<your-ip>:8080. Der Store enthält die üblichen Anwendungen für Home-Server. Daher sind beispielsweise ein Jellyfin-Medienserver auf einem VPS oder eine selbst gehostete Immich-Fotobibliothek mit wenigen Klicks eingerichtet. Wenn Sie sich noch nicht für einen Fotoserver entschieden haben, sollten Sie zuerst die Mindestanforderungen an RAM und die mobilen Apps, die PhotoPrism von Immich unterscheiden lesen. Auf einem CasaOS-System mit 1GB RAM entscheidet diese Wahl darüber, ob die App überhaupt läuft. Sie können außerdem beliebige docker-compose.yaml importieren. Darin liegt die eigentliche Stärke: Die Apps sind gewöhnliche Container und kein proprietäres Format.

TLS und Backups als Schwachstelle. Hier zeigen sich die Grenzen von "kostenlos". CasaOS stellt standardmäßig alles über unverschlüsseltes HTTP bereit, einschließlich des eigenen Dashboards. Eine integrierte Let's-Encrypt-Unterstützung gibt es nicht. Ebenso fehlt eine integrierte zeitgesteuerte Backup-Funktion. Ihre Daten liegen in Docker-Volumes unter /DATA. Für die Sicherung sind Sie selbst verantwortlich, etwa mit einem per cron ausgeführten restic oder tar.

Fehlerbild: kein TLS, aber keine sichtbare Fehlermeldung. Es tritt kein Fehler auf. Sie installieren eine App, öffnen http://<your-ip>:8080, und sie funktioniert über eine unverschlüsselte Verbindung, die der Browser als "Nicht sicher" kennzeichnet. Passwörter und Session-Cookies werden unverschlüsselt über das Netzwerk übertragen. Außerdem gab es in der Vergangenheit tatsächliche Remote-Code-Execution-Schwachstellen im CasaOS-Dashboard (CVE-2023-37265 und CVE-2023-37266, eine Umgehung der Authentifizierung, die anschließend eine vollständige Übernahme des Hosts ermöglichte). Deshalb ist es ein erhebliches Sicherheitsrisiko, diesen HTTP-Port direkt im Internet bereitzustellen. Es handelt sich nicht nur um eine Frage des Stils. Stellen Sie CasaOS niemals direkt im Internet bereit. Setzen Sie einen Reverse Proxy davor, der TLS terminiert, beispielsweise nginx mit einem Let's-Encrypt-Zertifikat von Certbot, Caddy oder einen Cloudflare Tunnel. Leiten Sie den Datenverkehr ausschließlich im lokalen Netzwerk an CasaOS weiter. Beachten Sie, dass CasaOS bereits Port 80 verwendet. Ihr Proxy und CasaOS würden sich diesen Port sonst streitig machen. Ändern Sie daher zuerst den Port von CasaOS.

Kosten. Die Software ist dauerhaft kostenlos, ohne Begrenzung der App-Anzahl. Dafür übernehmen Sie den betrieblichen Aufwand selbst: TLS, Backups und die Absicherung des Systems.

Coolify: die selbst gehostete PaaS

Was es ist. Coolify ist eine quelloffene, selbst gehostete Platform-as-a-Service-Lösung nach dem Vorbild von Heroku oder Vercel auf dem eigenen Server. Die grundlegende Einheit ist nicht „dieses paketierte Programm installieren“, sondern „dieses Git-Repository deployen“: Sie verbinden ein Repository, und Coolify erstellt daraus über Nixpacks oder Ihre eigene Dockerfile ein Deployment und veröffentlicht es. Bei jedem Push wird es erneut deployt. Außerdem bietet Coolify Datenbanken und Dienste zur Einrichtung mit einem Klick. Die Plattform richtet sich an Entwickler, die eigenen Code deployen und Push-to-Deploy nutzen möchten, ohne eine PaaS zu mieten.

Installation.

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

Das Skript installiert Docker und startet den eigenen Container-Stack von Coolify. Prüfen Sie den Zustand 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 jeweils Up melden. Das Dashboard ist unter http://<your-ip>:8000 erreichbar. Erstellen Sie sofort Ihr Administratorkonto, weil die Registrierungsseite bis zur Erstellung des ersten Kontos offen ist und jeder, der sie zuerst erreicht, den Server kontrollieren kann. Legen Sie anschließend die Domain Ihrer Instanz fest und zeigen Sie einen Wildcard-DNS-Eintrag (*.example.com oder *.apps.example.com) auf den Server. Dadurch kann Coolify jeder deployten Anwendung eine eigene Subdomain zuweisen.

Die erste Anwendung hinzufügen. Verbinden Sie eine Git-Quelle (GitHub, GitLab oder eine einfache Repository-URL), wählen Sie einen Branch aus, legen Sie die Domain fest und deployen Sie die Anwendung. Der integrierte Traefik-Proxy von Coolify leitet die Subdomain weiter und fordert das Zertifikat an. Für fertige Software können Sie über den Service-Katalog mit wenigen Klicks Dienste deployen: Der gleiche n8n-Stack zur Workflow-Automatisierung, den Sie sonst möglicherweise manuell einrichten würden, ist dort ein Eintrag. Das gilt auch für Uptime Kuma zur Überwachung von Statusseiten.

TLS und Backups. Über das integrierte Traefik werden automatisch Let's-Encrypt-Zertifikate für jede Anwendung ausgestellt. Dadurch erhält jede deployte Subdomain ein Zertifikat. Backups sind datenbankorientiert: Sie können Dumps von Postgres und MySQL für die Speicherung in einem S3-kompatiblen Speicher planen. Ein Backup der gesamten Instanz, einschließlich der Coolify-Konfiguration unter /data/coolify, ist manueller. Exportieren und speichern Sie diese Konfiguration daher selbst.

Kosten und Lizenzierung. Die selbst gehostete Edition ist vollständig quelloffen und kostenlos und begrenzt die Anzahl der Anwendungen nicht. Optional gibt es Coolify Cloud (kostenpflichtig). Dabei hostet Coolify die Steuerungsebene für Sie, während Ihre Anwendungen weiterhin auf Ihren eigenen Servern laufen. Das ist praktisch, aber nicht erforderlich.

Fehlerbild: Die Anwendung wird deployt, aber ihre Domain ist nicht erreichbar. Das Dashboard unter http://<ip>:8000 funktioniert, der Build ist erfolgreich, aber die eigene URL der Anwendung liefert einen Verbindungsfehler oder einen Traefik-404 page not found. Das deutet auf den Proxy oder DNS hin, nicht auf Ihre Anwendung. Zwei Ursachen treten häufig auf. Erstens waren Port 80 oder 443 bereits belegt, als der Proxy gestartet werden sollte. Deshalb wurde sein Container mit einem Docker-Fehler beendet:

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. Dadurch erhält Traefik keine Anfrage für diesen Hostnamen. Wenn stattdessen die gesamte Serverkarte in Coolify „Server is not reachable“ anzeigt, liegt ein anderer Fehler vor: Coolify kann überhaupt nicht mit dem Docker-Socket des Servers kommunizieren. Häufig sind ein gestoppter Docker-Daemon oder ein ungültiger SSH-Schlüssel die Ursache. Lesen Sie die tatsächliche Ursache in den Logs, bevor Sie eine Vermutung anstellen:

docker logs coolify-proxy --tail 100

Beheben Sie den Fehler über die Proxy-Seite: Klicken Sie auf Restart Proxy oder setzen Sie die Proxy-Konfiguration auf die Standardwerte zurück und starten Sie den Proxy erneut. Warten Sie anschließend etwa zwei Minuten, bis er stabil läuft. Lassen Sie Port 8000 nur für Ihre eigene IP-Adresse erreichbar (oder öffnen Sie ihn vorübergehend erneut, wenn der Proxy fehlerhaft arbeitet), statt ihn für das gesamte Internet freizugeben. Über diesen Port wird das Dashboard über unverschlüsseltes HTTP bereitgestellt. In der eigenen Dokumentation weist Coolify außerdem darauf hin, dass die Ports 8000, 6001 und 6002 geschlossen werden können, sobald das Dashboard über seine eigene Domain bereitgestellt wird.

Zusätzlicher Ressourcenbedarf auf derselben VPS

Auf derselben VPS mit 4GB wurde der Ressourcenbedarf im Leerlauf gemessen, bevor eine produktive Arbeitslast bereitgestellt wurde. Prüfen Sie den Bedarf mit free -m und docker stats --no-stream, statt einem einzelnen Wert zu vertrauen, da sich die Gesamtsumme abhängig von Ihrer Anwendungskombination verändert.

• CasaOS ist am sparsamsten. Das Panel besteht aus wenigen Go-Diensten. Rechnen Sie zusätzlich zu den von Ihnen ausgeführten Containern mit etwa 150 bis 300 MB.
• Coolify führt mehrere eigene Support-Container aus: die Anwendung, einen Postgres-, einen Redis-, einen Echtzeitdienst- und einen Traefik-Container. Im Leerlauf benötigt es daher etwa 600 MB bis 1 GB, bevor Sie etwas bereitstellen.
• Cloudron benötigt im Leerlauf am meisten Ressourcen, da es unabhängig von Ihrer Nutzung einen eigenen nginx-, Datenbank-, Mail- und Überwachungs-Stack ausführt. Planen Sie im Leerlauf 1 bis 1.5 GB ein. Deshalb fordert Cloudron mindestens 2GB und läuft mit 4GB deutlich entspannter.

Auf einer kleinen VPS mit 2GB lässt CasaOS am meisten Platz für produktive Anwendungen, während Cloudron am wenigsten Platz lässt. Wenn Ihr Tarif 2GB bietet und Sie Cloudron mit aktiviertem Mailserver betreiben möchten, sollten Sie ein Upgrade der VPS einplanen.

Updates, Backups und Bindung an die Plattform im Vergleich

Updates. Cloudron aktualisiert die Plattform und jede Anwendung nach einem getesteten Zeitplan für Sie. Das erfordert den geringsten Aufwand und bietet die umfassendste Unterstützung. Coolify aktualisieren Sie mit einem Klick über das eigene Dashboard. CasaOS aktualisiert das Panel über sein Installationsskript oder apt. Die von Ihnen installierten Anwendungen müssen Sie jedoch selbst abrufen und neu starten.

Bindung an die Plattform – der Teil, der im zweiten Jahr problematisch wird. CasaOS bindet Sie am wenigsten an die Plattform. Die Anwendungen sind gewöhnliche Compose-Projekte. Sie können daher docker-compose.yaml und die Volumes unter /DATA auf einen anderen Host kopieren und dort weiterarbeiten. Coolify liegt in der Mitte. Ihre Deployments basieren auf eigenen Dockerfiles und Repositories. Die Konfiguration wird jedoch in der Coolify-Datenbank gespeichert. Beim Wechsel des Hosts müssen Sie die Projekte auf dem anderen System neu erstellen. Cloudron bindet Sie am stärksten an die Plattform. Die Anwendungen sind als Cloudron-Pakete erstellt. Ihre Daten lassen sich dank der hervorragenden Backups problemlos übertragen. Die Paketierung wird jedoch nicht übertragen. Auf der Zielplattform müssen Sie die Anwendungen daher erneut deployen. Die Daten sind portabel, die zugrunde liegende Konfiguration nicht.

Welche Lösung sollten Sie wählen?

Kurzfassung, danach die Ausweichoption. Wählen Sie Cloudron, wenn Sie den geringsten Verwaltungsaufwand der drei Lösungen möchten, mehrere vorgefertigte Anwendungen betreiben und eine jährliche Gebühr für verwaltetes TLS, Backups und Updates bezahlen wollen. Wählen Sie CasaOS, wenn es sich um ein Home-Lab hinter Ihrem eigenen Netzwerk oder einem Reverse Proxy handelt, Sie eine benutzerfreundliche Oberfläche für Docker möchten und grundsätzlich nichts bezahlen wollen. Wählen Sie Coolify, wenn Sie eigenen Code aus Git bereitstellen möchten und Push-to-Deploy mit automatischem TLS benötigen, ohne den Preis einer gehosteten PaaS zu zahlen. Wenn keine dieser drei Lösungen auf Ihre Anforderungen passt, finden Sie im nächsten Abschnitt die ehrliche Antwort.

Überspringen Sie alle drei, wenn ...

Seien Sie ehrlich in Bezug auf Ihre Größenordnung. Wenn Sie nur eine oder zwei Anwendungen betreiben oder genau verstehen und kontrollieren möchten, was auf Ihrem Server läuft, überspringen Sie die Panels. Der zusätzliche Aufwand und die Bindung an einen Anbieter lohnen sich für einen kleinen, stabilen Stack nicht. Der DIY-Weg besteht aus einem Reverse Proxy vor Ihren eigenen Compose-Dateien: Traefik mit automatischem TLS vor mehreren Docker-Compose-Anwendungen bietet Ihnen HTTPS mit dem Komfort einer Ein-Klick-Einrichtung, ohne den Ballast eines Panels. Ihre Backups erstellen Sie mit einem per cron gestarteten restic-Job, dessen Funktionsweise 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

Bei einer einzelnen zentralen Anwendung ist der Fall noch eindeutiger: Eine Nextcloud-Installation mit Docker, TLS und eigener Backup-Routine besteht aus einer Compose-Datei und einem Zertifikat. Eine vollständige Appliance dafür bereitzustellen, würde nur Kosten verursachen und keinen Nutzen bringen. Wenn Sie noch entscheiden, was Sie betreiben möchten, bevor Sie festlegen, wie Sie es betreiben, ist der Leitfaden dazu, was sich 2026 für Self-Hosting lohnt der bessere Ausgangspunkt.

FAQ

Brauche ich überhaupt ein Self-Hosting-Panel?

Nur wenn Sie bei mehreren Anwendungen von den vier Funktionen profitieren, die ein Panel automatisiert: Installationen mit einem Klick, automatische TLS-Konfiguration, geplante Backups und Benutzerverwaltung. Für einen oder zwei Dienste erledigt plain Docker Compose hinter Traefik die TLS-Aufgabe mit deutlich weniger Overhead und ohne Vendor-Lock-in. Panels lohnen sich, wenn Sie viele Anwendungen betreiben und Ihre Zeit mehr wert ist als der Arbeitsspeicher, den sie benötigen.

Welches Panel ist für Einsteiger am besten geeignet?

Für ein Home-Lab, das nicht dem unsicheren Internet ausgesetzt ist, bietet CasaOS den einfachsten Einstieg: ein Befehl und eine übersichtliche Benutzeroberfläche, ohne laufende Kosten. Vor der Veröffentlichung muss jedoch ein Reverse Proxy mit TLS-Terminierung vorgeschaltet werden, da CasaOS unverschlüsseltes HTTP verwendet. Wenn Sie verwaltetes TLS und automatisch erstellte Backups wünschen und dafür bezahlen, bietet Cloudron innerhalb seines kostenlosen Limits von zwei Anwendungen die umfassendste Unterstützung.

Ist Cloudron kostenlos?

Teilweise. Der kostenlose Tarif erlaubt zwei Anwendungen. Das reicht zum Testen oder für eine sehr kleine Installation. Darüber hinaus ist Cloudron ein kostenpflichtiges Abonnement, das monatlich oder jährlich abgerechnet wird. Die kostenpflichtigen Tarife erlauben eine unbegrenzte Anzahl von Anwendungen. Cloudron ist ein kommerzielles Produkt mit einem begrenzten kostenlosen Tarif und keine freie Software. Planen Sie daher entsprechende Kosten ein, wenn Ihre Umgebung wachsen soll.

Kann ich diese Panels neben meinen vorhandenen Anwendungen betreiben?

Cloudron: nein. Es benötigt ein sauberes Ubuntu-System und bricht die Installation ab, wenn nginx, Docker oder Node bereits installiert sind, da es den gesamten Rechner verwaltet. CasaOS und Coolify sind flexibler, da sie ihren eigenen Docker-Stack installieren und grundsätzlich einen Rechner gemeinsam nutzen können. Beide benötigen jedoch die Ports 80 und 443 und kollidieren daher mit jedem Webserver oder Proxy, den Sie bereits betreiben. Auf einem Rechner, der bereits andere Dienste hostet, ist ein Panel normalerweise das falsche Werkzeug. Verwenden Sie stattdessen Traefik und Compose.

Wie kann ich später von einem Panel wechseln?

Planen Sie den Wechsel, bevor Sie ihn benötigen. Kopieren Sie bei CasaOS das docker-compose.yaml der Anwendung und ihre /DATA-Volumes auf den neuen Host und starten Sie die Anwendung dort erneut. Exportieren Sie bei Coolify die Konfiguration jedes Projekts und verweisen Sie es auf dem Zielsystem auf dieselben Repositories. Stellen Sie bei Cloudron die Daten aus den Backups in neu installierten Anwendungen auf der neuen Plattform wieder her, da sich die Cloudron-Paketierung nicht übertragen lässt, sondern nur die Daten. Testen Sie die Wiederherstellung in jedem Fall auf einem temporären Rechner, bevor Sie den alten Rechner außer Betrieb nehmen.