Eigener Gitea-Pages-Stack mit Wildcard-Subdomains und ACME – mein GitHub-Pages-Ersatz

Sat, 19 Apr 2025 00:00:00 +0000

Einführung

Dieser Beitrag dokumentiert meinen eigenen Gitea-Pages-Stack – eine datenschutzfreundliche Alternative zu GitHub Pages. Mit GT-RUNNER, dem Codeberg Pages Server und Traefik als Reverse Proxy entsteht ein selbstverwalteter Hosting-Stack, der Domains, Zertifikate und Deployments vollständig automatisiert – ohne zentrale Abhängigkeiten und mit voller Kontrolle.

Architekturüberblick

Die folgende Skizze zeigt die Struktur meines Stacks. Alle zentralen Komponenten – Gitea, Runner, Pages Server und Reverse Proxy – sind im internen Netzwerk miteinander verbunden. Die TLS-Zertifikatsvergabe erfolgt gestaffelt über Let’s Encrypt (intern Staging, extern Production):

Funktionsweise im Detail

Ganz ehrlich: Das Ganze ist im Kern ein ganz normaler Git-Server. Gitea läuft intern, der GT-Runner ist angebunden – läuft über „act“ mit einem recht großen Image, bringt aber alles mit, was GitHub Actions auch kann. Für meine Zwecke ist das kompatibel genug.

Dazu kommt der Codeberg Pages Server – ebenfalls intern. Der spricht mit Gitea über die API, genau wie es gedacht ist. Wichtig: Alles, was Gitea, der Runner und der Pages-Server machen, bleibt komplett im internen Netzwerk. Da kommt nichts nach draußen. Das war mir wichtig.

Jetzt zum Thema TLS: Der Pages-Server kann nicht ohne Zertifikate. Also bekommt er welche – ganz regulär über meinen DNS-Provider, via API und ACME-Protokoll. Aber eben nur Staging-Zertifikate von Let’s Encrypt. Warum? Weil das reicht. Es geht um internes TLS, nicht um Vertrauen von außen.

Der Pages-Server kann dann sauber ausliefern – intern, per HTTPS, mit gültiger Struktur. Und mein Reverse Proxy (Traefik) kümmert sich um den Rest.

Traefik ist so konfiguriert, dass ihm egal ist, ob das interne Zertifikat „echt“ ist. Er terminated TLS nach außen hin selbst, holt sich dafür eigene echte Zertifikate über DNS-01 und Let’s Encrypt Production, und mappt die Domains sauber weiter.

Damit das überhaupt funktioniert, schreibe ich die Requests um. Traefik nimmt z. B. home.pagessub.0xmax42.io, extrahiert daraus, um welches Repository es geht, und gaukelt dem Pages-Server vor, dass die URL intern user.pagessub.0xmax42.io/repo/ wäre. Damit der Pages-Server richtig routet.

Nach außen hin sieht alles aus wie bei GitHub Pages – jede Subdomain bekommt ihr eigenes statisches Projekt. Nur eben: datenschutzfreundlich, selbst gehostet, ohne Vendor-Lock-in.

Ausblick

Langfristig will ich es ermöglichen, dass Repositories selbst konfigurieren können, unter welcher Domain sie ausgeliefert werden – z. B. über eine .traffic-Datei. Über die Gitea-API könnte dann automatisch die passende Traefik-Konfiguration erzeugt und an Traefik übergeben werden. Das Ziel: ein vollständig automatisierter Webhosting-Stack.

Verwendete Komponenten

🧃 Gitea – Selfhosted Git-Service
🌀 Traefik – Reverse Proxy mit ACME-Support
📦 Codeberg Pages Server – statischer Pages-Server
🔀 traefik-subdomain-path-rewrite-plugin – für dynamisches URL-Rewriting basierend auf Subdomains
🔐 Let’s Encrypt – kostenfreies TLS-Zertifikatsmanagement via ACME-Protokoll
🐳 Docker – Containerisierung aller Komponenten zur einfachen Verwaltung und Isolierung