The honest answer to "should you leave GitHub?" depends almost entirely on a number nobody in the exodus discourse calculates: your migration cost, in hours, for your actual repos. When Mitchell Hashimoto pulled Ghostty — 50,000 stars, and him GitHub user 1299 since 2008 — off the platform in late April 2026, I did what half the industry did: opened a tab and typed a search phrase I never expected to type. Then I did the part most people skipped. I ran the numbers on my own forty-odd active repositories across this site, Ramlit, and client work, and tested the three serious alternatives against workflows I run daily.
The conclusion surprised me, and it is not "everyone should move." It is that the assumption of GitHub's inevitability broke that week — and a cracked default demands a decision made with a worksheet, not a panic.
What Actually Happened in Late April 2026
The order of the incidents matters more than any single one.
April 23. A regression in GitHub's merge queue silently produced incorrect merge commits whenever a squash-merge queue group contained more than one PR. GitHub's own incident report counted 2,092 pull requests across 658 repositories affected in a window from 16:05 to 20:43 UTC. This was not downtime — Git kept working, the status page stayed green. It was worse: previously merged changes got silently reverted by subsequent merges. And it took roughly three and a half hours to detect, because it surfaced through customer support tickets, not monitoring. Nobody was watching for "did the merge do what the merge said it did." Read that again: a version control platform briefly stopped reliably tracking versions.
April 27. The search infrastructure behind PR lists, issue filters, and project boards buckled — GitHub's leadership described hostile bot traffic stacked on top of load the cluster was already struggling with. The underlying data stayed intact while the interface that finds it lied for hours. Teams held meetings about PRs that "no longer existed."
April 28. Three things in one news cycle: GitHub published a public availability mea culpa; Wiz Research disclosed CVE-2026-3854, a CVSS 8.7 flaw letting any authenticated user reach remote code execution on GitHub Enterprise Server with a crafted git push (GitHub.com had been quietly patched in March); and Hashimoto published "Ghostty Is Leaving GitHub," citing a month-long personal journal in which almost every single day logged a disruption that blocked his work.
Three failures, three different layers, one week — against a backdrop of third-party monitors recording availability well below the status page's perpetual above-99% narrative. The gap between reported and experienced reliability is what actually eroded trust.
What I Tested, and the Honest Verdicts
My rule: no evaluating platforms from their marketing pages. I migrated a real private Laravel project — about 240 commits, GitHub Actions CI, open PRs, issues, milestones, CODEOWNERS — to each candidate and ran my actual workflow for a day.
GitLab: The Safe Choice That Isn't Quite Safe
The importer is genuinely good: eleven minutes from click to a repo with issues, milestones, and PRs-as-merge-requests intact. The real cost was CI translation — my workflow runs PHPUnit, Pint, Larastan, and a preview deploy, and rewriting .github/workflows/*.yml into .gitlab-ci.yml took about ninety minutes of actual thinking, not copy-paste. In fairness, GitLab's services: block for spinning up a MySQL container is nicer than GitHub's equivalent.
GitLab's true advantage is first-party integration breadth: code, CI, container registry, package registry, and security scanning in one product instead of stitched across four vendors. If you are assembling that stack from scratch, it is the cleaner bet.
The catch nobody flags loudly enough: GitLab.com is another giant SaaS under the same scaling pressures, with its own outage history. Migrating from one large hosted forge to another because you fear outages changes your single point of failure; it does not remove it. The version that actually fixes reliability is self-hosted GitLab — which is a sysadmin job with patching, backups, and a 2 a.m. runbook. For solo operators and small teams, that operational tax usually outweighs the gain.
Codeberg: The One That Surprised Me
I expected to dismiss Codeberg in twenty minutes and came out taking it more seriously than anything else I tested. It is a German nonprofit running Forgejo (the community-governed Gitea fork): no investors, no AI upsells, donation-funded, EU-hosted — which quietly matters enormously if you have GDPR exposure.
Import took seven minutes. The interface is "GitHub circa 2018," which I mean as a compliment: everything legible, nothing engagement-optimized. Forgejo Actions is API-compatible with GitHub Actions — my workflow ran after about forty-five minutes of tweaks, mostly one marketplace Action swapped for a Codeberg-registry equivalent.
The structural point: during the exact week GitHub was struggling, Codeberg's status page showed normal operations. Not because it is better engineered than GitHub — because it is not a target at that scale, and is not absorbing the agentic-AI traffic surge. Smallness is currently a reliability feature.
The honest limits: it is intentionally for free and open-source work, not private client repos; CI minutes are donation-funded and conservative; and there is no Trending page to feed a project's growth. For open-source work, especially European, it is the most underrated destination of 2026.
SourceHut: Built for an Engineer You Probably Aren't
I lasted six hours. Not because SourceHut is bad — every page renders instantly, the engineering is impeccable, builds.sr.ht CI is fast and clean, and pricing runs roughly $20-50 a year. Because review happens via mailing lists and git send-email, and the cultural distance from PR-button muscle memory is enormous. Kernel-style workflows thrive there. Most of us, honestly assessed, are not that engineer.
The Migration Math Nobody Shows You
Feature comparisons are the easy 20%. Here is the worksheet that decides the real question — run your own numbers through it:
- Repo migration: ~30 minutes per repo with standard issues/PRs.
- CI rewrite: 1-3 hours per non-trivial workflow to GitLab CI; 30-90 minutes to Forgejo Actions; half a day to SourceHut builds if it is your first.
- Webhooks and integrations: ~15 minutes each — Slack, deploy hooks, status checks all need rewiring. My own deploy pipeline is a GitHub Actions rsync job with SSH secrets and post-deploy artisan commands (the one I documented here); porting it is easy, re-testing it against production safely is the real cost.
- Branch protection and permissions: nothing migrates; ~2 hours to audit and recreate.
- Documentation: every badge, wiki link, and "find us on GitHub" reference.
- Contributors: they must migrate too. Some won't. Budget a quarter of reduced contributor velocity.
- Discovery and identity: stars, the contribution graph, the profile-as-resume. This is the one-way network effect, and it does not transfer at all. Hashimoto can leave because Ghostty is already famous; a project still building an audience cannot.
For my forty-repo setup the total came out around sixty focused hours plus a months-long tail of fix-ups. That is a real fraction of a quarter, traded against an unknown quantity of future GitHub unreliability. For most working engineers, that trade only makes sense under specific conditions.
Migrate, Stay, or the Third Option
Migrate now if: your team depends on merge-queue correctness at high velocity (the April 23 failure mode is precisely yours); you have EU data-sovereignty requirements you have been hand-waving; or you run GitHub Enterprise Server and have not yet upgraded past the CVE-2026-3854 fix versions (3.19.3 or the equivalent patch for your line) — that one is not a migration question, it is a patch-today question, since the exploit chain runs through a single authenticated push.
Stay, with adjustments, if: you are a solo dev or small team on standard PR workflows whose public repos benefit from discovery. Note what actually failed in April: mostly the UI layer, not Git itself. The rational hardening is to reduce UI dependence — I already drive most GitHub operations through the gh CLI daily, which kept working through incidents that broke the web views — and to keep an off-platform copy of everything that matters.
The third option is what I actually did: mirror. Every repo of mine that matters now pushes an automated nightly git push --mirror to a second host. About thirty lines of shell and a scheduled job — the same pattern as any background automation in my terminal-first workflow, and the credentials live in a separate vault from my GitHub ones. If GitHub has another bad week, I have a warm copy. If it never does, I spent three hours acquiring a backup that was good practice anyway. Mirror first. Migrate only if the pain becomes real.
The Bigger Shift Underneath
GitHub's own leadership framed the load crisis in terms of agentic development workflows arriving like "a free buffet" — and that framing stuck with me, because we are the buffet line. Every Claude Code session, every autonomous pipeline, every agent built on the SDK hits version-control APIs at a rate no human ever did. The platform was sized for people; it now serves people plus their agents, and the company has publicly committed to scaling for roughly an order of magnitude more load. Whether that lands in twelve months or thirty-six is the real question hanging over every "should I leave" thread.
Meanwhile the same shift changes what we value in a forge: API reliability over UI polish, programmatic access over social features. Codeberg and SourceHut were accidentally built for that world years early. The era when "GitHub" was a synonym for "where code lives" is closing — not because GitHub is collapsing, but because the inevitability is gone.
Your homework, and it costs one hour: run the worksheet above against one repo that genuinely matters to you. You will probably conclude, as I did, that you should stay and mirror. But you will have concluded it from your own numbers — which means the next incident finds you with a plan instead of a panic.
If your team needs that evaluation done properly — CI portability audit, mirror automation, or a full forge migration with the deploy pipeline re-proven on the other side — that is work I take on. Tell me what your repo situation looks like and I will tell you honestly whether moving is worth it.
