Ghostty Is Leaving GitHub, and It Won't Be the Last

When Mitchell Hashimoto, the creator of Vagrant, Terraform, and Ghostty, writes a breakup letter, people listen. And on April 28, 2026, he wrote one to GitHub.

It was not a typical technology migration post. It was raw, personal, and devastating.

"I'm GitHub user 1299, joined Feb 2008. Since then, I've opened GitHub every single day. Every day, multiple times per day, for over 18 years. Over half my life."

The post struck a nerve. It hit #1 on Hacker News with over 3,500 upvotes and 1,000 comments. Because Mitchell was not just complaining about downtime. He was grieving a relationship with a platform that had shaped his entire career, and then let him down.

The Journal That Broke Him

The most damning detail was the journal. For a month, Mitchell put an "X" next to every date where a GitHub outage prevented him from working. Nearly every day had one.

"On the day I am writing this post, I've been unable to do any PR review for around 2 hours because there is a GitHub Actions outage. This is no longer a place for serious work if it just blocks you out for hours per day, every day."

Here is the thing: this was not about Git itself. Mitchell was explicit about this. Git is distributed. You can commit offline. The problem is everything else.

Issues. Pull requests. Actions. Projects. Wikis. Code review. All the collaborative infrastructure that turns a Git repo into a development platform. When GitHub goes down, you cannot review PRs, run CI, triage bugs, or merge anything. You are frozen.

For a project like Ghostty, a fast-moving terminal emulator with hundreds of contributors, hours of downtime per day is existential.

The Infrastructure We Forgot We Depend On

Most developers do not think about GitHub as infrastructure. It just works, until it does not.

But over the past year, GitHub reliability has visibly degraded. The platform has grown enormously. AI features like Copilot, Codespaces, and model hosting have been layered on top of a platform originally designed for Git hosting and pull requests. And the cracks are showing.

The pattern is familiar to anyone who has watched platform companies evolve:

1. Growth phase: Ship features fast, reliability is good enough
2. Monetization phase: AI features get priority, core reliability slips
3. Crisis phase: Users start leaving, taking their communities with them

GitHub seems to be somewhere between phase 2 and 3. And Ghostty is the canary.

Where Are Projects Going?

The interesting question is not whether Ghostty leaves. It is where it goes, and what that signals for the rest of us.

Here are the alternatives Mitchell mentioned considering, plus the ones the community is rallying behind:

Self-hosted Forgejo / Gitea

Forgejo (a fork of Gitea) has emerged as the leading self-hosted alternative. It provides issues, pull requests, CI via Actions-compatible runners, and a clean interface. Because it is self-hosted, you control uptime.

The Codeberg platform runs Forgejo and has seen a surge of new projects since the GitHub exodus began. Notable projects like Forgejo itself, and several Linux distributions, already host there.

# Deploy Forgejo with Docker in 5 minutes
docker run -d \
  --name forgejo \
  -p 3000:3000 \
  -p 2222:22 \
  -v forgejo-data:/data \
  codeberg.org/forgejo/forgejo:9

GitLab (self-hosted or SaaS)

GitLab is the incumbent alternative. It has feature parity with GitHub on most fronts, and its CI/CD pipeline is arguably superior. The self-hosted Community Edition is free.

The downside: GitLab.com has its own reliability issues, and the self-hosted version requires maintenance. For a project the size of Ghostty, that might be worth it.

SourceHut

Drew DeVault's SourceHut takes a fundamentally different approach: email-based patches instead of pull requests, a minimal web UI, and a focus on performance. It is the opposite of GitHub in philosophy. Small, fast, and intentionally bare.

For projects that prefer the Linux kernel-style workflow, SourceHut is excellent. For projects that rely on GitHub's social features, it is a harder sell.

Staying Distributed

Some projects are taking the nuclear option: fragmenting across multiple services.

