Ich habe Coolify wegen der schnellen Einrichtung genommen. Elf Projekte später wechsle ich zu Kubernetes.

Ich habe meine privaten Projekte auf Coolify gelegt, weil es schneller stand als alles andere, das ich mir angesehen hatte, und weil ich wissen wollte, wie sich eine selbstgehostete PaaS anfühlt, nachdem ich jahrelang Terraform für andere geschrieben habe. Beides waren gute Gründe. Beides hat es eingelöst.

Inzwischen laufen dort elf Projekte. Mehrere PostgreSQL-Instanzen, Redis, Prometheus, Grafana. Irgendwann dazwischen hörte es auf, ein Experiment zu sein, und wurde das, worauf meine Arbeit steht. Den Übergang habe ich nicht bemerkt.

Bemerkt habe ich, als sich die Frage änderte. Lange lautete sie wie deploye ich das, und darauf antwortet Coolify gut. Jetzt lautet sie wie ziehe ich das um, und das ist eine andere Art von Frage.

Was ein Umzug tatsächlich verlangt

Coolifys eigene Dokumentation ist beim ersten Teil eindeutig: Es gibt keinen eingebauten Weg, Anwendungen von einem Server auf einen anderen zu migrieren. Das ist keine Lücke in der Doku. Die Funktion existiert nicht.

Eine Instanz umzuziehen heißt, vier Dinge von Hand mitzunehmen:

• Den coolify-db-Container, in dem die Konfiguration sämtlicher Projekte liegt.
• Den APP_KEY aus der .env, weil diese Datenbank damit verschlüsselt und ohne ihn wertlos ist.
• Die SSH-Keys, mit denen Coolify deine Server erreicht.
• Die authorized_keys, mit denen diese Server ihn akzeptieren.

Volumes sind eine eigene Übung: jedes in einen temporären Container mounten, den Inhalt tarballen, das Archiv herauskopieren, den Container löschen. Danach auf der Gegenseite das Dashboard öffnen und jede Anwendung neu deployen, damit die Container gegen die zurückgespielten Volumes hochkommen.

Nichts davon ist unangemessen für ein Werkzeug dieser Art. Es sagt dir aber, wo die Wahrheit über deine Infrastruktur liegt, und in diesem Fall ist die Wahrheit ein verschlüsselter Postgres-Container plus ein Geheimnis in einer Punktdatei.

Was mir wirklich fehlt

Nicht die Migration.

Das Review.

Ich kann meine Infrastruktur nicht diffen. Es gibt keine Datei, in der elf Projekte beschrieben sind, also gibt es nichts, wogegen man einen Pull Request öffnen könnte, nichts, das man in einem Jahr liest, um herauszufinden, warum ein Container die Umgebungsvariable hat, die er hat, nichts, das man auf einen frischen Host abspielt, um zu sehen, ob es identisch zurückkommt. Die Konfiguration ist echt und sie ist korrekt, und einsehbar ist sie nur, indem man sich Projekt für Projekt durch eine Oberfläche klickt.

Das ist derselbe Defekt in anderem Kostüm. Ein Terraform-State-File für alles ist gefährlich, weil es den Radius jeder Änderung auf den gesamten Bestand ausdehnt. Eine PaaS-Datenbank für alles ist aus dem gespiegelten Grund gefährlich: Es gibt gar keinen Radius, weil es überhaupt keine Änderung zu reviewen gibt.

An Berechtigungen wird es konkret. In Kubernetes ist eine Datei, wer was darf. Eine Role, ein RoleBinding, ein securityContext, eine NetworkPolicy. Man kann sie lesen, diffen, im Review ablehnen und im Incident darauf zeigen. In Coolify sind Berechtigungen das, was die Oberfläche anbietet, ausgedrückt als Zustand einiger Checkboxen, und der einzige Weg, sie zu prüfen, ist hinzugehen und nachzusehen.

Was ArgoCD ändert, und was nicht

Der Grund, warum ich zu Kubernetes mit ArgoCD tendiere, ist nicht, dass Kubernetes Container besser ausführt. Für elf Projekte ist es offensichtlich schlechter: mehr bewegliche Teile, mehr zu patchen, mehr Wege, an einem Sonntag angepiept zu werden.

Es ist, dass GitOps umdreht, wo die Wahrheit liegt. Bei derselben Frage bin ich gelandet, als ich aufgeschrieben habe, was deine Infrastruktur wirklich ausführt, wenn du SST benutzt: Die Schicht, die den Sollzustand hält, ist die Schicht, die du reviewen kannst. Der Sollzustand des Clusters ist ein Repository. Migration hört auf, eine Tarball-Prozedur zu sein, und wird dazu, ein neues Cluster auf dasselbe Repo zu zeigen. Erweitern hört auf, eine Klickfolge zu sein, die sich jemand merken muss, und wird zu einem Diff, den jemand freigeben kann. Rollback ist git revert.

Ich will bei den Kosten ehrlich sein, weil die Fassung dieses Arguments, die man sonst liest, es nicht ist. Du tauschst einen Nachmittag Einrichtung gegen ein System mit echter Lernkurve, und du übernimmst den Betriebsaufwand der Control Plane selbst. Wenn du nur elf Container brauchst, die laufen, ist der Tausch schlecht und Coolify gewinnt auf jeder Achse, die zählt.

Der Tausch lohnt erst, wenn deine Fragen von Änderung handeln statt von Verfügbarkeit. Meine tun das seit einer Weile, und ich war langsam darin, es zu merken.

Wo die Grenze verläuft

Meine ehrliche Einschätzung, nachdem ich auf beiden Seiten stand:

Coolify ist richtig, solange das, was du betreibst, klein genug ist, um es im Kopf zu behalten, und solange du der Einzige bist, der es verstehen muss. Das ist keine Einschränkung, das ist die meiste private Infrastruktur, und eine Oberfläche ist dafür eine wirklich gute Schnittstelle. Das Tempo, das ich am Anfang gekauft habe, war echt, und ich würde es wieder kaufen.

Richtig ist es nicht mehr ab dem Punkt, an dem jemand anderes rekonstruieren können muss, was du gebaut hast. Dieser jemand anderes bist meistens du selbst, achtzehn Monate später, ohne jede Erinnerung an die Checkboxen.

Umgezogen bin ich noch nicht. Ich schreibe das auch, um zu prüfen, ob die Gründe standhalten, wenn ich sie ordne. Bisher tun sie es.

Next

Die Kurzfassung:

• Coolify hat keine eingebaute Anwendungsmigration. Ein Instanzumzug heißt: Datenbank-Container, der APP_KEY zum Entschlüsseln, beide Sätze SSH-Keys und jedes Volume von Hand.
• Der eigentliche Preis ist nicht die Migration, sondern dass es keine Datei zum Diffen, Reviewen und Abspielen gibt.
• Berechtigungen sind in Kubernetes eine Datei, die man im Review ablehnen kann. In einer PaaS sind sie der Zustand eines Formulars.
• ArgoCD lohnt seinen Aufwand erst, wenn deine Fragen von Änderung handeln statt von Verfügbarkeit. Für elf Container, die einfach laufen sollen, ist es der falsche Tausch.

Als Nächstes will ich klären, was die Migration tatsächlich an Stunden kostet, gemessen statt geschätzt. Diese Zahl ist das ganze Argument, und ich habe sie noch nicht. Sobald ich sie habe, steht sie hier. Falls du diesen Wechsel mit vergleichbarem Bestand hinter dir hast, würde mich interessieren, was er dich gekostet hat. Jede Schätzung, die ich finde, stammt von jemandem, der eine der beiden Seiten verkauft.