Warten Sie nicht auf den nächsten Ausfall: Die GitHub-Exit-Strategie für CTOs

Sie würden Ihre Produktion nicht in nur einer Availability Zone betreiben. Betreiben Sie Ihre Engineering-Organisation auch nicht in nur einer Code‑Forge.

In den letzten Wochen gab es eine Reihe von Erinnerungen daran, dass GitHub eine Abhängigkeit ist, keine Garantie: eine offengelegte RCE‑CVE, ein öffentliches Update zu einem availability incident, das Projekt Ghostty kündigt öffentlich an, GitHub zu verlassen, und HardenedBSD baut sich auf Radicle auf. Keines davon bedeutet: „In Panik geraten und morgen migrieren.“ Es bedeutet: Handeln Sie wie ein nüchterner Plattformverantwortlicher – sichern Sie Ihr Risiko jetzt ab, damit Sie später ohne Drama migrieren können.

Dieser Beitrag liefert einen Entscheidungsrahmen und eine konkrete Architektur für eine Dual‑Home‑Git‑Strategie: Behalten Sie GitHub als Primärsystem bei und bauen Sie ein zweites Zuhause auf, zu dem Sie in Stunden statt Wochen umschalten können. Außerdem bekommen Sie einen 30‑60‑90‑Tage‑Plan und die Fallstricke, die wir aus nächster Nähe gesehen haben – aus Projekten für US‑Teams mit unseren in Brazil ansässigen Platform Engineers.

Warum eine GitHub‑Absicherung rational ist (nicht reaktionär)

• Abhängigkeit von einer einzelnen Forge. Wenn Ihre Repos, CI, Pakete und Code‑Suche hinter einem einzigen Anbieter hängen, kann ein anbieterseitiger Auth‑Ausfall die Engineering‑Arbeit in Minuten zum Erliegen bringen. Das messen Sie im gemischten Engineering‑Stundensatz – nicht in SLA‑Nachkommastellen.
• Sicherheitsvorfälle passieren. RCEs und Token‑Lecks wird es bei allen Forges weiterhin geben. Die Abhilfe ist nicht „den Anbieter wechseln“. Sie lautet: „Breach annehmen, Schadensradius begrenzen, schnell failovern.“
• Policy‑ und Preisänderungen. Änderungen an AGB oder Preisen (denken Sie an nutzungsbasierte AI‑Add‑ons oder steigende Seat‑Kosten) können das Budget mitten im Jahr treffen. Sie brauchen Verhandlungsmacht vor der Verlängerung – nicht danach.
• Compliance und Souveränität. Bestimmte Kunden (insbesondere Enterprise oder regulierte) verlangen zunehmend nachweisbare Code‑Provenance und einen Anbieter‑Exit‑Plan. Ein Spiegel mit signierten Builds überzeugt Auditoren, die fragen: „Was ist, wenn GitHub 48 Stunden nicht verfügbar ist?“

Auf GitHub zu bleiben, ist in Ordnung. Nur auf GitHub zu bleiben – ohne getesteten Notausstieg – ist es nicht.

Der Entscheidungsrahmen: drei Stufen der Bereitschaft

Level 0: Status quo (hier sollten Sie nicht bleiben)

• Alle Repos, Issues, CI/CD, Pakete auf GitHub.
• Personal Access Tokens für Automatisierung.
• Keine Offsite‑Backups, keine Commit‑Signaturen, keine Provenance.

Zeit bis zum Exit: Tage bis Wochen, mit schmerzhaften Lücken und Datenverlust.

Level 1: Absicherung (starten Sie hier, 0–30 Tage)

• Nächtliche Bare‑Repo‑Backups Offsite (verschlüsselt), einschließlich Git LFS.
• Schlüsselloses Signieren von Builds via Sigstore (Fulcio/Rekor) und Provenance‑Metadaten (SLSA L2+).
• GitHub Actions verwenden OIDC zur Cloud für Credentials; keine langlebigen Secrets.
• Package‑Artefakte werden in ein neutrales Registry gespiegelt (z. B. ECR/Artifact Registry/Quay), nicht nur in GitHub Packages.

