Ghostty Is Leaving GitHub

GitHub is so thoroughly identified with open source that leaving it reads as an ideological statement. Mitchell Hashimoto has been GitHub user #1299 since 2008 and built his entire career there. His announcement that Ghostty is moving isn’t about principles — it’s about being blocked from doing PR review for two hours on the day he’s writing the post.

Source

Ghostty Is Leaving GitHub

By: Mitchell Hashimoto
Published: Apr 28 2026
Type: Personal blog post

Worth saving as a documented, non-reactive decision from one of the most GitHub-native maintainers in open source — months of observation with a specific operational failure mode, not a response to a single incident.

When platform reliability becomes an infrastructure decision

Mitchell Hashimoto is GitHub user number 1299, joined February 2008. He opened GitHub every day for over 18 years, multiple times per day, with only a handful of exceptions per year. He built Vagrant specifically hoping it would earn him a job at GitHub. He describes GitHub as the place that has historically made him happiest. His announcement that Ghostty is leaving is not written in the register of principled protest. It reads like someone saying goodbye to something they still love and can no longer use.

The operational argument is specific. For about a month before writing the post, Hashimoto kept a journal with an “X” next to each date where a GitHub outage blocked his work. Almost every date had one. On the day he wrote this post, a GitHub Actions outage prevented PR review for approximately two hours. He addresses the “Git is distributed!” reply in a footnote: the issue isn’t Git, it’s the infrastructure around it — Issues, Pull Requests, Actions, code review. That layer is centralized, and when it fails, the loops teams use to ship software stop.

The distinction worth holding is between an outage that delays work and one that blocks it. Many teams treat platform outages as interruptions they catch up from. For an actively maintained open source project with distributed contributors, CI gates on merges, and a community expecting responsiveness, a two-hour mid-workday outage isn’t something you recover from cleanly. Contributions queue up, CI jobs don’t run or run against stale state, and context fragments across the contributor base. Hashimoto’s framing is that GitHub is “no longer a place for serious work” — not because individual outages are catastrophic, but because their cumulative frequency makes the platform unreliable as a daily work environment.

He’s careful about timing and causation. The post was written more than a week before publication, and the decision to migrate had been building for months before that. The major April 27, 2026 Elasticsearch outage — the widely-reported one — is explicitly not the trigger; a footnote clarifies that was a separate, later incident from the Actions outage he describes. That matters because it rules out the “hot reaction to a high-profile incident” reading and makes this a considered operational call.

The plan preserves continuity: a read-only mirror stays at the current GitHub URL so existing links don’t break, and the migration is incremental because removing Issues, PR history, Actions workflows, and GitHub-specific integrations takes real time. Personal projects and other repositories Hashimoto maintains stay on GitHub for now. Ghostty is the focus because that’s where the active contributor community experiences the reliability failures most directly.

What provider Ghostty is moving to isn’t decided at the time of writing — several commercial and FOSS options are under discussion. That openness is the honest version of the announcement: the decision is to leave, and the destination will be chosen on merit rather than announced before it’s settled. The more durable observation in the post is about accumulated platform dependency. Every GitHub-native integration added over 18 years — Actions workflows, issue templates, PR checks tied to GitHub APIs — was a reasonable choice at the time and becomes migration cost when the platform fails. A project that had stayed platform-agnostic from the start would have a different kind of migration. Whether that theoretical portability is worth the daily friction of avoiding GitHub-specific features is a tradeoff each maintainer makes incrementally; Ghostty is making the cumulative cost visible by paying it.

What I want to remember

Remember: Platform dependency compounds quietly — each GitHub-native integration is reasonable in isolation and becomes migration cost together. When reliability is the failure mode, the bottleneck isn’t conviction to leave but how much of the workflow was locked in before anyone noticed the problem.