Von nginx, Apache oder Traefik zu Caddy migrieren

Server Manager setzt klar auf Caddy — jedes Rezept und jeder Assistent schreibt Caddyfile-Blöcke, keine nginx-server { }-Blöcke, keine Apache-<VirtualHost>-Blöcke und keine Traefik-Docker-Labels. Wenn auf deinem Server aktuell eine dieser Engines läuft, wechseln Rezepte, die die Proxy-Konfiguration ändern müssen, auf den 💬 per Chat-Pfad — sie funktionieren weiterhin, aber du bestätigst pro Aktion einmal zusätzlich. Das Rezept Zu Caddy migrieren bringt dich in etwa 10 Minuten von diesem Zustand zu einem vollständig verwalteten Caddy-Server. Dabei gibt es einen Probelauf, mit dem Faro prüfen kann, ob jede Website korrekt übersetzt wurde, bevor wirklich umgeschaltet wird.

Das Rezept unterstützt drei Quell-Engines: nginx, Apache (sowohl apache2 auf Debian/Ubuntu als auch httpd auf RHEL/Fedora) und Traefik (Docker-Labels-Provider). Der Ablauf der Migration ist bei allen drei gleich — nur die Details auf der Quellseite unterscheiden sich.

1. Server-Info → Webserver öffnen

Klicke in der oberen Leiste auf deinen Servernamen, um das Server-Info-Panel zu öffnen, und klicke dann auf den Tab **Webserver**.

Der Tab zeigt:

• Engine — was aktuell auf den Ports 80 / 443 läuft (nginx / Apache / Traefik / Caddy / nichts).
• Erkannte Vhosts — wie viele Websites die Engine ausliefert (bei Traefik werden stattdessen „Router“ angezeigt).
• TLS-Zertifikate — wer deine HTTPS-Zertifikate verwaltet (typischerweise certbot für nginx/Apache, Traefiks integriertes ACME für Traefik).
• Verwaltbarkeit — eine Prüfung, ob die Konfiguration übersetzbar ist: Ein grünes ✓ bedeutet, dass jede Website nur Direktiven nutzt, die das Rezept umwandeln kann; ein rotes ✗ zeigt dir, welche Direktive im Weg ist (mod_lua, proxy_cache_path, komplexe RewriteRule-Ketten, Traefik-Middlewares usw.). Wenn du ein rotes ✗ siehst, verweigert das Rezept den Start, bis du die nicht unterstützte Direktive entfernst — das ist Absicht, denn das Rezept lässt niemals stillschweigend Verhalten weg.

2. Auf Zu Caddy migrieren klicken

Klicke auf den Button Diesen Server zu Caddy migrieren →. Server Manager öffnet das Chat-Panel und Faro übernimmt ab dort.

Das Rezept läuft in 5 Phasen. Phase 0 ist schreibgeschützt (nur ein Prüfdurchlauf). Die Phasen 1–4 pausieren jeweils für deine Bestätigung, bevor ein destruktiver Befehl ausgeführt wird. Du kannst jederzeit abbrechen — bis zur atomaren Umschaltung in Phase 4 gehören die Live-Ports weiterhin deiner bestehenden Engine, und deine Websites liefern unverändert Traffic aus.

3. Jede Phase bestätigen

Faro erklärt vor jeder Bestätigung, was als Nächstes passiert. Die Pakete sind kurz und klar abgegrenzt.

• Phase 0 — Vorabprüfung. Schreibgeschützt: listet deine bestehenden Vhosts auf, prüft auf nicht unterstützte Direktiven und ermittelt die Admin-E-Mail für Let's Encrypt. Endet mit einem Plan in verständlicher Sprache + einem Reply: go-Button. Klicke darauf (oder tippe go), um zu starten.
• Phase 1 — Caddy installieren. Fügt das offizielle Caddy-Repository hinzu, installiert das Paket und stoppt den Dienst sofort wieder. Deine bestehende Engine besitzt weiterhin die Ports.
• Phase 2 — Übersetzen. Schreibt ein vorgeschlagenes Caddyfile nach /tmp und validiert es. Live ändert sich noch nichts.
• Phase 3 — Probelauf. Startet Caddy auf alternativen Ports :8080 / :8443, damit getestet werden kann, ohne echten Traffic anzufassen. Faro führt dann selbst Loopback-curl-Tests aus (HTTPS, HTTP→HTTPS-Weiterleitung, ACME-Challenge-Route) und zeigt dir die Antwortnachweise pro Domain. Deine bestehende Engine bedient weiterhin die echten Ports :80 / :443.