Zeit bis zum Exit: 48–72 Stunden mit Mehrarbeit und etwas manueller Nacharbeit.

Level 2: Dual‑Home (was Sie wirklich wollen, 30–90 Tage)

• GitHub bleibt primär. Forgejo/Gitea/GitLab CE laufen als Hot‑Mirror (per Policy read‑only).
• Alle Repos werden beim Commit per Push gespiegelt; Issues/Discussions werden zeitgesteuert gespiegelt.
• CI/CD‑Definitionen sind runner‑neutral mit einer Schatten‑Pipeline auf WoodpeckerCI/Drone, Buildkite oder Tekton.
• Sourcegraph/Zoekt indexieren beide Forges.
• Vierteljährlicher Failover‑Game‑Day und dokumentierte Cutover‑Schritte.

Zeit bis zum Exit: 4–8 Stunden, vor allem koordiniertes DNS/URL‑Umschalten und Pipeline‑Umschaltungen.

Level 3: Vollständige Migration (nur wenn nötig)

• Primärsystem wechselt zu selbstgehostetem Forgejo/GitLab CE oder einer gehosteten Alternative (SourceHut, Codeberg, GitLab Cloud).
• GitHub bleibt als read‑only Spiegel für Historienkontinuität und Reichweite im Ökosystem.

Zeitaufwand: 2–6 Wochen mit sorgfältiger Behandlung der Issue/PR‑Historie.

Die Referenzarchitektur: Git, das wie Prod failovert

Forges und Spiegel

• Primär: GitHub (Enterprise empfohlen für SSO, Audit und IP‑Allowlists).
• Sekundär: Forgejo (Community‑geführter Gitea‑Fork), Gitea oder GitLab CE. Für sehr Abenteuerlustige oder OSS‑Anwendungsfälle ergänzend einen Radicle‑Remote für Peer‑to‑Peer‑Replikation.

Mirroring‑Muster:

1. Schützen Sie Ihren Primary‑Branch auf GitHub; nur CI oder Merge Queues dürfen schreiben.
2. Bei Push auf geschützte Branches läuft ein Push‑Mirror‑Job von einem gehärteten Runner, der einen Write‑Only Deploy Key zur sekundären Forge hält. Verwenden Sie git push --mirror für neue Repos und git push --prune für die laufende Synchronisierung.
3. Schließen Sie Secrets und private Git‑Notes aus. Synchronisieren Sie Git LFS explizit via git lfs fetch --all und git lfs push --all.

Kosten: Eine VM mit 4 vCPU/16 GB für Forgejo plus Postgres kostet typischerweise $60–$120/Monat in einer großen Cloud, plus S3‑kompatiblen Storage für Repos/LFS (ca. $0.023/GB‑Monat). Admin‑Zeit ist der eigentliche Kostenfaktor: Rechnen Sie mit 3–5 Stunden/Woche, sobald es stabil ist, für Organisationen mit 50 Engineers und 200–400 Repos.

Identity und Berechtigungen

• Zentralisieren Sie SSO (Okta/Entra/Google) für beide Forges.
• Verwenden Sie kurzlebige Tokens via OIDC für sämtliche Automatisierung; verbannen Sie Personal Access Tokens aus der CI.
• Replizieren Sie Team→Repo‑Berechtigungen zur Sekundär‑Forge via Exporter (GitHub GraphQL) und Importer (Forgejo/GitLab API). Erzeugen Sie täglich ein Diff und alarmieren Sie bei Drift.

CI/CD‑Neutralität

