GitHub Developer Exodus 2026: Should You Actually Leave?

GitHub Developer Exodus 2026: Should You Actually Leave?

I was halfway through reviewing a pull request when the X notification came in. Mitchell Hashimoto — the guy who built Vagrant, Terraform, and Ghostty — was pulling his 50,000-star terminal project off GitHub. He'd been GitHub user 1299 since February 2008. He'd opened the site, by his own count, basically every single day for over eighteen years.

I read his post twice. Then I closed the PR I was reviewing, opened a new tab, and started typing "GitHub alternatives 2026" into a search bar I never thought I'd type that phrase into.

The thing is, I'm not Mitchell Hashimoto. I don't have a 50k-star project. I don't have leverage with multiple "commercial and FOSS providers" willing to host me. I'm a working engineer with maybe forty active repos across mejba.me, Ramlit Limited, and a handful of client projects. The math on whether I should leave GitHub isn't the same math as his.

But the question got loud enough this week that I couldn't ignore it. So I spent four days running the numbers — actually testing GitLab, Codeberg, and SourceHut against the workflows I run daily — and what I found surprised me. Not because one of them is obviously better. They aren't. The surprise is what the comparison reveals about what GitHub has actually become in 2026, and the specific kind of developer who should be making moves right now versus the specific kind who should absolutely stay put and just adapt.

This is the post I wish someone had written before I lost a Sunday to it.

The Week That Broke the "GitHub Is Forever" Assumption

You already know the headlines. Let me set the timeline tight, because the order matters more than the individual incidents.

April 23, 2026. Between 16:05 UTC and 20:43 UTC, a regression in GitHub's merge queue silently produced incorrect merge commits whenever a queue group contained more than one PR using the squash merge method. According to GitHub's own incident report, 2,092 pull requests across 230 repositories were affected. The bug wasn't an availability failure — Git operations kept working, the API kept returning data, the status page stayed mostly green. The bug was that commit correctness broke. Code that teams thought they'd merged got reverted by subsequent merges in the same queue. It took GitHub three hours and thirty-three minutes to even notice, because no automated monitor was watching for "did the merge actually do what the merge said it did."

Read that paragraph again if you need to. A version control platform briefly stopped reliably tracking versions.

April 27, 2026. GitHub's Elasticsearch cluster — the subsystem that powers PR list views, issue search, project board filters, and most of the UI you actually click on — got overwhelmed. GitHub's CTO publicly described it as a botnet attack stacked on top of organic traffic the cluster was already struggling with. For hours, the underlying data was fine, but the interface that finds the data lied to developers. People accused teammates of deleting work that hadn't been deleted. Teams ran meetings on the assumption that PRs they couldn't see no longer existed.

April 28, 2026. Three things happened in the same news cycle. GitHub published a public reliability apology pivoting the company to an "Availability First" stance. Wiz Research disclosed CVE-2026-3854 — a CVSS 8.7 critical RCE that let any authenticated user achieve remote code execution on GitHub's backend with a single git push, by injecting unsanitized data into the internal X-Stat header. And Mitchell Hashimoto published "Ghostty Is Leaving GitHub."

Three failures, three different layers of the stack, one week. That's the data.

But here's the part that didn't fit on the front page of Hacker News: GitHub's third-party-monitored uptime dropped below 90% across 2025 and slid further into April 2026, hitting roughly 86% for the month. AWS S3, for context, runs on a "eleven nines" design target — 99.999999999%. GitHub's public status page kept claiming above 99% the whole time. That gap, between what the status page reports and what developers actually experienced, is the thing eroding trust faster than any single outage could.

When the most respected solo developer in the open source world says a platform is "no longer a place for serious work," the rest of us have to at least do the math.

What I Actually Tested (And the Honest Verdict)

Before I get into the comparison, here's the rule I gave myself: I wasn't going to evaluate any platform from its marketing page. I'd migrate one real project to each, run my actual workflow against it for a day, and write down what broke.

The project I picked was a private Laravel side-project with about 240 commits, GitHub Actions for CI, two open PRs, three milestones, twelve issues, and a CODEOWNERS file. Not a toy. Not a 50k-star monster either. Roughly the shape of work most readers of this site actually do.

Here's what happened.

GitLab: The Safe Migration That Isn't Quite Safe

GitLab is the obvious first stop. It's the platform every "GitHub alternatives 2026" listicle leads with, and the reason is simple — it's the only competitor with comparable feature surface area. CI/CD, issue tracking, container registry, package registry, security scanning, all bundled into one product instead of stitched across GitHub Actions, Packages, Dependabot, and Advanced Security.

I migrated the Laravel project to GitLab.com (the SaaS, not self-hosted) using their built-in GitHub importer. Total time from clicking "import" to seeing my repo with all PRs, issues, and milestones intact: about eleven minutes. The importer brought across:

