Statische Seiten ohne Big-Tech-Hosting

Wer eine statische Website oder einen Blog betreibt, greift oft reflexartig zu GitHub Pages oder GitLab Pages. Alles, was es braucht, ist ein dort gehostetes Git-Repository, und ein git push sorgt sofort dafür, dass die Seite neu gebaut und deployt wird. Aber hinter dieser Bequemlichkeit steckt ein Problem, das leicht übersehen wird: Code-Hosting und Website-Deployment sind untrennbar miteinander gekoppelt, und beides liegt bei US-amerikanischen Unternehmen unter US-Recht.

‍

Microsoft (GitHub) und GitLab Inc. unterliegen dem US Cloud Act. Das bedeutet: US-Behörden können unter bestimmten Umständen auf Daten zugreifen, auch wenn die Server physisch in Europa stehen. Der Inhalt einer öffentlichen statischen Website ist dabei das geringste Problem, denn der ist ohnehin frei zugänglich. Was aber tatsächlich bei GitHub oder GitLab liegt und nicht öffentlich ist: der Quellcode (bei privaten Repositories), unveröffentlichte Entwürfe, Deployment-Logs, Account- und Zugangsdaten sowie Zugriffsstatistiken. Für einen Unternehmens-Blog können das zum Beispiel noch nicht veröffentlichte Inhalte, interne Strukturen oder Hinweise auf Kundenprojekte sein.

‍

GitHub, GitLab und Cloudflare verfügen alle über Data Processing Agreements und adressieren DSGVO-Compliance formal. Als Website-Betreiber weißt du aber nicht, welche Besucherdaten – IP-Adressen, User-Agents, Zeitstempel – tatsächlich erfasst werden.

statichost.eu dokumentiert transparent, was in Server-Logs landet: keine IP-Adressen, keine User-Agents, nur aggregierte Antwortgrößen für die Abrechnung – belegt durch einen echten Log-Eintrag in ihrer Dokumentation. Was GitHub, GitLab oder Cloudflare tatsächlich loggen, bleibt unklar. Hinzu kommt die Rechtsgrundlage: Das EU-US Data Privacy Framework, auf das sich US-Anbieter bei Datentransfers berufen, basiert maßgeblich auf der Unabhängigkeit der FTC – die der US Supreme Court Ende Juni 2026 für verfassungswidrig erklärt hat. Europäisches Recht auf europäischen Servern ist gerade keine Kleinigkeit.

‍

Dazu kommt eine subtilere Form der Abhängigkeit: GitHub Pages ist so nahtlos in den GitHub-Workflow integriert, dass man die Kopplung zwischen Code-Hosting und Deployment kaum wahrnimmt. Das ist kein harter Lock-in. Wie dieses Rezept zeigt, ist der Wechsel technisch unkompliziert. Aber wer beides nie bewusst getrennt hat, denkt auch nicht daran, die Komponenten unabhängig voneinander zu optimieren oder auszutauschen.

‍

Die gute Nachricht: Statische Websites sind von Natur aus portabel. Die Idee hinter diesem Rezept ist einfach: Git-Hosting und Website-Hosting trennen und jeweils durch eine europäische Alternative ersetzen. Das Ergebnis ist ein Stack, der genauso komfortabel ist wie GitHub Pages, vollständig in europäischer Hand liegt und bei dem beide Komponenten unabhängig voneinander ausgetauscht werden können.

‍

Konkret zeigen wir, wie man eine bestehende Website zu Codeberg oder Codefloe als Git-Hoster und statichost.eu für das Deployment portiert.

‍

Zutaten

‍

Ein statischer Site-Generator

‍

Für dieses Rezept verwenden wir Zola, einen in Rust geschriebenen Generator, der sich durch kurze Build-Zeiten auszeichnet und ohne externe Abhängigkeiten auskommt. Das Prinzip funktioniert aber mit jedem anderen Generator genauso, z.B. Hugo, Eleventy oder Jekyll. statichost.eu baut die Site mit einem Docker-Image deiner Wahl. Das gibt maximale Freiheit, auch für ungewöhnliche Build-Setups.

