Deploy von GitHub auf deinen eigenen Server

1. 1Build. Der Code wird in einem temporären Container gebaut. Ein Repository mit Dockerfile wird damit gebaut. Ohne eines findet Railpack den Build für Node, Python, Go, statische Websites und mehr heraus, und Zelie zeigt die Build- und Startbefehle, die es gewählt hat.
2. 2Test. Die Tests des Projekts laufen im neuen Image, in einem eigenen Container, höchstens zehn Minuten lang. Bei Node-Projekten findet Zelie das Testskript selbst; jeder andere Befehl lässt sich festlegen. Ein fehlschlagender Test behält die alte Version.
3. 3Health-Check. Die neue Version startet neben der alten. Eine App mit Domain muss innerhalb einer Minute auf ihrem Health-Pfad antworten.
4. 4Live. Der Traffic zieht um. Der Commit auf GitHub wird als „building“, „live“ oder „failed“ markiert.

Scheitert ein Schritt, bedient die alte Version weiter, und das Log zeigt, warum. Die Images der letzten fünf Live-Versionen bleiben erhalten, deshalb dauert ein Rollback ein, zwei Sekunden.

Beim Verbinden mit GitHub entsteht eine GitHub App in deinem eigenen Konto oder deiner Organisation, mit Zugriff nur auf die Repositories, die du auswählst. Private Repositories funktionieren. Die App darf Code lesen und Commit-Status setzen, sonst nichts, und ihr privater Schlüssel wird verschlüsselt, bevor er gespeichert wird.

• Jeder Push auf den Branch der App deployt sie, wenn du das eingeschaltet lässt.
• Ein Push deployt nur die Apps, die auf dieses Repository und diesen Branch eingestellt sind, so bedient eine GitHub App viele Apps, ohne dass sie sich in die Quere kommen.
• Jeder Webhook wird vor allem anderen gegen sein Secret geprüft, und eine Zustellung, die zweimal ankommt, wird einmal verarbeitet.
• Öffentliche Repositories lassen sich ohne die App deployen, wenn du das Deployment selbst startest.

Ein Container-Image

Jedes öffentliche Image, etwa nginx:1.27, mit eigener Domain und eigenem HTTPS. Zelie prüft die Registry einmal am Tag und bietet das neue Image an, wenn sich der Tag bewegt hat.

Deine eigenen Dateien

Wähle Node.js, Python, Bun, Deno oder Java und lade die Dateien hoch oder schick sie per SFTP. Das passt für einen Discord-Bot oder eine kleine Website. Einen Build-Schritt gibt es hier nicht: Die Dateien sind die App.

Eine Domain und HTTPS

Mit einer Domain installiert, holt Zelie Zertifikate von Let’s Encrypt. Hinter einem Cloudflare Tunnel übernimmt Cloudflare HTTPS, und auf dem Server ist kein Port offen.

Variablen und Secrets

Normale und geheime, oder eine ganze .env-Datei zum Einfügen. Ein Secret wird beim Speichern versiegelt, und Builds bekommen Variablen als BuildKit-Secrets, die nicht im Image landen.

Datenbanken daneben

PostgreSQL, MariaDB oder Redis mit einem Klick. Wer eine verknüpft, gibt der App DATABASE_URL oder REDIS_URL, und sonst kann nichts sie erreichen.

Live-Logs und Metriken

Build-, Deploy- und App-Logs, während sie entstehen. Anfragen, Serverfehler, Speicher, CPU und Traffic, ein Messwert pro Minute, einen Tag lang aufbewahrt.

Abstürze abgefangen

Eine App, die von selbst stoppt, kommt wieder und wartet nach jedem Absturz länger. Nach fünf Abstürzen in zehn Minuten bleibt sie unten, und das Panel sagt, warum.

Ein eigener Container

Eigenes Netzwerk und eigener User-Namespace, mit Limits für Speicher und CPU. Root im Container ist auf dem Server niemand.

Zelie ist ein Binary, ein Download von etwa 50 MB, mit eigenem containerd und seinem Zustand in SQLite. Seine eigenen Prozesse bleiben im Leerlauf unter 66 MB Speicher, also hat ein kleiner VPS Platz für die Apps. Es läuft auf Debian oder Ubuntu, amd64 oder arm64, und dasselbe Panel kann Gameserver neben deinen Apps betreiben. Wie es sich von Coolify unterscheidet, steht im Vergleich.

Deploy bei jedem Push setzt voraus, dass GitHub das Panel erreicht, was mit einer Domain oder einem Cloudflare Tunnel geht. Jede App ist ein Image, ein Dockerfile oder ein Ordner mit Dateien; Docker-Compose-Dateien werden nicht gelesen.