Am 28. April 2026 kündigte Mitchell Hashimoto an, dass Ghostty, sein Open-Source-Terminal-Emulator, GitHub verlassen wird. Hashimoto ist GitHub-Benutzer 1299, seit Februar 2008 dabei und hat die Plattform über 18 Jahre fast täglich genutzt. Trotzdem reichte die Zuverlässigkeit für ihn nicht mehr aus: Er führte ein persönliches Ausfall-Tagebuch, in dem „fast jeder Tag ein X hat“, und am Tag der Ankündigung blockierte ein GitHub-Actions-Ausfall seine PR-Reviews für zwei Stunden.
Apidog noch heute ausprobieren
Wenn Sie Entwickler-Tools bauen, sollten Sie diese Ankündigung nicht als reine Forge-Migration lesen. Hashimoto hat HashiCorp auf GitHub mitbegründet und Projekte wie Terraform, Vagrant, Vault, Consul und Boundary dort veröffentlicht. Wenn ein Nutzer mit diesem Profil GitHub aus Zuverlässigkeitsgründen verlässt, ist das ein Signal für jedes Team, dessen Produkt im kritischen Pfad anderer Entwickler liegt.
Für den breiteren Kontext zu GitHub-nativen Workflows in der KI-Ära siehe wie man AGENTS.md-Dateien schreibt, GitHub Copilot-Nutzung und Abrechnungs-API für Teams und den Clawsweeper Triage-Bot-Bericht.
TL;DR
- Mitchell Hashimoto kündigte am 28. April 2026 an, dass Ghostty GitHub zugunsten einer noch unbenannten Forge verlassen wird.
- Der Grund ist nicht Preis, Politik oder Feature-Strategie, sondern wiederholte Ausfälle von GitHub Actions und der Plattform.
- Ghostty bleibt als schreibgeschütztes Mirror auf GitHub; Issues, Pull Requests und CI sollen schrittweise migrieren.
- Die zentrale Lektion: Wenn Ihr Tool im kritischen Pfad anderer Entwickler liegt, schlägt Zuverlässigkeit jedes Feature.
- Lock-in entsteht nicht nur durch Git-Repositories, sondern durch Issues, PR-Historie, CI, Secrets, Releases, Packages und Identität.
- API-Teams sollten Abhängigkeiten mocken, Anbieter austauschbar machen und Release-Pipelines nicht vollständig an eine Plattform koppeln.
- Apidog folgt genau diesem Muster: API-Schemas, Mock-Server, Umgebungen und Tests werden so aufgebaut, dass Teams auch bei Upstream-Ausfällen weiterarbeiten können.
Was Hashimoto konkret angekündigt hat
Die Ankündigung ist kurz und technisch nüchtern:
- Hashimoto führte über Monate ein Tagebuch über GitHub-Ausfälle.
- Das Muster wurde häufiger, als er erwartet hatte.
- Am Morgen der Ankündigung blockierte ein GitHub-Actions-Ausfall seine PR-Reviews für zwei Stunden.
- Er entschied, dass GitHub für die aktive Ghostty-Entwicklung nicht mehr zuverlässig genug ist.
Wichtig: Er beschreibt die Migration nicht als Reaktion auf einen einzelnen schlechten Tag. Der Ausfall am 27. April 2026 beeinflusste den Zeitpunkt, nicht die Entscheidung.
Der aktuelle Stand:
- Das Ghostty-Repository auf GitHub bleibt als schreibgeschütztes Mirror bestehen.
- Die aktive Entwicklung soll auf eine neue Forge umziehen.
- Issues, Pull Requests und CI werden dort weitergeführt.
- Hashimoto spricht mit mehreren kommerziellen und FOSS-Anbietern.
- Seine anderen Projekte bleiben vorerst auf GitHub.
Die entscheidende Auslassung: Es geht nicht um Features. Es geht um Verfügbarkeit.
Warum das für Entwickler-Tools relevant ist
Wenn Sie ein Entwickler-Tool betreiben, ist Hashimotos Beitrag ein praktischer Testfall:
Würden Ihre Power-User ebenfalls ein Tagebuch führen, in dem fast jeder Arbeitstag einen Ausfall oder eine Einschränkung enthält?
Das Problem ist nicht nur absolute Uptime. Für Entwickler zählt, ob das Tool genau dann funktioniert, wenn sie es brauchen:
- während eines PR-Reviews
- während eines Releases
- während eines Incident-Fixes
- während einer CI-Pipeline
- während eines Kundendemos
- während eines Deployments
Eine Plattform kann insgesamt gute Verfügbarkeitszahlen haben und trotzdem für bestimmte Workflows unzuverlässig wirken, wenn die Ausfälle regelmäßig in kritische Arbeitsfenster fallen.
Vier Fragen für Ihr eigenes Produkt
1. Wie viele Stunden verlieren Ihre wichtigsten Nutzer wirklich?
Ziehen Sie nicht nur Ihre Statuspage-Daten. Erfassen Sie auch:
- degradierte Latenzen
- verzögerte Queues
- teilweise API-Ausfälle
- CI-Timeouts
- Webhook-Verzögerungen
- bekannte interne Incidents ohne öffentliche Meldung
Ordnen Sie diese Daten den Arbeitszeiten Ihrer wichtigsten Kunden zu.
Beispielhafte Auswertung:
Zeitraum: letzte 90 Tage
Kunde: Top-20-Kunden nach Nutzung
Metrik: blockierte Entwicklerstunden
Incident A: 2h während EU-Arbeitszeit
Incident B: 45min während US-West-Coast-Releasefenster
Incident C: 30min Webhook-Verzögerung während CI-Peak
Ergebnis:
- 7 von 20 Top-Kunden betroffen
- 14 geschätzte blockierte Entwicklerstunden
- 3 wiederkehrende Komponenten: CI, Webhooks, Auth
Wenn Power-User wöchentlich blockiert werden, ist Ihr Produkt bereits auf einer gefährlichen Kurve.
2. Messen Sie die zweite Ableitung Ihrer Zuverlässigkeit?
Ein einzelner Ausfall ist ärgerlich. Ein Trend ist gefährlich.
Messen Sie pro Komponente:
Komponente Incidents März Incidents April Trend
CI Runner 2 5 steigend
API Gateway 1 1 stabil
Webhook Queue 3 6 steigend
Auth 0 2 steigend
Wenn Ihre Gesamt-SLA noch gut aussieht, aber einzelne kritische Komponenten schlechter werden, sehen Ihre Nutzer den Trend vor Ihrem Dashboard.
3. Ist Ihre Statuspage ehrlicher als der Slack Ihrer Kunden?
Nutzer führen eigene Ausfall-Tagebücher, wenn sie dem offiziellen Signal nicht vertrauen.
Veröffentlichen Sie früh und granular:
- Region betroffen?
- API-Endpunkt betroffen?
- Webhooks verzögert?
- Queue im Rückstand?
- CI-Runners limitiert?
- Auth teilweise gestört?
Eine Statuspage sollte nicht erst rot werden, wenn alles ausfällt.
4. Sind Sie zuverlässig für echte Arbeit oder nur für Demos?
Demos testen Happy Paths. Produktionsworkflows testen Abhängigkeiten.
Beispiel:
Demo:
- Ein Request
- Kleine Nutzlast
- Einzelner Nutzer
- Keine parallelen Jobs
- Keine Abhängigkeit von Webhooks
Echter Workflow:
- 200 Requests
- parallele CI-Jobs
- Secrets
- Webhooks
- externe APIs
- Retry-Logik
- Rate Limits
Messen Sie die Verfügbarkeit an echten Nutzungskurven, nicht an synthetischen Smoke Tests allein.
Lock-in ist größer als Git
Viele Teams unterschätzen, wie viel GitHub neben Git übernimmt:
- Repository-Hosting
- Issues
- Pull Requests
- Review-Historie
- GitHub Actions
- Secrets
- Releases
- Packages
- CODEOWNERS
- Discussions
- OAuth
- Marketplace
- Webhooks
- Automatisierungen
Ein Repository können Sie klonen:
git clone --mirror git@github.com:org/project.git
git push --mirror git@gitlab.com:org/project.git
Aber damit migrieren Sie nicht:
- offene Issues
- Kommentare
- PR-Diskussionen
- Review-Zustände
- CI-Secrets
- GitHub-Actions-spezifische Workflows
- Release-Artefakte
- Paket-Registries
- OAuth-Integrationen
Der Lock-in steckt in den Workflows, nicht nur im Code.
Praktischer Schutz: Repositories spiegeln
Ein einfacher erster Schritt ist ein regelmäßiges Mirror auf eine zweite Forge.
Beispiel mit GitHub Actions:
name: Mirror repository
on:
schedule:
- cron: "0 2 * * *"
workflow_dispatch:
jobs:
mirror:
runs-on: ubuntu-latest
steps:
- name: Clone mirror
run: |
git clone --mirror https://github.com/YOUR_ORG/YOUR_REPO.git repo.git
- name: Push to secondary forge
run: |
cd repo.git
git push --mirror https://oauth2:${{ secrets.SECONDARY_FORGE_TOKEN }}@gitlab.com/YOUR_ORG/YOUR_REPO.git
Das löst nicht alle Migrationsprobleme, aber es reduziert das Risiko, dass Ihr Code nur auf einer Plattform verfügbar ist.
Für FOSS-Projekte sind Forgejo, Codeberg oder GitLab häufige Ziele. Entscheidend ist nicht die perfekte Alternative, sondern ein getesteter Fallback.
Adapter statt harte GitHub-Abhängigkeit
Wenn Ihr Tool GitHub-APIs nutzt, kapseln Sie die Plattform hinter einem Interface.
Beispiel in TypeScript:
export interface ForgeClient {
getPullRequest(repo: string, id: number): Promise<PullRequest>;
listChangedFiles(repo: string, id: number): Promise<FileChange[]>;
createComment(repo: string, id: number, body: string): Promise<void>;
}
GitHub-Implementierung:
export class GitHubClient implements ForgeClient {
constructor(private token: string) {}
async getPullRequest(repo: string, id: number) {
// GitHub REST oder GraphQL API
}
async listChangedFiles(repo: string, id: number) {
// GitHub-spezifischer Endpoint
}
async createComment(repo: string, id: number, body: string) {
// GitHub Review Comment API
}
}
Später können Sie einen zweiten Adapter ergänzen:
export class GitLabClient implements ForgeClient {
constructor(private token: string) {}
async getPullRequest(repo: string, id: number) {
// GitLab Merge Request API
}
async listChangedFiles(repo: string, id: number) {
// GitLab Changes API
}
async createComment(repo: string, id: number, body: string) {
// GitLab Notes API
}
}
Der wichtigste Punkt: Ihre Businesslogik darf nicht direkt von GitHub-spezifischen Objekten abhängen.
Forge-Alternativen kurz eingeordnet
Hashimoto hat kein Ziel genannt. Die plausiblen Optionen unterscheiden sich stark:
- Forgejo: FOSS, Fork von Gitea, stark für selbstbestimmte Open-Source-Projekte.
- Codeberg: gehostete Forgejo-Instanz, gemeinnützig, attraktiv für Open Source.
- GitLab: starke CI/CD-Funktionen, kommerziell etabliert, großer Funktionsumfang.
- Sourcehut: minimalistischer, E-Mail-orientierter Workflow.
- Selbstgehostetes Forgejo oder Gitea: maximale Kontrolle, aber eigene Betriebsverantwortung.
- Radicle: Peer-to-Peer-Ansatz, spannend für Föderation, aber für viele Projekte noch früh.
Die praktische Erkenntnis: Es gibt selten einen 1:1-Ersatz für alles, was GitHub abdeckt. Deshalb sollte Migration inkrementell geplant werden.
Was API-Teams daraus lernen sollten
Für API-Teams ist GitHub nur ein Beispiel für eine externe Abhängigkeit. Ersetzen Sie „GitHub Actions“ durch:
- Payment Provider
- LLM Provider
- Auth Provider
- Search API
- Cloud Storage
- Message Queue
- CRM API
- internes Plattform-Team
Die Kernfrage bleibt:
Kann Ihr Team weiterentwickeln, testen und releasen, wenn eine kritische Upstream-API ausfällt?
Drei Muster helfen sofort.
Muster 1: Jede Upstream-API mocken
Wenn eine externe API ausfällt, sollten lokale Entwicklung und CI nicht blockieren.
Minimaler Mock mit Node.js und Express:
import express from "express";
const app = express();
app.use(express.json());
app.post("/v1/chat/completions", (req, res) => {
res.json({
id: "mock-chatcmpl-123",
object: "chat.completion",
choices: [
{
index: 0,
message: {
role: "assistant",
content: "Mock-Antwort für lokale Tests"
},
finish_reason: "stop"
}
]
});
});
app.listen(3001, () => {
console.log("Mock API läuft auf http://localhost:3001");
});
Dann konfigurieren Sie Ihre App über Umgebungen:
API_BASE_URL=http://localhost:3001
API_KEY=mock-key
Apidog bietet diesen Workflow als Produktfunktion: Dieselben API-Definitionen, die Sie für Tests und Dokumentation verwenden, können auch Mock-Server erzeugen. Ein praktisches Multi-Provider-Beispiel finden Sie im Beitrag wie man die GPT-5.5 API verwendet.
Muster 2: Provider austauschbar machen
Wenn Ihr Produkt LLMs, Zahlungsanbieter oder andere APIs nutzt, bauen Sie einen Provider-Layer.
Beispiel:
export interface LlmProvider {
complete(input: string): Promise<string>;
}
Implementierung A:
export class OpenAIProvider implements LlmProvider {
async complete(input: string): Promise<string> {
// Request an OpenAI-kompatiblen Endpoint
return "Antwort von Provider A";
}
}
Implementierung B:
export class BackupProvider implements LlmProvider {
async complete(input: string): Promise<string> {
// Request an Backup-Provider
return "Antwort von Provider B";
}
}
Failover-Logik:
export async function completeWithFallback(
primary: LlmProvider,
backup: LlmProvider,
input: string
): Promise<string> {
try {
return await primary.complete(input);
} catch (error) {
console.warn("Primary Provider fehlgeschlagen, nutze Backup", error);
return backup.complete(input);
}
}
In Apidog können Sie solche Varianten über Umgebungen abbilden:
dev -> Mock Server
staging -> Sandbox Provider
prod -> Primary Provider
backup -> Secondary Provider
Der Wechsel ist dann Konfiguration, nicht Code-Operation.
Muster 3: Release-Pipeline entkoppeln
Wenn Ihre Releases nur über GitHub Actions laufen, ist GitHub Actions ein Single Point of Failure.
Mindestens für kritische Releases sollten Sie einen zweiten Pfad haben:
Primär:
GitHub Actions -> Build -> Test -> Release
Fallback:
Self-hosted Runner oder zweite CI -> Build -> Test -> Release
Dokumentieren Sie den manuellen Pfad:
# 1. Tag lokal prüfen
git fetch --tags
git checkout v1.2.3
# 2. Build ausführen
npm ci
npm run build
npm test
# 3. Artefakt erzeugen
npm pack
# 4. Veröffentlichung über alternativen Token
npm publish --access public
Wenn dieser Ablauf nicht getestet ist, existiert er nicht.
Ein robuster Apidog-Workflow für API-Teams
Ein konkreter Workflow sieht so aus:
- Apidog herunterladen.
- Pro externer API ein Projekt anlegen.
- Request- und Response-Schemas definieren.
- Mock-Server aus den Schemas erzeugen.
- Umgebungen für
dev,staging,produndbackupkonfigurieren. - Secrets pro Umgebung speichern.
- Vertragstests schreiben.
- Tests gegen Mock, Sandbox und Live-API ausführen.
- Bei Upstream-Ausfällen auf Mock oder Backup-Provider wechseln.
- Den Fallback regelmäßig im Team üben.
Beispielhafte Umgebungsstruktur:
Environment: dev
BASE_URL=https://mock.apidog.local
API_KEY=mock
Environment: staging
BASE_URL=https://sandbox.provider.example
API_KEY={{STAGING_SECRET}}
Environment: prod
BASE_URL=https://api.provider.example
API_KEY={{PROD_SECRET}}
Environment: backup
BASE_URL=https://api.backup-provider.example
API_KEY={{BACKUP_SECRET}}
Dieses Muster ist nicht Ghostty-spezifisch. Es ist ein allgemeines Robustheitsmuster für Teams, deren Arbeit von Drittanbieter-APIs abhängt.
Praktische Checkliste für Ihren Stack
Nutzen Sie Hashimotos Ankündigung als Anlass für ein internes Reliability-Review.
Repository und Forge
- [ ] Aktive Repositories werden regelmäßig auf eine zweite Forge gespiegelt.
- [ ] Der Mirror wurde mindestens einmal für einen Restore getestet.
- [ ] Issues und PRs haben einen Export- oder Archivierungsplan.
- [ ] Release-Artefakte liegen nicht nur bei einem Anbieter.
- [ ] CI-Secrets sind dokumentiert und wiederherstellbar.
CI/CD
- [ ] Kritische Releases haben einen Fallback-Pfad.
- [ ] Mindestens ein Build kann außerhalb von GitHub Actions laufen.
- [ ] Der manuelle Release-Prozess ist dokumentiert.
- [ ] Der Fallback wurde in den letzten 90 Tagen getestet.
API-Abhängigkeiten
- [ ] Jede externe API hat einen Mock.
- [ ] Vertragstests laufen gegen Mock und Live-API.
- [ ] Provider-spezifischer Code ist hinter Interfaces gekapselt.
- [ ] Timeouts und Retries sind explizit konfiguriert.
- [ ] Rate-Limit- und Ausfallverhalten sind getestet.
Kommunikation
- [ ] Ihre Statuspage zeigt Teilstörungen, nicht nur Totalausfälle.
- [ ] Kunden sehen betroffene Komponenten.
- [ ] Incidents enthalten Zeitlinie, Ursache und Follow-up.
- [ ] Interne bekannte Degradierungen werden nicht verschwiegen.
Ein weiteres konkretes Beispiel für robuste API-Workflows mit mehreren Anbietern finden Sie im Beitrag über den Aufbau robuster Workflows, die Anbieter-Ausfälle überleben.
FAQ
Wohin zieht Ghostty um?
Hashimoto hat in der Ankündigung kein Ziel genannt. Er sagte, dass Gespräche mit mehreren kommerziellen und FOSS-Anbietern laufen. Die Migration soll inkrementell erfolgen. Das aktuelle GitHub-Repository bleibt als schreibgeschütztes Mirror bestehen.
Ist GitHub wirklich so unzuverlässig?
GitHub hat weiterhin wettbewerbsfähige Verfügbarkeitszahlen. Hashimotos Punkt ist jedoch nicht nur die Gesamt-Uptime, sondern das Muster wiederholter Teilstörungen, insbesondere bei Actions und Plattformfunktionen, die aktive Entwicklung blockieren.
Sollte ich meine Repositories sofort von GitHub entfernen?
Für die meisten Teams: nein. Aber Sie sollten spiegeln. Ein regelmäßiger Mirror auf eine zweite Forge ist billig, reversibel und reduziert Risiko. Ob Sie die zweite Forge primär machen, hängt von Ihren Migrationskosten für Issues, PRs, CI und Releases ab.
Betrifft das GitHub Copilot?
Hashimotos Beitrag erwähnt Copilot nicht explizit. Der unmittelbare Auslöser war ein GitHub-Actions-Ausfall. Wenn Ihr Team Copilot nutzt, finden Sie Details zu Nutzung und Abrechnung in GitHub Copilot-Nutzung und Abrechnungs-API für Teams.
Was bedeutet das für Tools, die GitHub-APIs nutzen?
Review-Bots, Issue-Triage-Tools, MCP-Server und ähnliche Integrationen erben einen Teil des GitHub-Zuverlässigkeitsprofils. Sie sollten cachen, degraded modes unterstützen und GitHub in Tests mocken. Der Clawsweeper Triage-Bot-Bericht zeigt ein praktisches Beispiel.
Ist das der Beginn eines „GitHub verlassen“-Trends?
Wahrscheinlich langsam, nicht abrupt. Nicht-triviale Migrationen sind aufwendig. Das Signal ist trotzdem wichtig: Einer der langjährigsten GitHub-Nutzer hält die Migrationskosten inzwischen für geringer als die Kosten wiederholter Blockaden.
Was ist die wichtigste technische Lektion?
Behandeln Sie jede externe Plattform als austauschbare Abhängigkeit. Spiegeln Sie Code, mocken Sie APIs, kapseln Sie Provider hinter Interfaces, testen Sie Fallbacks und dokumentieren Sie manuelle Pfade, bevor Sie sie brauchen.
Top comments (0)