• Behalten Sie GitHub Actions für die Entwickler‑Ergonomie, definieren Sie Pipelines aber portabel:
• Für Build/Test: Spiegeln Sie den Job‑Graph in WoodpeckerCI oder Drone (YAML ist Actions sehr ähnlich), oder nutzen Sie Buildkite, wenn Sie eine gemanagte Control‑Plane mit eigenen Runnern wollen.
• Für K8s‑native Organisationen: Tekton gibt Ihnen volle Kontrolle, erfordert aber mehr Plumbing.
• Credentials: Nutzen Sie von beiden CI‑Systemen OIDC zur Cloud (AWS/GCP/Azure), sodass Secrets identisch sind. Keine langlaufenden Umgebungs‑Secrets; jeder Step erhält frische, eng begrenzte Credentials.
• Artefakt‑Provenance: Signieren Sie Container und Binärdateien mit Sigstore, hängen Sie SLSA‑Provenance an Releases und verifizieren Sie beim Deploy. So wird „Welche Forge hat das gebaut?“ zur Nicht‑Frage.

Issues, PRs und Code Review

Das ist der schwierigste Teil in puncto Portabilität. Wählen Sie ein einziges System of Record für die Zusammenarbeit und spiegeln Sie Metadaten zur Kontinuität.

• System of Record: Belassen Sie Issues/PRs auf GitHub, solange Sie dual‑homen. Im Failover frieren Sie GitHub ein (Org‑weite Schreibrechte aus) und befördern die Sekundär‑Forge auf Read‑Write.
• Mirroring: Nutzen Sie Exporter, um Issues/Labels/Milestones nächtlich auf die Sekundär‑Forge zu synchronisieren. Für Forgejo/GitLab können die Migrationstools die meisten Metadaten importieren; Reviews und PR‑Diskussionen verlieren oft an Detailtreue. Erstellen Sie Snapshots von PRs als statisches HTML auf S3 für rechtliche/archivarische Zwecke.
• Benachrichtigungen: Leiten Sie Webhooks über ein Fan‑out‑Relay (z. B. ein kleiner Service hinter API Gateway/Cloud Run), das an beide CI‑Systeme und Chat weiterleitet, sodass ein Umschalten Automatisierungen nicht bricht.

Suche und Developer Experience

• Code‑Suche: Richten Sie Sourcegraph (self‑hosted oder Cloud) oder Zoekt auf beide Forges. Devs behalten eine Suchleiste – unabhängig davon, welches Remote primär ist.
• Devcontainers und Templates: Halten Sie sie im Repo und provider‑agnostisch. Vermeiden Sie reine Actions‑Composite‑Steps für grundlegende Operationen; kapseln Sie diese in Makefiles oder kleinen Go/Node‑CLIs, die Ihre alternative CI aufrufen kann.

Cutover: So sehen „vier Stunden“ wirklich aus

Wenn Sie Level 2 richtig umgesetzt haben, ist dies Ihr Runbook für ein geplantes oder ungeplantes Cutover.

1. Writes auf GitHub einfrieren. Schalten Sie Org/Repo‑Berechtigungen auf Read‑Only. Kündigen Sie ein 30‑minütiges Brownout an.
2. Sekundär auf Read‑Write befördern. Nehmen Sie Schreibschutz‑Policies dort vorübergehend zurück, wo nötig; bewahren Sie Branch‑Protections.
3. CI/CD umschalten. Pausieren Sie Actions org‑weit, aktivieren Sie Pipelines auf der Sekundär‑Forge (Woodpecker/Buildkite/Tekton). Prüfen Sie, dass Runner verfügbar sind und Autoscaling funktioniert.
4. Remotes in Bulk aktualisieren. Für Monorepos und trunk‑basierte Teams aktualisieren Sie die Origin‑URLs über zentrale Skripte für interne Repos; OSS‑Repos behalten GitHub als Spiegel für die Community.
5. Webhooks und Paket‑Publishing umstellen. Ihr Relay sollte dies zu einem Toggle machen – nicht zu einem Refactoring. Validieren Sie Artefakt‑Signaturen in Staging, dann in Produktion.
6. Überwachen und kommunizieren. Verfolgen Sie Merge‑Queue‑Zeiten, CI‑Dauer, Incident‑Kanäle. Entscheiden Sie binnen 24 Stunden, ob Sie bleiben oder zurückrollen.

