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 Lösungen 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 dagegen nicht. Auf einem KVM-Tarif gibt der Befehl kvm aus, auf Bare Metal none. In beiden Fällen können Sie fortfahren.

Darüber hinaus unterscheiden sich die Anforderungen. Das ist der wichtigste Punkt für die 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 spürbar besser, 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-Provider verfügen, damit es DNS-Einträge und Wildcard-Zertifikate selbst erstellen kann. CasaOS läuft auch über eine reine IP-Adresse, dann steht Ihnen jedoch kein TLS zur Verfügung.
• Ports. Cloudron und Coolify benötigen offene Ports 80 und 443 für HTTP und HTTPS. CasaOS stellt sein Dashboard über unverschlüsseltes HTTP bereit und benötigt daher nur Port 80. 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 Lösungen Port 22 für SSH offen.

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

Cloudron: die ausgereifte Plattform mit festen Vorgaben

Was es ist. Cloudron ist eine kommerzielle Plattform, die einen ganzen Server in eine verwaltete Appliance umwandelt. Sie betreibt einen eigenen Reverse Proxy, eine Datenbank und einen Mail-Stack sowie einen kuratierten App Store mit paketierten Anwendungen (Nextcloud, WordPress, Gitea, Mattermost und weitere). Cloudron richtet sich an Nutzer, die ihre Anwendungen verwalten lassen möchten – mit automatischen Updates, automatischen Zertifikaten und automatischen Backups – und bereit sind, dafür zu bezahlen.

Installation. Cloudron setzt ein sauberes System voraus und übernimmt es vollständig. Führen Sie den folgenden Befehl auf einem frischen Ubuntu-24.04-Server (Noble) aus. Auf dem Server 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: Verknüpfen Sie Cloudron mit Ihrer 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 – ohne dass Sie eine Konfigurationsdatei bearbeiten müssen. Das ist das zentrale Versprechen, und Cloudron erfüllt es.

TLS und Backups. In diesem Punkt ist Cloudron von den drei Lösungen am stärksten. Jede App-Subdomain erhält automatisch ein Let's-Encrypt-Zertifikat, das Cloudron für Sie erneuert. Backups werden geplant und sind integriert. Als Ziel können ein lokales Verzeichnis, S3 oder ein anderer entfernter Speicher dienen. Für jede Anwendung ist eine Wiederherstellung möglich. Außerdem lässt sich eine Anwendung mit einem Klick unter einer neuen 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, greift 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äftsmodell hat. Der kostenlose Tarif ist eher eine verlängerte Testphase als eine dauerhafte Basis für einen wachsenden Stack.

Fehlerfall: die Regel für ein sauberes System. Wenn Sie Cloudron auf einem Server installieren, auf dem bereits andere Dienste laufen, bricht die Einrichtung ab, bevor sie Änderungen vornimmt:

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

Der Grund ist nicht unnötige Strenge. Cloudron bindet bestimmte Versionen von nginx, Docker und Node fest ein und integriert diese Komponenten tief in die Plattform. Deshalb kann Cloudron nicht neben Ihren eigenen Installationen dieser Komponenten betrieben werden. Verwenden Sie ein frisches Ubuntu-24.04-Image und installieren Sie nichts weiter: keinen Webserver, kein Docker und auch keine 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, 24.04 oder 26.04) auf x86-64 ist. ARM, LXC und OpenVZ werden grundsätzlich nicht unterstützt. Seit Cloudron 10 (September 2026) ist Ubuntu 26.04 der Standard für neue Installationen. Wenn Sie heute neu beginnen, sollten Sie daher dieses Image auswählen.

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 übergeben, kann Cloudron keine DNS-Einträge und kein Wildcard-Zertifikat für Sie erstellen. Für jede neue Anwendung müssen Sie dann zunächst manuell einen DNS-Eintrag anlegen, 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 zu einem einzigen Klick.

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 Open-Source-Plattform-as-a-Service für das Self-Hosting, vergleichbar mit Heroku oder Vercel auf Ihrem eigenen Server. Die zentrale Einheit ist nicht „diese paketierte Anwendung installieren“, sondern „dieses Git-Repository bereitstellen“: Sie verbinden ein Repository, und Coolify erstellt daraus über Nixpacks oder Ihre eigene Dockerfile eine Anwendung und stellt sie bereit. Bei jedem Push wird sie erneut bereitgestellt. Außerdem stehen Datenbanken und Dienste für die Bereitstellung mit einem Klick zur Verfügung. Coolify richtet sich an Entwickler, die ihren eigenen Code bereitstellen 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}}'

