Warum GitHub Pages vielleicht nicht ausreicht (und was du stattdessen tun kannst)

Ganz ehrlich: GitHub Pages hat schon etwas Magisches. Code pushen, Website erscheint – fertig. Keine Server-Konfiguration, keine nervigen CI/CD-Pipelines, keine Deployment-Skripte, die ausgerechnet freitags abstürzen. Diese Einfachheit lässt einen glatt vergessen, was da eigentlich im Hintergrund läuft.

Aber genau da liegt der Haken. Bei GitHub Pages landet dein Code, deine Deployment-Infrastruktur und deine Daten auf US-amerikanischem Boden – juristisch gesehen zumindest. Und im Jahr 2024 wird das relevanter, als die meisten Entwickler ahnen.

Das Cloud Act-Problem

Der US Cloud Act ist seit 2018 Gesetz. Er erlaubt US-Behörden, von amerikanischen Unternehmen Daten anzufordern – auch wenn diese Daten physisch auf Servern in Frankfurt, Amsterdam oder Dublin liegen. GitHub (gehört zu Microsoft) und GitLab Inc. sind US-Firmen. Punkt, aus, fertig.

Bevor du das als Panikmache abtust, überlege einmal, was wirklich in deinem Repository liegt:

• unveröffentlichte Blogposts mit Produktankündigungen
• interne Team-Dokumentation
• Kundendaten in Issues und Wikis
• Deployment-Zugangsdaten und Access Tokens
• Zugriffsprotokolle, die zeigen, wer sich in deinen Projekten umgeschaut hat

Nichts davon ist öffentlich. Alles davon ist unter den richtigen (oder falschen) Umständen theoretisch abrufbar. Für einen Firmenblog mag das okay sein. Für ein Startup mit unveröffentlichten Features, eine Agentur mit Kundenprojekten oder jemanden, der mit sensiblem Quellcode arbeitet – da sollte man hellwach werden.

Die Transparenzlücke

Was mich an den großen Plattformen am meisten frustriert: die Intransparenz bei der Datenerfassung.

GitHub, GitLab und Cloudflare bieten alle GDPR-Compliance und Datenverarbeitungsvereinbarungen. Das fühlt sich beruhigend an – bis dir klar wird, dass du nicht weißt, was sie tatsächlich loggen. IP-Adressen? User Agents? Zeitstempel mit Geolocation? Die Standardbedingungen sind vage, und die echten Server-Logs bekommst du nie zu sehen.

Vergleiche das mit kleineren Anbietern wie statichost.eu, die offen dokumentieren, was ihre Server tatsächlich protokollieren: keine IP-Adressen, keine User Agents, nur aggregierte Antwortgrößen für die Abrechnung. Sogar ein Beispiel-Logeintrag ist in der Dokumentation enthalten. So baut man Vertrauen auf.

Dann gibt es noch das juristische Minenfeld rund um das EU-US Data Privacy Framework. Der Nachfolger von Privacy Shield, das Instrument, mit dem US-Unternehmen Datentransfers aus Europa legitimieren. Das Problem: Das Framework basiert wesentlich auf der Unabhängigkeit der FTC – und der US Supreme Court hat genau diese Unabhängigkeit kürzlich infrage gestellt. Der juristische Untergrund unter transatlantischen Datentransfers ist im Wandel. Europäische Infrastruktur auf europäischen Servern ist kein nettes Extra mehr – es wird zunehmend zur einzigen stabilen Basis.

Die Nahtlosigkeitsfalle

GitHub Pages ist so elegant integriert, dass du aufhörst, „Code-Hosting" und „Website-Deployment" als getrennte Konzepte zu denken. Es ist einfach alles GitHub. Diese nahtlose Experience ist brillante UX – aber sie erzeugt eine versteckte Abhängigkeit.

Du bist nicht im harten Sinne eingeschlossen – technisch ist eine Migration straightforward. Aber wenn du diese Zusammenhänge nie mental getrennt hast, optimierst du sie auch nie unabhängig voneinander. Du nimmst, was GitHub fürs Deployment bietet, weil das halt einfach so ist.

Das ist das Argument der seams-based Architecture, angewandt auf Infrastruktur: Kopplung erzeugt versteckte Kosten, selbst wenn sie sich bequem anfühlt.

Der europäische Alternativ-Stack

Die gute Nachricht: Statische Sites sind von Natur aus portabel. Der ganze Sinn eines Static Site Generators ist, dass dein Content zu plain Files wird. Hosting umziehen ist selten so schmerzhaft wie eine Datenbank-Anwendung zu migrieren.

Der entstehende Alternativ-Stack sieht ungefähr so aus:

Für Git-Hosting:

Codeberg betreibt Forgejo (ein Community-Fork von Gitea) und wird von einem Non-Profit in Berlin operiert. Kostenlos, komplett Open Source, Infrastruktur in Deutschland. Für öffentliche Repositories und Open-Source-Projekte eine offensichtliche Wahl. Die Bedingungen heißen explizit Open-Source-Arbeit willkommen.

Codefloe ist das kommerzielle Gegenstück – ebenfalls Forgejo-basiert, aber ohne Nutzungsbeschränkungen. Private Repositories? Kommerzielle Projekte? Enterprise-Teams? Alles willkommen. Wenn dein Quellcode nicht öffentlich sein sollte, ist das deine europäische Option.

Beide Plattformen sprechen Standard-Git. Von GitHub wechseln bedeutet, eine Remote-URL ändern. Import-Tools übertragen deine komplette History.

Für Deployment:

statichost.eu baut und hostet statische Sites in europäischen Rechenzentren. Repository per Webhook verbinden, Build-Prozess angeben (Docker-Images werden unterstützt, also funktioniert praktisch jeder Static Site Generator), und beim Push deployen. Custom Domains, SSL-Zertifikate, das komplette Paket.

Die Trennung ist nicht nur philosophisch – sie ist praktisch. Du kannst deinen Git-Hoster wechseln, ohne dein Deployment anzufassen, oder dein Hosting migrieren, ohne den Code zu bewegen. Zwei unabhängige Komponenten, zwei unabhängige Entscheidungen.

Den Umstieg wagen

Falls du überzeugt bist, aber Komplexität fürchtest: Dieser Stack ist tatsächlich genauso bequem wie GitHub Pages. Zola baut Sites in Millisekunden. Codeberg oder Codefloe kümmern sich ums Repository. statichost.eu löst die Builds aus. Das Developer Experience ist nahezu identisch.

Der Unterschied: Wenn du schläfst, leben deine Daten in Europa, governed von europäischem Recht, geloggt mit europäischer Transparenz, kontrolliert von europäischen Organisationen.

Für manche Projekte ist GitHub Pages völlig in Ordnung. Für Projekte, bei denen Datensouveränität, Privatsphäre oder professionelle Diskretion zählen, verdient der europäische Alternativ-Stack ernsthafte Betrachtung.

Statische Sites sind von Natur aus portabel. Vielleicht wird es Zeit, dass deine Infrastruktur das widerspiegelt.