The post asked a simple question after repeated GitHub incidents: should teams switch? The useful answer was “switch to what problem you are actually solving.” If you only need remote Git storage, a bare repo over SSH is enough. If you need a full forge with pull requests, issues, permissions, and CI, the main paths split between self-hosted GitLab, lighter self-hosted options like Forgejo or Gitea, hosted community services like Codeberg, and more opinionated alternatives like SourceHut, Tangled, Radicle, or Fossil.
The center of gravity landed on self-hosted Forgejo, Gitea, and GitLab. GitLab was described as the closest feature match to GitHub, especially for larger orgs and CI-heavy workflows, but also the heaviest to run and the most maintenance-intensive. Several people said self-hosted GitLab still gave them less downtime than GitHub because they controlled upgrades and incident response. Forgejo and Gitea got the most praise for being fast, lightweight, and easy to operate on modest hardware. The tradeoff is that they do not fully replace GitHub’s ecosystem gravity. Compatibility with
GitHub Actions exists, but not perfectly. Third-party integrations are thinner. Hosted options like Codeberg are attractive for open source, though private repo support and policy choices around AI-generated code limit it for many teams.
A recurring practical pattern was not a clean break, but a split setup. Teams self-host a primary forge, then mirror to GitHub for visibility, contributions, releases, or just outage insurance. That approach reflects the biggest sticking point people kept coming back to: GitHub is not hard to replace as a Git server, but it is hard to replace as the place where everyone already has an account, where issues and PRs are easy to submit, and where your existing CI actions, apps, notifications, and contributor flow already live. For small teams and private work, moving looks straightforward. For projects that depend on GitHub’s network effects, migration costs are mostly social and operational, not technical.
The sharper comments pushed one level deeper. The real fragility is not that Git itself is centralized, but that issues, PRs, CI logs, workflow history, and identity are trapped in a single hosted layer above Git. That is why several people argued for either mirroring everywhere you can, separating CI from your forge, or using more distributed models such as Radicle, Tangled, or git-native issue trackers. Even commenters who liked alternatives usually warned against reactive migration. The sensible move is to make sure a GitHub outage cannot halt critical work, then choose the smallest change that gets you there.
news.ycombinator.com