Bei coolify, coolify-db, coolify-redis, coolify-realtime und coolify-proxy sollte jeweils Up angezeigt werden. Das Dashboard ist unter http://<your-ip>:8000 erreichbar. Erstellen Sie sofort Ihr Administratorkonto, weil die Registrierungsseite bis zur Erstellung des ersten Kontos offen bleibt und die zuerst zugreifende Person den Server kontrolliert. Legen Sie anschließend die Domain Ihrer Instanz fest und richten Sie einen Wildcard-DNS-Eintrag (*.example.com oder *.apps.example.com) auf den Server ein. Dadurch kann Coolify jeder bereitgestellten Anwendung eine eigene Subdomain zuweisen.

Eine 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 starten Sie die Bereitstellung. Der integrierte Traefik-Proxy von Coolify leitet Anfragen für die Subdomain weiter und fordert das Zertifikat an. Für fertige Software stellt der Services-Katalog Anwendungen mit wenigen Klicks bereit: Derselbe 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 einer Statusseite.

TLS und Backups. Über den integrierten Traefik werden automatisch Let's-Encrypt-Zertifikate für jede Anwendung ausgestellt. Dadurch erhält jede bereitgestellte Subdomain ein Zertifikat. Backups sind datenbankorientiert: Sie können Dumps von Postgres und MySQL für die Speicherung in S3-kompatiblem Speicher planen. Ein vollständiges Backup der Instanz ist manueller. Die Coolify-Konfiguration selbst liegt unter /data/coolify. Exportieren und speichern Sie sie daher selbst.

Kosten und Lizenzierung. Die selbst gehostete Edition ist vollständig Open Source und kostenlos. Die Anzahl der Anwendungen ist nicht begrenzt. 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 bereitgestellt, ihre Domain ist jedoch nicht erreichbar. Das Dashboard funktioniert unter http://<ip>:8000, der Build ist erfolgreich, aber die URL der Anwendung liefert einen Verbindungsfehler oder einen Traefik-404 page not found. Das weist auf den Proxy oder DNS hin, nicht auf die Anwendung. Zwei Ursachen treten häufig auf. Erstens waren Port 80 oder 443 bereits belegt, als der Proxy gestartet werden sollte. Der Container wurde deshalb 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 wird der Hostname nicht zum Server aufgelöst. Entweder verwendet die Anwendung eine über einen Wildcard-Eintrag erzeugte Subdomain, für die der Wildcard-DNS-Eintrag fehlt, oder sie verwendet eine benutzerdefinierte Domain ohne eigenen DNS-Eintrag zum Server. In diesem Fall erhält Traefik keine Anfrage für diesen Hostnamen. Wenn stattdessen die gesamte Serverkarte in Coolify „Server ist nicht erreichbar“ anzeigt, liegt ein anderer Fehler vor: Coolify kann überhaupt keine Verbindung zum Docker-Socket des Servers herstellen. Meist läuft der Docker-Daemon nicht oder ein SSH-Schlüssel ist beschädigt. Lesen Sie den tatsächlichen Grund in den Logs, bevor Sie eine Ursache vermuten:

docker logs coolify-proxy --tail 100

Beheben Sie den Fehler auf der Proxy-Seite. Klicken Sie auf Proxy neu starten 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 sich der Zustand stabilisiert. Lassen Sie Port 8000 nur für Ihre eigene IP-Adresse erreichbar. Öffnen Sie ihn nur vorübergehend erneut, wenn der Proxy Probleme verursacht. Lassen Sie ihn nicht weltweit offen, weil darüber das Dashboard unverschlüsselt über HTTP bereitgestellt wird. Laut der Coolify-Dokumentation können die Ports 8000, 6001 und 6002 geschlossen werden, 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 Lock-in im Vergleich