Die häufigste Reibung: Entwickler mit langlebigen Feature‑Branches, die nicht gespiegelt wurden, und Sonderwege in Pipelines, die veraltete Actions nutzten. Ein Dry‑Run mit einem Pilotteams spült diese Fälle hoch.

Zahlen, die zählen, wenn Sie das dem CFO vorstellen

• Seat‑Kosten verschwinden nicht. Dual‑Home‑Absicherung dient nicht primär dem Einsparen von Seats. GitHub Enterprise pro Nutzer bleibt für die meisten Teams sinnvoll. Die Absicherung ist eine Versicherungsprämie, kein Ersatz.
• Infrastrukturposten sind moderat. Rechnen Sie mit $150–$400/Monat für die Sekundär‑Forge‑Infra bei 50–100 Engineers, plus $50–$150 für eine kleine Sourcegraph/Zoekt‑Instanz, wenn Sie selbst hosten.
• Time‑to‑Value ist kurz. Teams, die wir unterstützt haben, erreichen Level 2 in 6–10 Wochen mit einem Platform Engineer ~50% allokiert und einem DevOps/SRE ~30% allokiert. Game Days dauern vierteljährlich 2–3 Stunden.
• Die Ausfall‑Rechnung ist brutal. Wenn Ihr gemischter Engineer‑Kostensatz $150/Stunde beträgt und 60 Engineers drei Stunden blockiert sind, sind das $27.000. Ein einziger Incident bezahlt die Absicherungs‑Infra für Jahre.

Fallstricke und wie Sie sie vermeiden

• Git‑LFS‑Überraschungen. Spiegeln Sie LFS explizit und verifizieren Sie, dass die Objektanzahlen auf beiden Seiten übereinstimmen. Viele Teams nehmen an, --mirror beinhalte LFS – tut es nicht.
• Verlust der Review‑Historie. Sie werden PR‑Review‑Threads nicht 1:1 portieren. Archivieren Sie sie (statisches HTML + S3‑Lifecycle) und machen Sie weiter. Lassen Sie GitHub für ein Quartal read‑only, damit Links weiter funktionieren.
• Secret‑Sprawl. Absicherung verdoppelt die Orte, an denen Secrets leaken können – es sei denn, Sie standardisieren auf OIDC und kurzlebige Credentials. Alte Sünden nicht replizieren.
• Drift bei Schatten‑Tools. Halten Sie ein wöchentliches Diff von Repos, Teams und Branch‑Protections zwischen den Forges. Failen Sie bei Drift früh, statt es erst beim Cutover zu entdecken.
• CI über‑abstrahieren. Streben Sie 80% Portabilität an – nicht eine „kleinster gemeinsamer Nenner“‑DSL, die das Team ausbremst. Es ist okay, wenn 20% der Jobs providerspezifisch bleiben.

Was ist mit Radicle und vollständig dezentralem Code?

Radicle (das HardenedBSD nun verwendet) ist überzeugend für Zensurresistenz und Peer‑to‑Peer‑Replikation. Heute ist es für die meisten kommerziellen Teams eine Ergänzung, kein Ersatz:

• Anwendungsfälle: OSS‑Spiegel, Notfallreplikation auf Entwickler‑Maschinen und zusätzliche Absicherung für Kern‑Repos.
• Lücken: Enterprise‑SSO/Berechtigungs‑Reife und PR/Review‑UX im Vergleich zu GitHub/GitLab.

Wenn Sie stark OSS‑getrieben sind oder besondere Souveränitätsanforderungen haben, ist ein zusätzlicher Radicle‑Remote eine günstige Versicherung. Behandeln Sie ihn als dritte Kopie Ihrer kritischsten Repos.

Ein 30–60–90‑Tage‑Plan, den Sie wirklich umsetzen können

Tage 0–30: Schnelle Maßnahmen