• Git hosting: Self-hosted Forgejo or GitLab
• CI/CD: Self-hosted GitHub Actions runners or Woodpecker CI
• Issues: Linear, Plane, or a self-hosted solution
• Discussions: Discord, Zulip, or GitHub Discussions (read-only mirror)

This avoids vendor lock-in entirely but adds operational complexity.

What This Means for You

You probably are not Mitchell Hashimoto. Your personal projects do not have hundreds of contributors and thousands of daily PRs. But the same forces that pushed Ghostty off GitHub are affecting your workflow too.

Here is what you should consider:

1. Audit your GitHub dependency surface

List everything you rely on GitHub for beyond git push:

- Pull request review and merge
- CI/CD (GitHub Actions)
- Issue tracking and project boards
- Wiki and documentation
- Releases and package registry
- Codespaces or cloud dev environments
- Copilot or other AI features

For each one, ask: if GitHub went down for 4 hours, what would I lose?

2. Move your canonical source somewhere you control

The simplest step: push to multiple remotes. Your code is already distributed (that is the point of Git), but most of us only push to origin.

# Add backup remotes
git remote add forgejo [e-mail]:user/repo.git
git remote add codeberg [e-mail]:user/repo.git

# Push to all remotes
git push origin main
git push forgejo main
git push codeberg main

# Or automate with a post-push hook
git config --global alias.push-all \
  '!git push origin main && git push forgejo main && git push codeberg main'

3. Decouple CI from the platform

GitHub Actions are convenient but they are the deepest form of lock-in. If your CI lives only in .github/workflows/, migrating is painful.

Consider running your own Actions runners or using a CI system that pulls from any Git remote:

# Woodpecker CI .woodpecker.yml (runs on any Git host)
pipeline:
  test:
    image: python:3.12
    commands:
      - pip install -r requirements.txt
      - pytest

  lint:
    image: python:3.12
    commands:
      - ruff check .
      - mypy src/

4. Know your migration path

You do not need to leave GitHub today. But you should know how you would leave if you had to.

Write down what a migration would look like. Which tools would you use? How long would it take? Which team members would need to be involved?

The time to figure this out is not during an outage at 2 AM.

The Bigger Question

Ghostty leaving GitHub is not really about GitHub. It is about a deeper shift in how we think about open source infrastructure.

For two decades, we have been consolidating open source onto a single proprietary platform. That platform has been overwhelmingly positive for the community. It lowered the barrier to contribution, created social norms around code review, and gave us discoverability tools that did not exist before.

But the cost of that consolidation is fragility. When the platform goes down, the entire ecosystem stalls. When the platform changes its terms, we all adapt. When the platform prioritizes AI features over core reliability, we all suffer.

Mitchell Hashimoto is not the first to notice this. He is just the first with enough clout, enough emotional investment, and enough frustration to do something about it publicly. His post resonated because thousands of developers feel the same way but have not had the courage or the platform to say it.

The decentralized web has been a dream for decades. Maybe, finally, GitHub's reliability crisis will be the thing that makes it real.

The Ghostty Migration: What We Know

Mitchell has been careful not to announce a destination yet. Ghostty is still in discussions with multiple providers. The migration will happen incrementally, and a read-only mirror will stay on GitHub.

What we do know:

• The plan was in motion for months before the April 27, 2026 outage
• They are evaluating both commercial and FOSS options
• This is focused on Ghostty specifically, not all of Mitchell's projects
• The decision is driven by reliability, not ideology

The Ghostty team has a lot of dependencies to unwind, including GitHub Actions workflows, issue templates, contributor guides, and community norms. A full migration will take months.

A Final Thought

Mitchell closed his post with something that has stuck with me:

"I'd love to come back one day, but this will have to be predicated on real results and improvements, not words and promises."

That is the bar. Not a blog post from GitHub acknowledging the outages. Not a discount on Copilot. Real, measurable, sustained reliability improvements.

Until then, the open source community has some decisions to make. Ghostty made theirs. What will yours be?