Updates. Cloudron aktualisiert die Plattform und jede App nach einem von Cloudron getesteten Zeitplan für Sie: Das bedeutet den geringsten Aufwand und die meiste Unterstützung. Coolify aktualisiert sich selbst über das eigene Dashboard mit einem Klick. CasaOS aktualisiert das Panel über das Installationsskript oder apt, aber die von Ihnen installierten Apps müssen Sie selbst per Pull aktualisieren und neu starten.

Lock-in, der Aspekt, der im zweiten Jahr schmerzt. CasaOS bietet den geringsten Lock-in: Die Apps sind gewöhnliche Compose-Projekte. Sie können die docker-compose.yaml und die Volumes unter /DATA auf jeden anderen Host kopieren und dort weiterarbeiten. Coolify liegt im Mittelfeld: Ihre Deployments basieren auf Ihren eigenen Dockerfiles und Repositories, aber deren Konfiguration liegt in der Datenbank von Coolify. Ein Umzug auf einen anderen Host erfordert daher das Neuerstellen der Projekte auf der Zielseite. Cloudron weist den stärksten Lock-in auf: Apps sind Cloudron-spezifisch paketiert. Während Ihre Daten über die exzellenten Backup-Funktionen sauber exportiert werden können, gilt dies nicht für die Paketierung. Sie müssen die Apps auf der Zielplattform also neu bereitstellen. Portierbare Daten, nicht portierbare Infrastruktur.

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 einfaches Docker Compose hinter Traefik dieselbe TLS-Aufgabe mit deutlich weniger Overhead und ohne Bindung an einen Anbieter. Panels lohnen sich, wenn Sie viele Anwendungen betreiben und Ihre Zeit mehr wert ist als der dafür benötigte Arbeitsspeicher.

Welches Panel ist für Einsteiger am besten geeignet?

Für ein Homelab, in dem nichts dem ungeschützten Internet ausgesetzt ist, bietet CasaOS den einfachsten Einstieg: ein Befehl und eine übersichtliche Oberfläche, ohne laufende Kosten. Vor der Veröffentlichung müssen Sie jedoch einen Reverse Proxy mit TLS-Terminierung davorschalten, weil CasaOS reines HTTP verwendet. Wenn Sie eine verwaltete TLS-Konfiguration und automatische Backups möchten und dafür bezahlen, bietet Cloudron innerhalb des kostenlosen Limits von zwei Anwendungen die umfassendste Unterstützung.

Ist Cloudron kostenlos?

Teilweise. Der kostenlose Tarif erlaubt zwei Anwendungen. Das reicht zum Ausprobieren oder für eine sehr kleine Installation. Darüber hinaus ist Cloudron ein kostenpflichtiges Abonnement mit monatlicher oder jährlicher Abrechnung. Die kostenpflichtigen Tarife erlauben eine unbegrenzte Anzahl von Anwendungen. Cloudron ist ein kommerzielles Produkt mit einem begrenzten kostenlosen Tarif und keine freie Software. Berücksichtigen Sie die Kosten, 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, weil es den gesamten Rechner verwaltet. CasaOS und Coolify sind flexibler, da sie ihren eigenen Docker-Stack installieren und sich grundsätzlich einen Rechner mit anderen Diensten teilen können. CasaOS benötigt jedoch Port 80 für sein Dashboard, und der Proxy von Coolify benötigt sowohl Port 80 als auch Port 443. Daher kollidieren beide mit jedem Webserver oder Proxy, der diese Ports bereits verwendet. Auf einem Rechner, der bereits Dienste hostet, ist ein Panel normalerweise das falsche Werkzeug. Verwenden Sie stattdessen Traefik und Compose.

Wie kann ich später von einem Panel wegwechseln?

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 am Ziel auf dieselben Repositories. Stellen Sie bei Cloudron die Daten aus den Backups in neu installierten Anwendungen auf der neuen Plattform wieder her. Die Cloudron-Pakete lassen sich nicht übertragen, sondern nur die Daten. Testen Sie die Wiederherstellung in jedem Fall auf einem Wegwerf-System, bevor Sie das alte System außer Betrieb nehmen.