I Ditched GitHub for a Week. Here's What I Wish I Knew Sooner
In this article
> **Bottom line:** I moved three working repos off GitHub for seven days in August 2026 — one to Codeberg, one to a self-hosted Gitea instance, one to SourceHut — after GitHub Actions had its fourth major outage of the year and torched my deploy pipeline mid-release.
The hosting itself was never the problem; migrating raw git history took under an hour per repo.
The real cost was the fifteen years of muscle memory built on top of GitHub — Actions, Copilot code review, Dependabot, the PR template your whole team has memorized — that nobody mentions when they tell you to "just self-host." I got my code out in a day.
I didn't get my workflow back all week.
Everyone in that "Ask HN: Alternatives to GitHub" thread is right, and everyone in that thread is also missing the point.
I've been shipping code professionally for over a decade, and I did something dumb this month: I actually left. Not "explored alternatives while keeping GitHub open in another tab." Left.
Three repos, one week, zero fallback.
**What I found wasn't a tooling problem. It was a dependency problem we've all been pretending doesn't exist.**
The Sacred Cow: "GitHub Is Just Where Code Lives"
Here's the conventional wisdom, and I get why people believe it: GitHub is free (mostly), it's where the recruiters look, it's where the open-source ecosystem already lives, and switching feels like changing your email provider — technically possible, practically insane.
For most of the last decade, that logic held up fine. GitHub was reliable, cheap, and had the network effects nobody else could touch.
Microsoft bought it in 2018 for $7.5 billion and largely left the core product alone.
Actions launched in 2019 and quietly became the default CI system for millions of repos. Copilot turned the platform into the place your code gets written, not just stored.
That's exactly what changed.
GitHub stopped being a place you keep code and became the place your entire engineering workflow runs through — build, review, deploy, security scanning, even the first draft of your pull request description.
**The more useful it got, the more expensive it became to leave.** And in 2026, that bill is coming due for a lot of teams who never noticed they were running a tab.
The Evidence: What Actually Happened When I Left
Day one: the code move was trivial, and that's the trap
Cloning a repo with full history and pushing it to Codeberg (a nonprofit, EU-based host running Forgejo) took me eleven minutes for a mid-sized repo with four years of commits.
Same story for spinning up Gitea on a $6/month VPS. Git is distributed by design — this part of the "alternatives" conversation is basically solved and has been for years.
That's also exactly why it's a trap. The ease of the git migration lulls people into thinking the whole move is that easy. It isn't.
Day two: CI died, and I mean *died*
My deploy pipeline was 22 lines of GitHub Actions YAML that I'd stopped thinking about years ago. On Codeberg, the closest native equivalent (Woodpecker CI) doesn't share a single syntax with Actions.
Rewriting it wasn't hard, but it wasn't a copy-paste either — it was a half-day of re-learning a tool I didn't know I'd need to re-learn.
SourceHut was worse in a good way: no visual pipeline at all, just a YAML manifest and a mailing-list-driven review model that made me feel like I'd time-traveled to 2009. It works.
It is also not what 90% of engineering teams hired for in the last five years.
Day three: I missed Copilot's PR reviews more than I expected
I didn't think I relied on Copilot's automatic review comments until they weren't there. On Gitea, I was reviewing my own PRs raw, the way we all did in 2015. It wasn't worse code.
It was slower code, and slower catches fewer things at 11pm before a release.
Day four: Dependabot's absence became a real security question
No GitHub means no Dependabot alerts by default.
Renovate covers this gap on self-hosted setups, and it's genuinely good — but "genuinely good, requires setup" is a different sentence than "on by default." I had a known-vulnerable dependency sit in one repo for two extra days simply because nothing was watching.
Day five: discoverability collapsed
This is the part open-source maintainers already know and everyone else underestimates.
A repo on GitHub gets found by search, by GitHub's own network graph, by the sheer gravity of 100+ million developers browsing there daily.
Move it to Codeberg or SourceHut and you're choosing principle over reach — full stop.
**Nobody stumbles onto your project anymore. They have to already be looking for it.**
The Real Problem Nobody's Talking About
The HN thread is full of great answers — Codeberg, SourceHut, Gitea, Forgejo, GitLab self-managed, even Radicle's peer-to-peer git for the truly decentralized-pilled.
All of these are legitimate, working tools. That was never in question.
The real problem is that we let one company become the operating system for how software gets built, reviewed, tested, and shipped — and we did it gradually enough that it never felt like a decision.
Nobody sat down in a meeting and said "let's make our entire release process dependent on a single vendor's uptime." It just accumulated, PR template by Action by bot integration, until one outage in August 2026 revealed the whole stack was load-bearing.
This isn't a GitHub-specific problem, either. It's the same story as AWS, as Slack, as Google Workspace.
**Convenience compounds into dependency, and dependency looks invisible right up until the day it isn't.** The "alternatives to GitHub" conversation keeps getting framed as a tooling comparison — Codeberg vs.
GitLab vs. self-hosted — when the actual question is about how much of your team's ability to function you're willing to hand to a system you don't control and can't fix when it breaks.
What You Should Actually Do Instead
You don't need to leave GitHub. I went back after my week, and so will most of the people posting in that thread. But you should do three things this month:
1. **Mirror your critical repos somewhere else.** A cron job pushing to Codeberg or a self-hosted Gitea instance costs you an hour to set up and gives you a real fallback, not a hypothetical one.
2. **Write your CI config so it's portable.** If your entire deploy process only exists as GitHub Actions YAML with no documented equivalent, you don't have a pipeline — you have a hostage situation.
Keep a plain-language runbook of what each step does, independent of the platform.
3. **Actually test the outage scenario.** Not "we'd probably be fine" — pick a Tuesday, pretend GitHub is down for four hours, and see what breaks.
You'll learn more from that than from any alternatives thread.
None of this requires ideology. It requires treating your dev tooling the way you'd treat any other single point of failure — with a plan, not a shrug.
The Uncomfortable Truth
The HN thread asking for GitHub alternatives isn't really about GitHub.
It's about the quiet realization that a huge amount of modern software development runs on infrastructure we don't own, can't audit, and have never stress-tested.
GitHub happens to be the most visible example because it's the one everyone touches every day.
I went back to GitHub because it's still, honestly, the best version of this trade-off available right now.
But I went back with a mirror running, a documented CI process, and a much smaller sense of certainty that "it'll always just work."
How much of your job would survive a week if the tool you didn't choose — the one you just inherited — disappeared tomorrow?
---
