Das bekommen Sie
Drei kleine Bash-Skripte, ein gemeinsamer Alert-Helfer und die Konfigurationsdateien, die alles verbinden. Zehn Minuten Lesezeit genügen. Installieren müssen Sie nichts, nur die Tools, die die Skripte aufrufen.
| Datei | Aufgabe |
|---|---|
deploy.sh | Klont ein Release, baut es, prüft per Health Check und rollt bei Fehlern zurück. Zwei Modi: restart (Symlink plus pm2-Restart) und bluegreen (im Test unten ohne eine einzige fehlgeschlagene Anfrage). deploy.sh rollback schaltet im Blue/Green-Modus zurück. |
backup.sh | Erstellt konsistente Dumps von SQLite- und Postgres-Datenbanken und sichert sie mit restic (standardmäßig 7 tägliche, 4 wöchentliche und 6 monatliche Snapshots). Danach wird das Repository geprüft. Ein defekter Dump stoppt den Lauf, bevor ein Snapshot entsteht. |
restore-test.sh | Stellt den letzten Snapshot in einem temporären Verzeichnis wieder her, prüft die Datenbank-Dumps, führt Ihren eigenen optionalen Check aus und liest eine Stichprobe der Daten. |
notify.sh | Schickt eine Telegram-Nachricht oder einen Webhook-POST, sobald ein Skript fehlschlägt. Bei Erfolg bleibt es still. |
| Konfiguration | kit.env.example, Caddyfile.example, ecosystem.config.js, cron.example |
Deployments ohne Downtime, gemessen
Im Modus bluegreen startet das neue Release auf dem freien Port und wird direkt per Health Check geprüft. Dann schaltet Caddy per Graceful Reload darauf um, und erst danach wird das alte Release beendet. Ein Release, das nicht gesund ist, bekommt nie Traffic.
Testaufbau: Debian-12-Container, Caddy 2.6.2 aus apt, pm2 und eine Node-App, die 1.5 Sekunden zum Starten braucht. Während des gesamten Deployments liefen 20 Anfragen pro Sekunde durch Caddy, jede fünfte an einen Endpoint mit 300 ms Antwortzeit. Eine Anfrage zählt als fehlgeschlagen bei einem Verbindungsfehler, einem Timeout über 3 Sekunden oder jedem Status außer 200.
| Szenario | Anfragen | Fehlgeschlagen | Deploy-Dauer |
|---|---|---|---|
Modus restart, gutes Release | 116 | 32 (alle HTTP 502) | 2.4 s |
Modus restart, kaputtes Release (zurückgerollt) | 380 | 67 (alle HTTP 502) | 16.8 s |
bluegreen, gutes Release | 211 | 0 | 7.6 s |
bluegreen, kaputtes Release (Health Check liefert 500) | 373 | 0 | 16.6 s |
bluegreen, Release stürzt beim Start ab | 371 | 0 | 16.5 s |
bluegreen, rollback | 208 | 0 | 7.5 s |
Im Blue/Green-Lauf mit gutem Release sah die Last beide Versionen (115 Antworten von v1, danach 96 von v2). Der Traffic ist also tatsächlich umgezogen. Über mehrere Läufe hinweg verlor der Modus restart jeweils 31 bis 35 Anfragen, Blue/Green keine.
Backups, die Sie wirklich zurückgespielt haben
- Datenbanken werden korrekt gedumpt. SQLite nutzt die Online-Backup-Funktion samt Integritätsprüfung, Postgres
pg_dump -Fcundpg_restore -l. Wer eine laufende Datenbankdatei einfach kopiert, endet oft mit einem defekten Backup. - Ein defekter Dump stoppt den Lauf. Im Test brach eine beschädigte SQLite-Datei das Backup ab, ohne dass ein Snapshot entstand.
- Alte Dumps schleichen sich nicht ein. Eine Datenbank, die Sie aus der Konfiguration entfernt haben, landet nicht weiter in neuen Snapshots.
restore-test.shliefert den Beweis. Das Skript stellt wieder her, prüft die Dumps und führtrestic checkauf einer Stichprobe aus. Lassen Sie es wöchentlich per Cron laufen.- Entferntes Repository.
sftp:-Repositories funktionieren mit beiden Skripten (getestet gegen einen lokalen OpenSSH-Server).
Alarm bei Fehlern
Setzen Sie TELEGRAM_BOT_TOKEN und TELEGRAM_CHAT_ID oder NOTIFY_WEBHOOK_URL. Ein fehlgeschlagenes Deployment, Backup oder ein fehlgeschlagener Restore-Test löst pro Kanal genau eine Nachricht aus, ein erfolgreicher Lauf keine. Das Token geht per stdin an curl und wird nie ausgegeben. Ist die Benachrichtigungs-API nicht erreichbar, bleibt der Exit-Code des Skripts unverändert.
Einrichtung in fünf Schritten
- Installieren Sie
restic,git,curlundpm2(dazucaddyfür Blue/Green sowiesqlite3oderpostgresql-client, je nach Datenbank). - Kopieren Sie den Ordner auf den Server, führen Sie
cp kit.env.example kit.envaus und passen Sie die Datei an. - Legen Sie das Repository-Passwort in einer Datei mit Modus 600 ab.
- Starten Sie nacheinander
./backup.sh,./restore-test.shund./deploy.sh. - Tragen Sie die Cron-Zeilen aus
cron.exampleein.
So wurde getestet
59 Checks laufen in einem sauberen Debian-12-Container (Node 22, restic, PostgreSQL 15, Caddy 2.6.2 und OpenSSH aus apt, pm2). Sie decken ab: Backup von Ordnern, SQLite und Postgres, Restore mit Zeilenvergleich, falsches Repository, beschädigte Datenbank, fehlenden Dump, Deployment und Rollback in beiden Modi unter Last, Alarme gegen eine lokale Fake-API sowie restic über SFTP.
Für wen es ist
Für Solo-Entwickler und kleine Teams, die eine oder zwei Node- oder Go-Apps auf einem einzelnen Linux-VPS betreiben und Deployments und Backups wollen, auf die sie sich verlassen können, ohne auf Kubernetes umzusteigen.
Voraussetzungen
Linux, bash, pm2, restic und für Blue/Green Caddy. Ihre App liest ihren Port aus PORT. Blue/Green lässt zwei Releases einige Sekunden lang parallel laufen, daher müssen Datenbank-Migrationen abwärtskompatibel sein.
Häufige Fragen
Brauche ich das Kit, um Deployments ohne Downtime zu bekommen?
Nein. Die Technik steht mit den wichtigsten Befehlen in diesem Beitrag. Das Kit packt sie zusammen mit Health Checks, Rollback, Zustandsverwaltung, Alarmen und der Testsuite in ein fertiges Paket.
Von welchem Stack geht es aus?
Linux, bash, pm2, Caddy für Blue/Green, restic für Backups und eine App, die ihren Port aus der Umgebungsvariable PORT liest.
Funktioniert es mit Postgres und SQLite?
Ja, beide werden gedumpt und geprüft.
Kann ich es für mehrere Apps nutzen?
Pro App eine kit.env. Mit KIT_CONF wählen Sie die Datei aus.
Wie ist die Lizenz?
Sie dürfen es auf Ihren eigenen Servern einsetzen. Die Dateien weiterzuverkaufen ist nicht erlaubt.
Änderungsprotokoll
- 0.3.0: Blue/Green-Deployments mit Rollback, Alarme bei Fehlern (Telegram und Webhook), SFTP-Repositories getestet, alle Meldungen auf Englisch.
- 0.2.0: SQLite- und Postgres-Dumps in
backup.sh, Dump-Prüfung inrestore-test.sh. - 0.1.0: erstes Release.
Weiterlesen
- Zero-downtime deploys on one VPS with Caddy and pm2 (Englisch)
- restic forget and prune: how the keep flags decide (Englisch)
- A restic backup recipe for SQLite and Postgres on one VPS (Englisch)
- Monitoring backups so that silence never means success (Englisch)
- The 3-2-1 backup rule applied to a single VPS (Englisch)
Herunterladen
Zahlung, Steuern und Rechnung übernimmt Polar als Merchant of Record. Den Download-Link erhalten Sie nach dem Checkout.