‍

Ein europäischer Git-Hoster

‍

Statt GitHub oder GitLab empfehlen wir hier zwei Alternativen, die beide auf Forgejo basieren, einem Community-Fork von Gitea:

‍

‍Codeberg ist ein gemeinnütziger Verein mit Sitz in Berlin. Codeberg ist kostenlos, vollständig Open Source, und die Infrastruktur liegt in Deutschland. Für Open-Source-Projekte ist es eine naheliegende Wahl. Wer den Quellcode seiner Website öffentlich hostet, ist klar im Rahmen der Nutzungsbedingungen. Private Repositories sind laut Nutzungsbedingungen auf FLOSS-Projekte sowie wirklich kleine persönliche Inhalte wie Notizen oder Config-Dateien beschränkt. Ein Website-Quellcode bewegt sich dort in einer Grauzone. Wer auf der sicheren Seite sein will, hostet das Repository öffentlich. Codeberg ist bewusst keine kommerzielle Allzweck-Plattform.

‍

‍Codefloe richtet sich ausdrücklich an alle, von Einzelentwicklern über Open-Source-Projekte bis hin zu Enterprise-Teams, und macht keine Einschränkungen hinsichtlich des Inhalts. Die Plattform basiert ebenfalls auf Forgejo, betreibt eine cloud-native Infrastruktur und entwickelt sich öffentlich weiter. Private Repositories sind ohne Einschränkungen nutzbar, was Codefloe zur besseren Wahl macht, wenn der Quellcode nicht öffentlich sein soll oder ein kommerzieller Kontext vorliegt.

‍
Beide sind vollständig kompatibel mit dem Standard-Git-Protokoll. Ein Wechsel von GitHub bedeutet im Wesentlichen nur, die Remote-URL zu ändern, und beide bieten eine Import-Funktion, die die Repository-History übernimmt. statichost.eu ist darüber hinaus nicht auf diese beiden beschränkt: Der Dienst unterstützt prinzipiell jeden Git-Hoster, der Webhooks anbietet, also auch selbst gehostetes Forgejo oder andere Plattformen.

‍

statichost.eu

‍

statichost.eu ist ein europäischer Hosting-Dienst, der speziell für statische Websites gemacht ist. Alles, was man tun muss, ist, eine Site mit einem dahinter liegenden Repository anzulegen und anzugeben, wie die statische Seite gebaut wird. Optional kann, wie bei GitHub Pages und GitLab Pages, natürlich auch eine Custom Domain verwendet werden.

‍

Bei jedem Push wird die Site automatisch neu gebaut und ausgeliefert. Anbieter und Infrastruktur sind europäisch. Was in Server-Logs landet, ist auf das absolute Minimum reduziert: Zeitstempel, HTTP-Methode, Host, Antwortgröße und Statuscode, keine IP-Adressen, keine User-Agents. Die Logs werden nach spätestens sieben Tagen gelöscht, in der Praxis meist früher. Für Organisationen stellt statichost.eu selbstverständlich ein Data Processing Agreement bereit.

‍

Zubereitung

‍

Wir gehen davon aus, dass eine statische Website bereits existiert und über GitHub Pages gehostet wird. Der Quellcode liegt also in einem GitHub-Repository, und GitHub baut und deployt die Site bei jedem Push. Genau diese Kopplung lösen wir jetzt auf. Alle Schritte funktionieren mit Codeberg analog zu Codefloe.

‍

Schritt 1: Repository zu Codefloe migrieren

‍

Um das Repository zu Codefloe zu migrieren, gibt es zwei Möglichkeiten. Die erste ist die automatische Migration. Dazu muss in GitHub zunächst ein Personal Access Token (PAT) angelegt werden.

‍

‍

Diesem müssen die notwendigen Rechte zugewiesen werden, um den Inhalt des bestehenden GitHub-Repositories zu lesen, wie im folgenden Screenshot gezeigt.

