Ghostty leaves GitHub over reliability

A terminal emulator moving code hosts sounds small. But Ghostty leaving GitHub is really a story about infrastructure trust — the boring layer developers assume will just be there. Mitchell Hashimoto, Ghostty’s creator and a longtime GitHub power user, said on April 28 that he’s moving the project off the platform because GitHub outages have become too frequent to work around. He didn’t frame it as protest theater. He framed it as operational necessity. (mitchellh.com) ### What is Ghostty, exactly? Ghostty is a fast, cross-platform terminal emulator — the window developers use to run shells, tools, builds, and remote sessions. It is not a toy side repo with five stars. Ghostty shipped version 1.3.0 on March 9, with 180 contributors and 2,858 commits represented in that release, which tells you the project is active enough that host reliability actually matters day to day. (ghostty.org) ### Why did Hashimoto finally snap? The key point is that this was not one bad afternoon. Hashimoto said he had spent the last month keeping a journal and marking every day when a GitHub outage hurt his ability to work. “Almost every day” got marked. On the day he wrote the post, he said a GitHub Actions outage had blocked pull-request review for about two hours. His conclusion was blunt: GitHub was (ghostty.org)if it could lock you out for hours per day. (mitchellh.com) ### Was GitHub actually having issues? Yes — and GitHub itself acknowledged that late-April incidents were not acceptable. GitHub published an availability update on April 28 saying it was rethinking scale assumptions, moving from a 10x capacity plan to designing for 30x today’s scale because software activity had changed so quickly. Its incident history shows an Apr(mitchellh.com)aded search and incomplete pull-request results in repositories. (github.blog) ### Why does a code host outage hurt so much? Because GitHub is not just “where the code lives.” A pull request touches storage, permissions, search, notifications, merge checks, Actions, webhooks, APIs, and more. GitHub basically said this out loud in its own availability post. So when one dependency slows down, the failure can spread sidew(github.blog)trusting what they see. (github.blog) ### Why is this more than one maintainer’s frustration? Hashimoto is not some casual user rage-posting after a timeout. He said he joined GitHub in February 2008 as user 1299 and had opened the site every day for more than 18 years. That makes the post land differently. He is describing a platform he loved and built on for most of his career(github.blog)perator changing vendors after too many incidents. (mitchellh.com) ### What’s the hidden lesson for other teams? The real lesson is dependency mapping. A lot of teams think “we use GitHub” means repository hosting. But they also use GitHub for issue triage, release artifacts, CI triggers, branch protections, package publishing, discussion history, and contributor identity. That stack is like a fuse box wired behind the wall — you ig(mitchellh.com)wn write-up talks about hidden coupling and blast radius, which is basically the same warning in platform language. (github.blog) ### Does this mean GitHub is doomed? No. GitHub’s status page now shows systems operational, and the company says reliability is the priority over new features. But the interesting shift is cultural: a prominent open-source maintainer decided recent instability was enough to move a real project, not just complain. Once maintainers start trea(github.blog)lives on GitHub forever” assumption gets weaker. (us.githubstatus.com) ### Bottom line Ghostty leaving GitHub matters because it turns uptime into strategy. If your toolchain depends on one platform for code, CI, review, and release flow, that platform is part of your product whether you admit it or not. (mitchellh.com)