GitHub stability crisis and Ghostty leaves — the platform-risk conversation gets sharper

The last week of April 2026 was bad for GitHub. The r/programming “Ghostty Is Leaving GitHub” thread (1,247 upvotes) dropped on April 28. The r/programming “An update on GitHub availability” thread (511 upvotes) — chronicling sustained reliability problems — landed the same day. Two days later, Fireship and Theo both published “GitHub is having major issues” / “Github is Falling Apart” pieces on April 30.

These aren’t unrelated stories. The dependency on GitHub as critical infrastructure for the entire software ecosystem is now visible in a way it wasn’t in March, and one prominent project (Mitchell Hashimoto’s Ghostty terminal) deciding to leave is being read — fairly or not — as a leading indicator.

What happened to GitHub

The reliability problems through April 2026 were structural, not a single outage:

• Intermittent API degradation affecting Git operations, GitHub Actions, and webhook delivery
• Sustained CI/CD slowdowns — Actions workflows queuing for hours during peak periods
• Search and discovery issues — repo search, code search, issue search all degraded at different points
• GraphQL API timeouts during the worst windows, breaking integrations downstream

From GitHub’s status page and the postmortem threads: capacity, scaling, and a series of internal infrastructure issues compounded over weeks. This wasn’t a single-day incident. The cumulative effect through April was an operational degradation that became hard to ignore, especially for teams running CI/CD-heavy workflows on GitHub Actions.

Fireship’s framing is straightforward: GitHub is the substrate that holds the open-source world together. When it wobbles, everything that depends on it wobbles. The systemic risk has always been there; April was the month it was visible.

Why Ghostty leaving matters more than it should

Ghostty is a high-profile, well-maintained open-source terminal emulator. The decision to move off GitHub — announced by Mitchell Hashimoto, who is a credible operator with infrastructure experience — got 1,247 upvotes in r/programming and broad social-media attention.

The reasons cited weren’t primarily reliability — that was the timing, not the cause. The substantive reasons (from the announcement and surrounding discussion):

• Concerns about platform direction: GitHub Copilot training, AI-based search, content surfaces evolving in ways the project didn’t want to be part of
• Vendor concentration risk: hosting on the same platform that Microsoft controls for one of the most-deployed open-source projects in its category
• Desire for governance independence: a project this widely used should not depend on a single commercial platform for canonical source-of-truth

Theo’s “Github is Falling Apart” makes the broader argument: for projects above a certain scale, hosting on GitHub is increasingly an active choice, not a default. The historical “everyone uses GitHub, so we use GitHub” inertia is fraying — slowly, project by project, but visibly.

The credible alternatives

Three patterns for “leaving GitHub” have emerged:

1. Self-hosted Forgejo/Gitea. Lightweight, self-hosted Git forge. Increasingly mature. Forgejo (community-governance fork of Gitea) is the rising default for “OSS project that wants to control its own destiny.” Some homelab/selfhosted users (per the Lempa coverage) have been running Forgejo for years.

2. SourceHut. Drew DeVault’s minimalist, email-based, very-opinionated forge. Strong fit for projects that explicitly reject mainstream developer-experience conventions. Smaller user base; higher friction; very high alignment for projects that want it.

3. Codeberg + Forgejo hosting. Codeberg (non-profit Forgejo host) is positioning as “the public-good alternative to GitHub.” Hosts OSS projects on Forgejo with explicit governance commitments. Increasingly hosting prominent projects.

For Ghostty’s tier of project, Codeberg + self-hosted mirrors is probably where the migration lands. For smaller projects, GitHub still works fine. For very large projects (Linux kernel, Mozilla, Apache Foundation), they were already off GitHub or maintained their own forges.

Creator POV vs Reddit dissent

Fireship’s framing on the GitHub issues video is technically focused — what’s breaking, why, what to do. He doesn’t go anti-GitHub; he treats it as the platform that’s wobbling and needs to recover, not a platform that needs replacing.

Theo’s framing is more critical. His “Github is Falling Apart” video lands the broader systemic argument: GitHub-as-Microsoft-property has accumulated strategic risks (training-data extraction for Copilot, decisions made for Microsoft commercial interests, AI features that some projects don’t want their code in) that are now compounding with the operational risks (uptime, reliability). For projects that take governance seriously, leaving is increasingly defensible.

The r/programming dissent on the Ghostty thread is sharper than usual:

• “Ghostty is signaling, not solving” — leaving GitHub for Codeberg doesn’t eliminate platform risk; it changes which platform you depend on.
• “For most projects this is overreaction” — the GitHub issues will resolve; the long-term hosting decision shouldn’t be driven by a bad month.
• “This is overdue” — counter-position: large-scale projects shouldn’t be hosted on commercial platforms long-term. Ghostty is a useful precedent.

The r/programming GitHub availability thread is more operational and less ideological — focused on what teams need to do to harden their CI/CD against further incidents.

What this means for working engineers

Three concrete actions in late April 2026:

1. Audit your GitHub dependency surface. What breaks when GitHub is down? CI/CD, package registries, internal automation, deploy pipelines, documentation links — list it. The April incidents are a forcing function to know your exposure.

2. Set up mirrors for critical repos. Push canonical Git history to a second forge (Codeberg, self-hosted Gitea, GitLab) for any repo that would be expensive to recover. The cost is low; the disaster recovery posture is meaningfully better.

3. Decouple CI/CD from GitHub Actions where it’s cheap. Workflows that depend on GitHub Actions specifically (rather than portable CI scripts) are harder to rehost. New workflows: write scripts that run identically on Actions, GitLab CI, Jenkins, or self-hosted runners. Existing workflows: don’t migrate reactively, but slowly portabilize.

The honest critique

What this story doesn’t mean:

• GitHub isn’t dying. The platform serves an enormous fraction of the software ecosystem; it has the engineering capability to fix the April issues; Microsoft will continue investing. Predictions of imminent collapse are unserious.
• Most projects shouldn’t leave GitHub. The cost of migration is real; the social cost of being on a less-discoverable forge is real; the operational benefit for small projects is small. Ghostty leaving is signal for Ghostty’s tier, not for the long tail.
• It doesn’t mean self-hosting is the answer. Forgejo, Gitea, SourceHut all require operational maintenance. For most teams, “GitHub but with mirrors” is a better posture than “self-hosted everything.”

But the underlying lesson is durable: the assumption that GitHub is invariant — always there, always working, always aligned with your project’s interests — is increasingly wrong. Working engineers in 2026 need to treat their source-hosting layer the way they treat their cloud provider: a critical dependency, worth thinking about, with a real disaster-recovery story.

For most working engineers in late April 2026: don’t panic, don’t migrate reactively, but do build the optionality — mirrors, portable CI, alternative-forge familiarity. The next incident may be smaller; or it may be larger. Optionality is the cheap insurance.