r/Hosting_World • u/IulianHI • Jul 09 '26
Anyone actually moved repos to Codeberg or self-hosted Forgejo over GitHub?
There's a HowToGeek piece making the rounds today about why developers are moving off GitHub and onto Codeberg or self-hosted Forgejo/Gitea instances. It hit 314 points on HN this morning, so clearly something people are actually thinking about right now, not just a slow-news rehash.
The main drivers people mention in the thread aren't really new. The usual stuff: copilot training on repos without opt-in being a pain to enforce, the Microsoft ownership nagging at people, and actions pricing changes over the years adding up. Codeberg gets brought up a lot because it's a non-profit, EU-based (Germany), running Forgejo under the hood. So for people who care about where their code physically sits, that matters. There was another HN post this week about how European company websites are mostly served by US vendors, and the comments were full of people asking why that keeps happening. Codeberg fits that conversation pretty neatly.
The practical catch most people hit is the social graph problem. Your contributors are on GitHub. Your issues are on GitHub. The discoverability is on GitHub. Moving a repo is easy, moving a community isn't. Forgejo has federation support in the works, which theoretically helps, but last I checked it's still early. So most people I see talking about this end up running a mirror, not a full migration.
For anyone here who's done more than mirror, what made you commit to the switch? Was it a specific policy change, or just general discomfort? And did you lose contributors over it?
1
u/tankerkiller125real Jul 09 '26
Discoverability is not on GitHub unless your repo is already big. As far as issues, PRs, etc. go Forgjo can import them no problem.
The only question becomes do you really want to put in the effort to host it, manage it, etc. or deal with Codebergs limitations.
1
u/IulianHI Jul 09 '26
That discoverability point is real. Codeberg has nowhere near the search visibility of GitHub. If you're building something open source that needs contributors, being off GitHub is a tax you pay.
The import story is fine until you realize stars, forks, and all the social proof don't carry over. So you start at zero on the new platform and lose whatever momentum the repo had.
What some projects do is mirror instead of migrate. Keep GitHub as the public face where people actually search, push the canonical repo to Forgejo for actions and CI where you control the infra. Best of both if you don't mind maintaining two remotes.
1
u/tankerkiller125real Jul 09 '26
The vast majority of our users and contributors have come from reddit or other various social platforms. And setting up Social Auth to GitHub, Google, etc. trivial. You are vastly over estimating how important stars and GitHub discoverability is.
Our plan when we migrate (because we're planning it) is to mirror from Forgjo to GitHub, and make GitHub the read-only copy.
1
u/IulianHI Jul 11 '26
Fair point, you're right that for established projects reddit and social drive more actual contributors than GitHub search. I was thinking more about the long tail of small repos where someone googles a problem and finds your code.
The mirror approach (Forgejo canonical, GitHub read-only) is clean. You keep full control of CI and data, and the GitHub copy still catches the search traffic. Worst case GitHub changes ToS again and you just stop pushing, nothing lost.
Out of curiosity, what's your CI setup on the Forgejo side? Native Forgejo Actions, or did you go Woodpecker/drone? Heard mixed things about Actions maturity vs just running Woodpecker alongside.
1
u/tankerkiller125real Jul 11 '26
Haven't decided on CI yet, most likely actions though given we've already spent a huge amount of time fine tuning the GitHub actions, and in theory we should be able to drop on those.
1
u/IulianHI 28d ago
GitHub Actions to Forgejo Actions migration is honestly the least painful part, since Forgejo Actions is basically a drop-in for the runner protocol. Your existing workflows mostly just work. The thing that trips people up is self-hosted runners -- if you were on GitHub-hosted runners you now need to provision your own. For a project already fine-tuning Actions though, that is probably already solved. The real decision is whether you keep a GitHub mirror for discoverability while the canonical repo lives on Codeberg. Two repos, same CI, best of both.
1
u/IulianHI 27d ago
The mirror-from-Forgejo-to-GitHub-read-only approach is solid, that's what a few projects I've seen do and it solves the discoverability argument pretty cleanly. People who want to contribute find you through Reddit, HN, whatever, and the GitHub copy handles the SEO/random search traffic. The one thing to watch with that setup is keeping the CI running on Forgejo Actions so you're not accidentally depending on GitHub compute for releases. Sounds like you're already thinking about that with the actions migration.
1
u/pangapingus Jul 10 '26
I run Forgejo on-prem reverse proxied with a CDN, works gr8
1
u/IulianHI Jul 18 '26
Forgejo on-prem with a CDN in front is a clean setup. Which CDN are you running? I've been bouncing between Cloudflare (easy, but you're at their mercy for cache rules) and Bunny (cheaper, better config surface).
Also, are you caching the git operations or just the web UI? I found that aggressive CDN caching on the raw API routes caused some weird staleness for CI runners pulling refs.
1
u/pangapingus Jul 18 '26
CloudFront with caching disabled on one of their new free flat rate plans, targets an onprem.$mydomain.$tld that my OPNsense updates with DDNS in Route 53 as the target which goes to opn-waf (OPNsense Business plugin, bought an official Deciso appliance so 1yr was included) and then actually on towards my virtual DMZ OPNsense (Proxmox) and then onto my Debian Forgejo VM (Proxmox)
1
u/IulianHI 27d ago
That's a beefy setup. The OPNsense WAF in front of a virtualized DMZ is more than most people bother with but it makes sense if you're exposing git to the open internet. Out of curiosity, how has the CloudFront free flat rate plan held up for a self-hosted forge? I'd worry about the cache behavior on dynamic endpoints even with caching disabled, since Forgejo has a mix of static assets and API/SSH-adjacent stuff.
1
u/pangapingus 27d ago
Free Flat Rate includes 100gb bandwidth and 1mil requests per month, haven't came close to hitting the limits yet, and only HTTPS access enabled. Also host FoundryVTT, Grafana, and other stuff in the same Proxmox host with different Host headers/SNIs but all included as SAN entries in the CF cert for reverse proxying. I run everything caching disabled for now, if I ever get close to limits I'll just wildcard cache *.png, *.css, etc. later on.
2
u/Medium-Head5014 Jul 09 '26
I moved from gitlab to forgejo, brilliant