• Phase 4 — Atomare Umschaltung. Sichert deine bestehende Konfiguration (/etc/nginx.helm-backup.<timestamp>/ oder /etc/apache2.helm-backup.<timestamp>/ oder /tmp/traefik.helm-backup.compose.*.yml), stoppt die alte Engine, startet Caddy auf den echten Ports :80 / :443, prüft jede Domain mit einem weiteren curl-Durchlauf und stellt dann deinen bestehenden certbot.timer vom Erneuerungsmodus mit Engine-Plugin (certbot --nginx, certbot --apache) auf den Webroot-Modus um, den Caddy ausliefern kann. Der certbot.timer bleibt für die Erneuerung zuständig; ein Deploy-Hook lädt Caddy bei jeder Erneuerung neu, sodass du dich nicht darum kümmern musst.

Wenn die Verifizierung an irgendeiner Stelle in Phase 4 fehlschlägt, führt das Rezept automatisch einen Rollback aus: Caddy wird gestoppt, die alte Engine wird neu gestartet, deine bestehende Konfiguration bleibt unangetastet. Du bist in <10 Sekunden wieder im Zustand vor der Migration.

4. Bestätigen + Übergabe

Nachdem Phase 4 erfolgreich abgeschlossen ist, bittet Faro dich, Server-Info → Webserver noch einmal zu öffnen und zu prüfen.

Der Tab aktualisiert sich beim Öffnen selbst (kein Trennen/Neuverbinden nötig). Du solltest Folgendes sehen:

• Engine: Caddy (Host-Service)
• TLS-Zertifikate — bei Migrationen von nginx/Apache: certbot (Let's Encrypt, renewed by certbot.timer; served by Caddy via deploy-hook reload). Bei Migrationen von Traefik: Caddy ACME (automatic Let's Encrypt) — Traefiks alte acme.json-Zertifikate werden nicht wiederverwendet; Caddy holt beim Umschalten neue.
• Status: ✓ Server Manager verwaltet diesen Server vollständig. Jedes Rezept und jeder Assistent funktioniert direkt; nichts wird an den reinen Chat-Fallback weitergeleitet.

Dein altes Engine-Paket bleibt als manuelle Rollback-Option etwa 30 Tage installiert (aber deaktiviert). Auch das Konfigurations-Backup bleibt auf der Festplatte. Sobald du sicher bist, dass die Migration stabil ist (nach etwa 1 Woche), kannst du mit apt remove nginx / apt remove apache2 ein paar MB freigeben oder den alten Traefik-Container mit docker rm traefik entfernen.

Hinweise je Engine

Der Ablauf mit Probelauf und anschließender Umschaltung ist bei allen Engines gleich. Die Unterschiede sind rein technisch:

nginx. Prüfung der Quell-Engine über sudo nginx -T. Backup unter /etc/nginx.helm-backup.<ts>/. Übergabe der Erneuerung: authenticator = nginx → authenticator = webroot in /etc/letsencrypt/renewal/<domain>.conf. Das Plugin certbot --nginx wird nicht mehr verwendet; certbot.timer läuft weiter.

Apache. Gleicher Ablauf, mit Pfaden für apache2 (Debian) oder httpd (RHEL). Vhost-Erkennung über apache2ctl -S + Lesen von sites-enabled/ (oder conf.d/ auf RHEL). Backup unter /etc/apache2.helm-backup.<ts>/. Übergabe der Erneuerung: authenticator = apache → webroot. Setups mit mod_php werden als nicht verwaltbar markiert, bis du sie entfernst — Caddy führt PHP nicht im selben Prozess aus wie Apache + mod_php.

Traefik. Die Quell-Engine ist ein Docker-Container und wird mit docker stop traefik gestoppt (nicht mit systemctl stop). Vhosts stammen aus traefik.http.routers.*-Labels laufender Container, nicht aus Konfigurationsdateien. Zertifikate werden nicht wiederverwendet — Caddy holt beim Umschalten über Auto-HTTPS frische Let's-Encrypt-Zertifikate, was eine neue Ausstellung pro Domain auslöst (Zertifikatsfenster ca. 30–60 Sekunden). Router mit eigenen Middlewares oder Matchern, die nicht Host() sind, werden als nicht verwaltbar markiert. Backends müssen auf dem Host veröffentlichte Ports haben (z. B. 127.0.0.1:8080:80 in der Compose-Datei) — Caddy als Host-Service kann keine Container erreichen, die nur im Docker-Netzwerk erreichbar sind.

Was, wenn das Rezept ablehnt?