• Inventarisieren Sie alle Repos, LFS‑Nutzung, Actions, Runner, Secrets, Webhooks und Pakete.
• Aktivieren Sie Sigstore‑Signaturen in Builds und hängen Sie SLSA‑Provenance an Artefakte.
• Ersetzen Sie CI‑Secrets durch OIDC. Verbannen Sie Personal Access Tokens aus der Automatisierung.
• Richten Sie nächtliche Bare‑Repo‑ + LFS‑Backups nach S3 mit Lifecycle‑Regeln ein.
• Verlagern Sie das Paket‑Publishing in ein neutrales Registry und spiegeln Sie von dort nach GitHub Packages (nicht umgekehrt).

Tage 31–60: Das zweite Zuhause aufbauen

• Stellen Sie Forgejo/GitLab CE mit SSO und teamweisen Berechtigungen bereit.
• Implementieren Sie Push‑Mirror beim Commit für alle geschützten Branches; füllen Sie große Repos offline nach.
• Nehmen Sie Schatten‑CI (Woodpecker/Buildkite/Tekton) in Betrieb. Spiegeln Sie 70–80% der Actions‑Jobs.
• Indexieren Sie beide Forges in Sourcegraph/Zoekt.
• Spiegeln Sie Issues/Labels/Milestones nächtlich; archivieren Sie PR‑Historien wöchentlich nach S3.
• Pilotieren Sie einen Game Day mit einem Product‑Squad und einem nicht‑kritischen Service.

Tage 61–90: Failover beweisen

• Führen Sie einen unternehmensweiten 2‑stündigen Failover‑Game‑Day durch. Messen Sie Time‑to‑Merge und CI‑Stabilität.
• Veröffentlichen Sie ein Cutover‑Runbook mit klaren Ownern und SLAs.
• Automatisieren Sie Drift‑Erkennung (Teams, Repos, Branch‑Protections) und Alarmierung.
• Integrieren Sie den Plan in Vendor Risk‑ und BCP‑Dokumente für Audits und Enterprise‑Kunden.

Wo ein Nearshore‑Partner hilft (und wo Sie keinen brauchen)

Für Sigstore und Backups brauchen Sie keine Hilfe. Unterstützung kann sinnvoll sein, wenn:

• Sie 200+ Repos, mehrere Sprachen und heterogene CI‑Runner haben.
• Sie SOC 2‑Nachweisführung erhalten müssen, während Sie CI/CD und Artefaktflüsse ändern.
• Sie 6–8 Stunden/Tag Überschneidung benötigen, um Migrationsfenster zu fahren, ohne Nächte und Wochenenden zu verbrennen.

Ein erfahrenes Platform‑Team nimmt die kniffligen Teile vorweg: LFS‑Sync, Identity/SSO‑Mapping, Provenance‑Verifikation im Deploy und Dry‑Run‑Failover. Danach ist der Betrieb im Steady State leicht.

Fazit

Ghostty verlässt GitHub, Radicle gewinnt bei gehärteten OS‑Projekten an Fahrt, und GitHubs eigene Incident‑Reports sollten Ihren Blick schärfen – nicht eine Kurzschluss‑Migration auslösen. Die richtige Antwort ist besonnene Resilienz: Nutzen Sie GitHub weiter, wo es glänzt, aber geben Sie sich einen echten Plan B. Sie investieren bereits in Multi‑AZ, Multi‑Region und Runbooks für Prod. Ihre Code‑Plattform verdient denselben Ernst.

Wichtigste Erkenntnisse

• GitHub nicht im Affekt verlassen – absichern. Dual‑homen Sie Code, CI und Artefakte, damit ein Cutover Stunden statt Wochen dauert.
• Provenance schlägt Plattform. Signieren Sie Builds, hängen Sie SLSA an und nutzen Sie OIDC, damit Eigentum und Integrität nicht von einer Forge abhängen.
• Rechnen Sie mit $150–$400/Monat Infra für eine Sekundär‑Forge bei 50–100 Engineers; der erste Ausfall bezahlt die Absicherung.
• Am schwierigsten sind Issues/PRs. Spiegeln Sie, was geht, archivieren Sie den Rest und halten Sie GitHub read‑only für die Kontinuität.
• Führen Sie vierteljährlich einen Failover‑Game‑Day durch. Wenn Sie Ihren Exit nie getestet haben, haben Sie keinen.