• Full Git history (obviously)
• Issues with labels and milestones
• Pull requests as merge requests
• CI/CD config (with rewrites — .github/workflows/*.yml doesn't run on GitLab; you need a .gitlab-ci.yml)
• Branch protection rules (manually re-applied)
• Webhooks (had to recreate)

The CI rewrite was the real cost. My GitHub Actions workflow ran PHPUnit, ran Pint for formatting, ran a static analysis pass via Larastan, and deployed a preview environment to a Hetzner VPS. Translating that to GitLab CI took me about ninety minutes, mostly because GitLab's services: block for spinning up a MySQL container is genuinely nicer than GitHub's, but the rules: syntax for conditional jobs is more verbose. You don't get to copy-paste; you have to think.

The thing GitLab does better than GitHub right now, full stop, is first-party DevOps integration. If you're a startup that wants one platform for code, CI, container registry, package registry, and security scanning, and you'd otherwise be assembling that from GitHub plus three other vendors, GitLab is the cleaner bet. The all-in-one story is real.

The catch — and this is the catch nobody flags loudly enough — is that GitLab.com had its own significant outage in 2025 and runs on the same fundamental scaling pressure GitHub does. Migrating from one large SaaS Git host to another large SaaS Git host because you're worried about reliability is, charitably, an incomplete strategy. You've changed your single point of failure, not removed it.

The version of GitLab that actually fixes the reliability concern is self-hosted GitLab — either the free Community Edition or the paid Premium tier. That's a different conversation. That's a sysadmin job. That's a server that needs patching, backups, an SSL cert, an SMTP relay, and a runbook for the day it goes down at 2am. If you're solo or a small team, the operational tax usually outweighs the reliability gain.

GitLab verdict: A genuine GitHub competitor on features. A questionable GitHub competitor on reliability if you stay on GitLab.com. A real reliability play only if you self-host — and self-hosting is a job, not a checkbox.

Codeberg: The One That Surprised Me

Codeberg is the platform I expected to dismiss in twenty minutes. I came out of the test taking it more seriously than anything else I evaluated.

Quick context: Codeberg is a German nonprofit running an instance of Forgejo, a community-governed soft fork of Gitea. There are no investors, no ads, no corporate roadmap, no AI features bolted on top, no "agentic workflow" surge artificially inflating the load. It's funded by donations. Its philosophy is explicit: be a safe home for free and open source software. It's hosted in the EU under a foundation, which matters quietly but enormously if you have GDPR exposure.

I imported the Laravel project — well, a public-friendly fork of it. Codeberg's own terms ask you to host primarily free/open source work, which is the right boundary for a donation-funded nonprofit. The import took about seven minutes. The interface is unmistakably "GitHub circa 2018" — and I mean that as a compliment. PR view, issue view, milestone view, code search, all immediately legible. No AI suggestions. No Copilot upsell. No "explore" feed designed to keep you on the site.

Forgejo's CI system, Forgejo Actions, is API-compatible with GitHub Actions. My .github/workflows/ci.yml ran with two minor tweaks: a renamed runner label, and one Action I'd been pulling from the GitHub marketplace had to be replaced with an equivalent published to Codeberg's own action registry. About forty-five minutes of work to get green.

Here's the part that made me sit up. The week of April 23-28, while GitHub was visibly struggling, Codeberg's status page showed normal operations across every component. That's not a crowing-about-it claim — it's a structural advantage. Codeberg isn't a target for the same botnets at the same scale, isn't being hammered by the same agentic AI workflow load, isn't trying to scale its infrastructure 30x to keep up with synthetic traffic. The platform is small enough to stay reliable in a way the giants currently aren't.

The honest limits: Codeberg is intentionally not for proprietary closed-source work. The CI minutes available are conservative because someone's donating to keep them on. There's no LinkedIn-style social graph driving discovery. If your project's growth strategy depends on GitHub's "Trending" page, you can't replicate that here.

Codeberg verdict: If you ship open source software, especially in the EU, especially as an individual or small team, this is the most underrated migration target in 2026. It's not a GitHub replacement. It's something better in the specific dimensions GitHub has stopped being good at — quiet, reliable, owned by the community it serves.

SourceHut: The One Built for the Engineer You Probably Aren't

SourceHut is the most opinionated platform I tested. Drew DeVault built it on a clear thesis: most of what makes modern Git hosting "powerful" is actually noise, and an email-driven, JavaScript-free workflow is faster for serious software development than any UI-heavy alternative. Pricing starts free; paid tiers are roughly $20-$50/year depending on usage.

I'm going to be honest with you. I imported the Laravel project, ran the workflow for a day, and gave up around hour six.

Not because SourceHut is bad. Because SourceHut is built for a workflow I don't actually run. Code review on SourceHut happens via mailing lists and git send-email. Bug tracking happens via a tracker that's deliberately spartan. CI runs through builds.sr.ht and is genuinely fast and clean. But the cultural delta — switching from PR-based review to patch-by-email review — is enormous. Linux kernel maintainers love it. Most of the rest of us, myself included, have built a decade of muscle memory around clicking "Approve" in a web interface.

The platform itself is impeccably engineered. Every page renders in well under a second. There's no JavaScript anywhere. The maintainer's transparency about infrastructure costs and decisions is something nobody else in this space matches. If you're the kind of developer who runs mutt for email and considers a UI button a personal insult, SourceHut is the platform that finally rewards your aesthetic.

SourceHut verdict: Not a GitHub alternative for most teams. A different paradigm for the specific subset of developers who genuinely want patch-via-email workflows. Respect the philosophy, but be honest about whether you're actually that engineer.

The Migration Math Nobody Shows You

Here's where I want to break from every "top GitHub alternatives" listicle you've read this week.

Most of them stop at the feature comparison. The feature comparison is the easy part. The feature comparison doesn't capture the actual cost of leaving GitHub, and if you don't price that cost honestly, you'll either migrate when you shouldn't or stay when you shouldn't.

Here's the real math.

What GitHub Actually Provides You Beyond Hosting

When you host on GitHub, you're not paying for git push to work. git push works on a $5 VPS with a bare repo and an SSH key. You're paying — explicitly with subscription dollars, implicitly with your data — for an interconnected stack of services most of which have no replacement on Codeberg, SourceHut, or even GitLab.

Discovery and inbound contributors. The "Trending" page, the explore graph, the social proof of stars and forks, the GitHub-native search that lets a stranger stumble onto your project — these are enormous business assets for any open source maintainer, and they don't migrate. Mitchell Hashimoto can move Ghostty off GitHub because Ghostty is already famous. A new project trying to build an audience cannot.

CI/CD ubiquity. GitHub Actions has become the de facto deployment integration target for every cloud provider, every package registry, every release tool. AWS publishes Actions. Cloudflare publishes Actions. Vercel publishes Actions. Replicating that integration surface elsewhere isn't impossible, but it's rarely turn-key.

The marketplace ecosystem. Third-party Actions, GitHub Apps, the integrations layer — none of this exists at the same density anywhere else. If your workflow depends on five marketplace Actions, migrating means rebuilding or replacing five integrations.

Recruiting and identity. Your GitHub profile is, for many companies, your resume. Your contribution graph is a credential. Your username is a brand. None of that transfers cleanly to a new platform — and the network effect only flows one way.

The Migration Cost Worksheet

Here's the worksheet I wish I'd had on Sunday morning. Run your project through it before you make any decision either way.

1. Repo migration time. For a project with under 500 commits and standard issues/PRs: ~30 minutes per repo for the import alone. Multiply by your repo count.

2. CI rewrite time. GitHub Actions to GitLab CI: budget 1-3 hours per non-trivial workflow. GitHub Actions to Forgejo Actions on Codeberg: budget 30-90 minutes per workflow. GitHub Actions to SourceHut builds: budget half a day per workflow if you've never written one before.

3. Webhook and integration rewiring. Every external service that posts to your repo (Slack, Discord, deployment hooks, status checks) needs reconfiguring. Budget 15 minutes per integration, more if the new platform's webhook format differs.

4. Branch protection and team permissions. None of this migrates automatically. Audit and recreate. Budget ~2 hours for a typical team setup.

5. Documentation updates. Every README badge, every wiki link, every external doc that says "find us on GitHub." This is the unglamorous work that takes longer than you think.

6. The contributor cost. If you have external contributors, they have to migrate too. Some won't. You'll lose some contributor velocity for at least the first quarter post-migration. Price that into your decision.

7. The recruiting and visibility cost. If your project gains contributors via discovery, GitHub's network effect is part of your growth strategy. Leaving means rebuilding that pipeline somewhere with weaker network effects.

For my forty-repo personal/work setup, my honest estimate to fully leave GitHub came out to about 60 hours of focused engineering work plus a multi-month tail of small fix-ups. That's a real number. A meaningful fraction of a quarter's productivity, traded for an unknown amount of future reliability.

For a startup at twenty engineers, multiply that by the number of repos and integrations and you're looking at a months-long project with real opportunity cost. For a 50k-star public project like Ghostty, it's bigger still — except Hashimoto has the leverage to negotiate with providers and the brand to keep contributors paying attention through the transition.

For most readers of this post: the migration cost is bigger than the reliability cost of staying through GitHub's recovery, unless one of three specific conditions is true.

When You Should Actually Migrate (And When You Shouldn't)

After running the math on real workflows, here's the framework I'm using personally and recommending to clients.

Migrate now if:

Your work depends on merge queue correctness for high-velocity monorepos. The April 23 incident specifically broke commit correctness in queues. If your team merges dozens of PRs a day through automated queues and you can't tolerate even a small probability of silent reverts, the trust gap is too large to wait out. GitLab's merge trains or a self-hosted alternative are reasonable hedges.

You have GDPR exposure or EU data sovereignty requirements and you've been treating "GitHub is fine for this" as a working assumption you haven't actually examined. Codeberg or self-hosted Forgejo on EU infrastructure clarifies your compliance story in a way GitHub now actively complicates.

You run GitHub Enterprise Server. This is the one where I genuinely think you should act today, not next quarter. CVE-2026-3854 affected an estimated 88% of GHES instances at disclosure. If you haven't already upgraded to GHES 3.19.3 or later, that's your first move regardless of any migration question. The RCE chain — inject a fake rails_env, redirect the hook directory, plant a pre-receive hook, get code execution as the git user — is straightforward enough that exploitation in the wild is a matter of when, not if.

Stay (with adjustments) if:

You're a solo developer or small team running standard PR-based workflows on public repos for visibility. The migration cost is real, the discovery cost is large, and most of GitHub's recent failures haven't actually broken Git itself. They've broken the UI layer that finds your work. The right move is to harden against UI-layer failures (use gh CLI, script your way around the web UI, mirror critical repos elsewhere as cold backup) rather than full migration.

Your business depends on GitHub-native integrations like Copilot, Advanced Security, or specific marketplace Actions you can't easily replace. Pricing the integration loss honestly often pushes "migrate" into "not yet."

You're running a project whose growth depends on inbound contributor discovery. You are using GitHub's network effect even if you don't think of it that way. Don't underprice it.

The hybrid play I'm actually doing

For my own work, I'm not migrating. I'm mirroring. Every repo of mine that matters now has an automated nightly mirror to a private Codeberg account. If GitHub has another bad week, I have a working second copy. If GitHub never has another bad week, I've spent about three hours on mirror automation and gained an off-platform backup that's good practice anyway.

The setup is roughly thirty lines of bash plus a cron job. Codeberg accepts pushes from any standard Git client, so the mirror config is identical to any other remote. I'm using git push --mirror on a schedule, with credentials in a separate vault from my GitHub credentials. The whole thing is the kind of low-stakes redundancy you wish you'd built before you needed it. (If you've already invested in a Claude Code workflow for terminal-driven development, wiring this in as a scheduled background job is a 20-minute task.)

What This Says About Where Developer Infrastructure Is Going

I want to close on the part that's bigger than any individual platform.

GitHub's CTO described the load curve hitting the platform as "agentic development workflows" arriving "like a free buffet." That phrase has stuck with me all week. He's not wrong. Every Claude Code agent, every Codex run, every Cursor background job, every autonomous pipeline you and I are running in 2026 hits GitHub's API more than a human ever would. We are, collectively and accidentally, the load that broke it.

The architecture GitHub was running in 2024 was sized for human developers. The architecture it needs in 2026 is sized for agents and humans, and the gap between those two numbers turns out to be roughly 30x. That's the scaling target the company has now publicly committed to. It's an enormous engineering project. Whether they hit it in twelve months or thirty-six is the actual question that determines whether the April 2026 incidents were a transitional pain point or the start of a longer decline.

What's also true is that the same agentic workflow surge changing GitHub's load curve is changing what developers value in a Git host. We care more about API reliability than UI polish, more about programmatic access than social features, more about predictable costs than enterprise feature lists. Codeberg and SourceHut, by accident or by design, were built for that audience years before the audience existed at scale. Their moment is now. If you're building AI agents that hit version control APIs continuously, the host you pick is a load-bearing decision in a way it wasn't two years ago.

The thing I'm most certain of, after this week: the era when "GitHub" was a synonym for "where code lives" is closing. Not because GitHub is collapsing — Microsoft has the capital, the engineers, and the strategic reasons to fix this. But because the assumption of inevitability is gone. We've watched the most visible solo developer in open source pack up and leave. We've watched the company itself publicly admit its uptime is below 86%. The default has cracked, and a cracked default is a different kind of default.

You don't have to leave. I'm not leaving. But sleepwalking back to the assumption that GitHub is the only serious option for hosting code in 2026 is a thing none of us get to do anymore. The question is finally back on the table — and that, more than any of the individual incidents, is what changed this month.

So here's the homework. Sometime in the next seven days, set a one-hour timer. Pick the worksheet from earlier in this post. Run it against one project of yours that genuinely matters. Just one. Find out what the actual migration cost would be for you, on your code, with your integrations.

You probably won't move. But you'll never again be in the position of having to make this decision under panic conditions, the way half the engineering managers I've talked to this week ended up doing. That's the real win. Not the migration. The clarity.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io