Wenn die Verwaltbarkeitsprüfung ein rotes ✗ zeigt, nennt Faro die genaue Direktive und den Vhost. Typische Lösungen:

• **nginx proxy_cache_path / fastcgi_cache** — diese lassen sich nicht 1:1 nach Caddy übersetzen. Entferne die Cache-Zone (oder verlagere Caching zu einem CDN wie Cloudflare) und versuche es erneut. Die meisten Nicht-Caddy-Nutzer auf kleinen Servern brauchen kein Caching direkt auf dem Server.
• **Apache RewriteRule ... [L,R=301]** — die Markierungen weisen auf mehrstufige Ketten hin, die der Übersetzer nicht modellieren kann. Wandle sie in ein einfacheres Redirect permanent um oder flache die Kette vorher ab.
• Traefik middlewares — Middlewares brauchen je Typ eine eigene Caddy-Übersetzung, die das Rezept in v1 nicht automatisch übernimmt. Entferne die Middleware-Labels und richte das Äquivalent nach der Migration in Caddy ein (Basic Auth, Rate Limit, Header — alles unterstützt, nur nicht automatisch übersetzt).
• **Traefik HostRegexp-Regel** — Regex-Matcher lassen sich nicht 1:1 übersetzen. Wechsle zu einer oder mehreren Host()-Regeln mit expliziten Hostnamen.

Wenn du deine Konfiguration nicht vereinfachen kannst und nicht migrieren möchtest, funktioniert der Chat-Pfad weiterhin für alles, was Server Manager normalerweise per Rezept erledigen würde — eine Website deployen, WordPress installieren, eine Domain verbinden, eine Datenbank einrichten, ein Backup erstellen, aus einem Backup wiederherstellen usw. Faro liest deine bestehende Engine aus und schlägt die passenden nativen Befehle vor (/etc/nginx/sites-available/ + certbot --nginx für nginx, das Apache-Äquivalent, Docker-Labels für Traefik). Konkrete Beispielanfragen, die heute auf einem Nicht-Caddy-Server funktionieren:

• „Füge auf diesem nginx-Server eine neue WordPress-Website unter blog.mysite.com hinzu“ — Faro schlägt den nginx-Vhost + das docker compose für WordPress + certbot vor. Du bestätigst jedes Paket.
• „Mein TLS-Zertifikat für api.mysite.com läuft bald ab — prüfe es und erneuere es bei Bedarf“ — Faro führt die Prüfung + die Erneuerung + den Reload aus, alles im Chat.
• „Erstelle ein Backup der Workload api.mysite.com“ — Faro findet heraus, was gedumpt werden muss, wie es gepackt werden soll, und bietet dir den Download-Link an.

Du verlierst keine Funktionen, wenn du bei deiner aktuellen Engine bleibst. Du tauschst Ein-Klick-Komfort in der Oberfläche gegen entsprechende Abläufe, die über den Chat vermittelt werden.

Referenz

Dateien, die während der Migration auf deinen Server geschrieben werden:

• /etc/caddy/Caddyfile — Caddys Website-Konfiguration (neu auf diesem Server)
• /var/www/certbot/.well-known/acme-challenge/ — Webroot für ACME-Erneuerungen (nginx + Apache; nicht genutzt bei Traefik-Migrationen)
• /etc/letsencrypt/renewal-hooks/deploy/reload-caddy.sh — lädt Caddy bei jeder certbot-Erneuerung neu (nur nginx + Apache)
• /etc/letsencrypt/renewal/<domain>.conf — gezielt bearbeitet, um authenticator = nginx / authenticator = apache → authenticator = webroot umzustellen (nur nginx + Apache)

Dateien / Zustand, die für einen Rollback erhalten bleiben:

• nginx: /etc/nginx.helm-backup.<timestamp>/ (vollständige Konfigurationskopie)
• Apache: /etc/apache2.helm-backup.<timestamp>/ (Debian) oder /etc/httpd.helm-backup.<timestamp>/ (RHEL)
• Traefik: /tmp/traefik.helm-backup.compose.<timestamp>.yml (die docker-compose-Datei), plus der gestoppte Traefik-Container selbst
• Das alte Engine-Paket bleibt installiert, aber deaktiviert (systemctl disable apache2 / nginx; docker update --restart=no traefik)

Bestätigungsschritte: normalerweise 4 Klicks für nginx und Apache, 5 für Traefik (der zusätzliche Schritt kommt dazu, wenn Faro einen nicht standardmäßigen Probelauf-Port wählen muss, weil dein Backend bereits :8080 nutzt).