‍

‍

In Codefloe wählen wir dann statt des üblichen "New Repository" die Option "New migration".

‍

Nun können wir die URL des GitHub-Repositories, unser Access Token sowie die Items, die wir migrieren wollen, angeben. Im Beispiel entscheiden wir uns, nicht nur den Source-Code und dessen Git-Historie, sondern auch die Issues zu importieren.

‍

‍

Statt einer solchen Migration kann aber auch einfach ein neues Repository auf Codefloe angelegt werden. In unserer lokalen Kopie setzen wir nun den Origin auf die Remote-URL des neuen Codefloe-Repositories und pushen es dorthin.

‍

‍git remote set-url origin https://codefloe.com/dein-nutzername/meine-website.git
git push -u origin main

‍

Schritt 2: Projekt auf statichost.eu anlegen

‍

Registriere dich auf statichost.eu und lege ein neues Projekt an. Du wirst nach der Repository-URL gefragt. Trage hier die URL deines Codeberg- oder Codefloe-Repositories ein.

‍

‍

Schritt 3: Build-Konfiguration

‍

Beim Anlegen des Projekts können Zola oder andere gängige Static-Site-Generatoren wie Hugo, Jekyll oder Gatsby ausgewählt werden. Im Fall von Zola können dann eine Version, ein Ausgabeverzeichnis und optionale Build Flags festgelegt werden. Für Generatoren, die statichost.eu nicht kennt, kann auch Docker ausgewählt werden. Dann ist es möglich, ein Docker-Image, ein Build-Kommando und das Ausgabe-Verzeichnis festzulegen.

‍

‍

Alternativ zu der Build-Konfiguration im Web-UI kann im Git-Repository aber auch eine statichost.yml-Datei hinterlegt werden. Diese sieht für Zola dann etwa so aus:


image: ghcr.io/getzola/zola:v0.21.0
command: build
public: public
image_entrypoint: true


‍

Schritt 4: Webhook einrichten

‍

Damit statichost.eu bei jedem Push automatisch einen neuen Build anstößt, muss ein Webhook im Repository konfiguriert werden. statichost.eu zeigt nach dem Anlegen des Projekts die passende Webhook-URL an.

In Codefloe findet sich die Konfiguration unter Repository → Settings → Webhooks → Add webhook. Dort muss dann die Webhook-URL von statichost.eu eingetragen und als Trigger „Push Events" gewählt werden. In Codeberg ist der Weg analog.

‍

‍

Nach dem nächsten git push baut statichost.eu die Site automatisch und stellt sie unter einer *.statichost.page-Subdomain bereit.

‍

Schritt 5: Eigene Domain einrichten (optional)

‍

statichost.eu unterstützt eigene Domains inklusive automatischer TLS-Zertifikate via Let's Encrypt. Dazu wird ein CNAME-Eintrag beim DNS-Anbieter gesetzt, der auf die von statichost.eu bereitgestellte Adresse zeigt. Die genauen Werte werden im Projekt-Dashboard angezeigt.

‍

Topping

‍

Wer den Stack vollständig selbst hosten möchte, kann Forgejo Actions oder Crow CI (Codefloes integriertes CI-System) nutzen, um bei jedem Push einen Build anzustoßen und das Ergebnis per rsync auf einen eigenen VPS zu übertragen, serviert von nginx, Apache oder Caddy.

‍

Ehrlicherweise ist das aber kein gleichwertiger Ersatz: statichost.eu bringt ein verteiltes CDN über Bunny und Ausfallsicherheit direkt mit. Hinzu kommt die konsequente Datensparsamkeit: gängige Webserver loggen standardmäßig IP-Adressen, User-Agents und Referrer. Das auf ein datenschutzfreundliches Minimum zu reduzieren, ist manuelle Konfigurationsarbeit, die leicht vergessen wird. Bei statichost.eu ist das von Haus aus so umgesetzt.

‍