Caddy

Apache vs. Caddy

Apache war gestern. Wer heute einen Webserver aufsetzt, denkt vielleicht an Nginx – leichtgewichtig, schnell, bewährt. Doch es gibt noch eine dritte Option, die viele übersehen: Caddy. Der Server verspricht nicht nur eine einfache Konfiguration, sondern bringt automatisches HTTPS gleich mit. Klingt spannend? Ist es auch. Zeit, genauer hinzuschauen.

Für das aktuelle Projekt geht es darum, einen Reverse-Proxy zu installieren, der OAuth-Anfragen für die Anwendung bearbeitet und den Header mit den User-Informationen an die App weitergibt, etwa im Format:

X-Auth-Username: @karsten

Die App selbst bleibt frei von Authentisierungscode. Caddy regelt Login, Logout, Sessions und Redirects.

Caddy bauen

Zunächst muss der Caddy-Server mit den erforderlichen Modulen gebaut werden. Das geschieht mit dem Werkzeug xcaddy sehr einfach, sofern Go installiert ist:

1
2
3
$ go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
$ xcaddy build --with=github.com/greenpau/caddy-security \
               --with=github.com/caddy-dns/cloudflare

Das letzte Kommando baut die Auth-Module ein und installiert den DNS-Handler für Cloudflare, um die Challenges für das ACME-Protokoll eintragen zu können.

Alternativ kann man sich auf der Caddy-Website die Module zusammenklicken und einen angepassten Server herunterladen.

ℹ️

Ich habe Apache durchgespielt

So fühlte es sich an, nachdem ich eine uralte mod_perl-basierte Software entstauben, aufräumen und irgendwie in die Jetztzeit hieven musste. Auf Apache 2.x zu migrieren war keine Option – fehlende Module, nicht mehr kompatibel. Apache 1.x war längst aus dem Support. Und natürlich lief ich in einen Bug, der nie gefixt wurde. Ich diskutierte ihn auf der Mailingliste mit den Core-Entwicklern – was spannend war. Gelöst wurde das Problem trotzdem nicht.

Apache war für mich damit offiziell abgeschlossen. Ich hatte den Endgegner besiegt. Und so kam ich zu Nginx – schlanker, schneller, moderner. Alles besser? Nicht ganz. Denn irgendwann stieß ich auf einen Server, der noch einfacher ist: Caddy. Der macht TLS einfach so. Reverse Proxy? Ein Einzeiler. Kein Gefrickel mehr.

OAuth-Provider einrichten

Als OAuth-Provider bevorzuge ich Github; selbstverständlich sind auch andere kompatible Provider möglich.

Unter https://github.com/settings/developers erstellt man eine neue Anwendung. Die Callback URL ist Authorization callback URL: https://dein-domain.tld/oauth2/github/callback. Danach bekommt man Client-ID und Cleint Secret. Diese sichert man sich zweckmäßigerweise im Password Safe.

Caddy konfigurieren

https://github.com/authcrunch/authcrunch.github.io/blob/main/assets/conf/oauth/github/Caddyfile https://docs.authcrunch.com/docs/intro

🧩

Hinweise

Ersetze GITHUB_CLIENT_ID und GITHUB_CLIENT_SECRET durch die Werte aus deiner GitHub-OAuth-App.
Caddy erledigt TLS automatisch, solange DNS (A/AAAA-Record) korrekt auf die Maschine zeigt.
Dein Backend läuft auf localhost:8000 und bekommt Auth-Header übermittelt.
Die Nutzeroberfläche vom Login-Portal erscheint automatisch beim ersten Zugriff.

Static users

https://docs.authcrunch.com/docs/authenticate/local/static-users

Portal anpassen

/etc/caddy/
├── Caddyfile
└── themes/
    └── tellcast/
        ├── login.html
        └── assets/
            ├── style.css
            └── logo.png

1
2
3
4
auth_portal {
  ...
  theme tellcast
}

📌

Wichtig

Caddy muss Zugriff auf den Theme-Ordner haben (z. B. über :ro-Mount bei Docker oder direkt in /etc/caddy).
Template-Platzhalter wie {{ .LoginURL }} und {{ .LogoutURL }} kannst du verwenden.

Machinectl Dev Setup