Mitchell Hashimoto — the original creator of Vagrant, Packer, Terraform, and now Ghostty, the modern terminal emulator that’s been getting a lot of attention since its 1.0 release last year — published a post on Monday saying Ghostty is leaving GitHub. Not the soft rebrand kind of leaving where the project just adds a mirror somewhere. The actual leaving — primary repo, issues, releases, the whole flow — moving off to a yet-to-be-finalized host, with GitHub kept around only as a read-only mirror.
His stated reason, in plain language: GitHub’s reliability has gotten bad enough that he can’t reliably ship work. He keeps a journal where he marks an X next to every date a GitHub outage cost him productive time, and the journal is dense. Eighteen years on the platform, and the answer he arrived at this month is that the cost of staying outweighs the cost of leaving — even though leaving means rebuilding workflows, integrations, and a community he largely grew there.
This is the kind of announcement that produces a thousand “I’ve been saying this for years” replies, which makes it tempting to dismiss as one prominent person’s frustration finally cresting. But there are a few things in the post worth taking seriously, even if you’re not personally moving anywhere.
The “GitHub is the internet” assumption is fraying
For roughly a decade, the implicit deal in open source has been: put your code on GitHub, get a discoverable URL, network effects, free CI minutes, and a contributor pipeline. The platform’s centrality made it functionally infrastructure, not a product. You don’t usually evaluate whether to be on the internet; you just are. Hashimoto’s post is, in effect, a re-evaluation of that posture.
The numbers backing him aren’t subtle. GitHub’s status page shows multi-incident days every week, sometimes touching nine or ten subsystems at once. Actions degrades. Pull-request UI lags. Pages goes down. The cumulative effect, especially during transitions like the Microsoft-Copilot integration push and the recent agent-features rollout, is that the platform’s reliability has trended in the wrong direction at exactly the moment it’s added the most surface area. If you’re a one-person OSS maintainer, that’s an annoyance. If you’re trying to ship a release across a dozen contributors on three continents, it’s a real cost.
Where do projects actually go?
The honest answer, in 2026, is that the alternatives aren’t a single drop-in replacement. They’re a small constellation of options, each with tradeoffs:
- Codeberg. Gitea-based, donation-funded, EU-based, no commercial owner. Reliable. Discoverability is a fraction of GitHub’s. Good for projects whose audience finds them through other channels (a website, a blog, a podcast).
- sr.ht (sourcehut). Email-based workflow, no JavaScript-required UI, self-hosted CI. Strong opinion about how software should be developed; that opinion either deeply resonates with you or it does not.
- Self-hosted Forgejo / Gitea. The “I run my own forge” path. Cheap, full sovereignty, maximum operational responsibility. Realistic only if the project’s commit volume is modest and the maintainer is operationally inclined.
- GitLab (the SaaS, not the on-prem CE). Mature, full-featured, slightly less central than GitHub. Has its own reliability arc — better than it was two years ago, still not perfect.
- A custom setup — Hashimoto hints in his post that Ghostty may end up here, with multiple parties bidding to host. Most projects don’t have that bargaining position.
None of these are GitHub, in the platform-everyone-already-has-an-account-on sense. That’s the part that makes leaving expensive. You’re trading a network-effects property for an operational property. For a project the size and following of Ghostty, the trade is rational. For most repos, it’s not — yet.
What this should make you think about this week
- Audit your own GitHub-blast-radius. If GitHub goes down for two hours, what stops? CI? Container builds? Your customers’ deploys? Your secrets manager? The answer for most teams is “more than I’d like.” A simple table of “GitHub-dependency / fallback / acceptable-degradation” is a useful artifact even if you never act on it.
- Make sure your code has a second copy that’s not theirs. A nightly mirror to Codeberg or to a self-hosted Gitea is fifteen minutes to set up and gives you a real escape hatch. Most maintainers I know who’ve lived through a GitHub policy change say the same thing afterwards: they wish they’d done this earlier.
- Watch the issue-tracker question separately from the code question. Code is fungible (a git remote add is one command). Issue history, releases, discussions, stars are not. That’s the harder migration, and it’s where Hashimoto’s “incremental” timeline comes from. If your project has a long discussion thread in issues, that’s the thing you should think about preserving first.
- Don’t follow the Hashimotos prematurely. If your project doesn’t have a discoverable audience outside GitHub, leaving prematurely costs you contributors. Wait until your audience finds you through other channels (your blog, your tag, your conference talk), then move. Until then, the read-only mirror pattern is the right cost-benefit.
The bigger arc
One person leaving GitHub is a personal decision. A second wave of high-profile maintainers leaving — and we’ve now seen several this year — is a market signal. GitHub is not in danger of losing its central position, but it is in the early phase of losing the assumption that it’s the only place serious open source happens. Microsoft’s challenge, in this context, is to make the platform feel reliable again before that assumption tips.
Read Hashimoto’s full post for the personal arc and the technical specifics: Ghostty is leaving GitHub. It’s the kind of post that’s worth reading for its texture — eighteen years of using a platform — even more than for its conclusion.
Photo: Code editor with React JSX by Antonio Batinic on Pexels.