On April 28, 2026, Mitchell Hashimoto dropped a blog post that broke developer Twitter for the day: Ghostty is leaving GitHub. If you use the terminal, contribute to the project, or just maintain repos elsewhere on GitHub, this matters – but probably not in the way the hot takes are framing it.
The news isn’t really about one terminal emulator. It’s about the fact that a creator of Vagrant, Terraform, and Vault – someone whose entire career lived on GitHub for 18 years – finally said the platform isn’t reliable enough for serious work. That’s a signal worth following, whether you stay on GitHub or not.
Here’s what’s actually happening, what changes for you as a Ghostty user, and how to migrate your own repos if this pushed you over the edge.
What changed (and what didn’t)
Ghostty’s GitHub repo is leaving – eventually. Hashimoto wrote the announcement over a week before publishing, and made the final decision the same week. His personal projects stay on GitHub for now; only Ghostty is moving, because that’s where the maintainers and contributors are most affected.
The destination? Not announced. Hashimoto’s exact words: “We’ll see where it goes after that.” Every article speculating about Codeberg, Forgejo, sourcehut, or self-hosted is guessing. As of this writing, there’s no public migration date and no new URL.
For end users, this is the practical truth:
- Ghostty itself doesn’t change. The terminal still installs the same way. Current version is 1.3.1 (as of April 2026), macOS 13+.
- Downloads still live at ghostty.org/download – the website is the source of truth, not the GitHub repo.
- If you opened issues or PRs on GitHub, they’ll need to be re-opened wherever the project lands.
- If you starred the repo, that signal is gone the moment it migrates. Bookmark the docs site instead.
Why this isn’t just drama
The community reaction on Hacker News and Lobsters has been split between “finally” and “isn’t this overreacting?” Both miss the point. Hashimoto kept a literal journal for a month marking every day a GitHub outage blocked his work – almost every day had an X, and on the day he wrote the post, Actions was down for two hours blocking PR review.
That’s not vibes. That’s a measurable reliability problem on the critical path of an open-source project maintained by real people with deadlines.
The interesting part of Mitchell’s post isn’t the goodbye – it’s the diagnosis. He’s not mad about Microsoft, Copilot, or AI priorities. He’s mad that the boring infrastructure stopped working. That’s a different complaint, and a harder one to dismiss.
The Ghostty user gotcha nobody is talking about
If you run Ghostty on Linux, you have a problem that predates this announcement. OpenSUSE, Debian, and Ubuntu have already dropped Ghostty from their repos – newer Zig and dependency requirements weren’t being maintained, and nobody stepped up to fix it. This is documented in GitHub discussion #10162.
Per the Ghostty team, Linux packaging has always been third-party best-effort. The only package they build and sign themselves is the macOS .dmg. The repo move makes this slightly worse: distro packagers now also need to retool their automation against whatever new git host comes next.
Practical fix if your distro dropped Ghostty: build from source, or check the issue tracker for Flatpak progress. On macOS, the signed binary from ghostty.org/download remains the cleanest path.
How to migrate your own repos to Codeberg (the realistic version)
If Hashimoto’s post made you want to do the same thing, good news: it’s mechanical. Bad news: there are three traps that will eat half a day if you don’t know about them.
Codeberg is the most common landing spot people consider after GitHub. It’s run by a non-profit foundation on the open-source Forgejo platform, EU-based, and you can self-host components like runners. Here’s the actual workflow:
Step 1: Import the repo
On codeberg.org, click + → New Migration → GitHub. Codeberg’s built-in GitHub importer handles repository contents plus issues and PRs, preserving issue numbers, labels, and authorship. Paste your GitHub token, choose what to migrate, done.
Step 2: Apply for Actions access (do this first, it takes hours)
Here’s the gotcha most guides bury at the bottom. Codeberg doesn’t grant CI to every account by default. You apply at codeberg.org/Codeberg-e.V./requests and wait for manual approval – even if you bring your own runner. Then you have to enable Actions per-repository under Settings → Units.
Start this on day one of your migration. If you wait until you’ve copied everything over, you’ll sit there with broken builds.
Step 3: Translate your workflows
Forgejo Actions YAML is nearly identical to GitHub Actions, and most of the existing actions ecosystem works as-is. The one syntax change you’ll hit constantly: action references need full URLs.
# GitHub Actions
uses: dtolnay/rust-toolchain@stable
# Forgejo Actions on Codeberg
uses: https://github.com/dtolnay/rust-toolchain@stable
That’s it. Copy your .github/workflows folder to .forgejo/workflows, find-and-replace the uses: lines, push.
Step 4: Fix release tooling
If you use goreleaser, it’ll silently misbehave. Forgejo Actions still injects a GITHUB_TOKEN env var – but goreleaser needs GITEA_TOKEN to talk to Codeberg’s API. Add this to your release workflow:
env:
GORELEASER_FORCE_TOKEN: gitea
GITEA_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Step 5: Decide what to do with the old GitHub repo
Three options: archive it (read-only, with a README pointing to Codeberg), set up a Codeberg → GitHub mirror push (people can still file issues you’ll have to close), or delete. Most maintainers archive – it preserves star history and search visibility without inviting confusion.
The macOS runner trap
One real limitation, stated upfront because no migration guide should hide it: Codeberg has no free macOS runners. GitHub offered free macOS CI for public repos – that’s gone the moment you leave.
Pro tip: If you ship Mac binaries and can’t self-host Mac hardware, the cleanest workaround is to keep a thin GitHub mirror just for Mac CI: push commits to both, run macOS Actions on GitHub, and use a Forgejo Action on Codeberg to poll the GitHub API and sync build status back. Ugly, but it works – and it lets you migrate everything else now without blocking on the Mac problem.
Should you actually do this?
Honest answer: probably not yet, unless GitHub Actions outages are actively costing you time, or you have ideological reasons – EU hosting, non-profit governance, discomfort with platform consolidation. All valid reasons. Just be clear-eyed that they’re your reasons, not everyone’s.
For most solo devs, the friction of migration is bigger than the friction of GitHub’s bad days. A simpler hedge: mirror your important repos to Codeberg as a backup. That’s a one-command setup and gives you a working fallback the next time GitHub Actions goes down for two hours.
The Ghostty move is interesting because of who is doing it, not because everyone needs to copy them. When the person who built Vagrant on GitHub starts moving off GitHub, that’s a leading indicator worth watching. See where Ghostty actually lands – that decision will tell you more than any blog post.
FAQ
Where is Ghostty moving to?
Not announced. Mitchell explicitly said “we’ll see” – anyone telling you it’s Codeberg or sourcehut or self-hosted is guessing. Watch ghostty.org for the official update.
Will my Ghostty config or installation break?
No. The terminal binary, the config file at ~/.config/ghostty/config, and the download page at ghostty.org are all unaffected by where the source code is hosted. The only people impacted right now are contributors with open PRs and anyone who relied on the GitHub issue tracker – those workflows will need a new home once the project moves. If you installed via Homebrew (brew install --cask ghostty), updates keep flowing through the cask regardless of the upstream repo location.
Is Codeberg actually ready for serious projects?
For code hosting, issues, and PRs – yes, the experience is close enough to GitHub that muscle memory mostly carries over. For CI, it’s rougher. You apply for Actions access, you might self-host runners, you give up free macOS builds. Plenty of medium-sized open-source projects run there happily, but expect a weekend of plumbing work, not an afternoon.
Next step: If you want to hedge, set up a Codeberg account today and use Forgejo’s GitHub importer on one low-stakes repo. You’ll learn the entire workflow in 30 minutes, and you’ll have a working backup the next time GitHub Actions falls over for two hours.