Why Developers Are Leaving GitHub for Forgejo — and How to Migrate Safely

# Why Developers Are Leaving GitHub for Forgejo — and How to Migrate Safely

Developers are leaving GitHub for Forgejo because they want more control over their code hosting, fewer surprises from a centralized platform’s policy and product shifts, and the ability to run a git forge on infrastructure they own—accepting the operational work that comes with self‑hosting. In practice, the move is less about a single “killer feature” and more about trust, privacy, and long-term autonomy: Forgejo is a lightweight, open-source git forge (from the Gitea/Gogs family) that supports repositories, issues, pull requests, wikis, releases, LFS, and Actions‑like CI—without tying you to a vendor-hosted roadmap.

The core motivations: control, privacy, and “feature freedom”

A recurring theme in migration writeups is control and trust. GitHub is a Microsoft-hosted, centralized service; Forgejo is designed to be self-hosted. That difference matters if you’re worried about platform decisions you can’t influence—policy changes, feature changes, or the risk of losing access to an account or organization at the platform layer. Self-hosting doesn’t eliminate risk, but it changes who holds the keys.

The second driver is privacy and sovereignty. Teams that need tighter control over where repository data lives—whether for personal “de‑big‑tech” reasons or organizational compliance posture—often prefer keeping source code, issues, and metadata on infrastructure they manage. The same logic extends to concerns about platform-level AI features and data handling: even when your code is private, some developers simply prefer not to rely on a third party’s evolving AI and data-collection posture for core engineering assets.

Then there’s feature freedom—the ability to shape the forge around your workflow rather than shape your workflow around the forge. Forgejo is commonly praised for being lightweight and customizable. Migrators point to benefits like fewer hosted limits (for example around Git LFS usage) and deeper integration options (including direct database access in self-hosted scenarios) that can simplify advanced internal tooling, archiving, or long-term mirroring strategies.

Finally, some of the shift is a reaction to product direction and perceived neutrality. GitHub has moved aggressively into AI-integrated developer tooling (notably Copilot and broader AI features). Multiple migration guides frame Forgejo as a way to avoid being “dragged along” by platform shifts that aren’t aligned with a team’s preferences, even if GitHub remains feature-rich and convenient.

If this broader confidence-and-trust theme sounds familiar, it also parallels anxieties around dependency and ecosystem risk discussed in Supply-Chain Worm Erodes Trust in npm and GitHub.

Why It Matters Now

While the underlying debate—centralized convenience versus self-hosted control—has existed for years, recent signals have made the “Forgejo option” feel more immediate and practical.

First, there’s growing visibility of real migrations. One widely cited personal report describes moving 200+ repositories to a self-hosted Forgejo instance (“I migrated 200+ repositories…”) and captures the trade-off honestly: “It was an insane journey and learned a lot of new things about Docker. I wish I didn't but I'm glad it's over.” That combination—proof it can be done at scale, plus a candid warning about operational work—has helped normalize the idea that leaving GitHub is feasible, not just theoretical.

Second, the “AI everywhere” direction of major platforms has sharpened organizational questions about data handling and sovereignty. Even without a single triggering event, the cumulative effect of rapid platform evolution can push teams toward infrastructure they can audit and govern more directly.

Third, migration is getting easier because the ecosystem is maturing. Tools like PatNei/GITHUB2FORGEJO explicitly target bulk backup/migration/mirroring by pulling repositories from GitHub and creating matching repositories on Forgejo via APIs. Meanwhile, Forgejo deployments via Docker / Docker Compose (often with PostgreSQL) have become a common, repeatable starting point—especially when combined with third‑party deployment helpers and templates.

What you can migrate easily—and what will hurt

A safe migration plan starts with realism about what ports cleanly.

Straightforward: your git data. Repositories, branches, tags—and the full commit history—are the easiest artifacts to move. Git’s native mirroring workflows (for example, clone --mirror) are reliable and well-understood.

Moderate effort: collaboration metadata. Issues, pull requests, comments, labels, releases, and wikis can often be migrated using scripts and API clients, but you should expect cleanup—especially around attachments and cross-references that may point back to GitHub URLs. Migration tooling can help, but it’s rarely “zero-touch.”

Hard: CI and ecosystem integrations. GitHub’s ecosystem strength—Actions workflows, marketplace integrations, and proprietary features—doesn’t automatically translate. Forgejo offers Actions-like CI, and some users report successfully porting pipelines, but many workflows require rework, and some integrations simply won’t have equivalents.

A practical, safe migration path (high-level)

Most successful migrations follow a staged approach:

1. Inventory and prioritize. List repositories, collaborators, issue volume, wiki usage, LFS usage, CI workflows, webhooks, and external integrations. Prioritize by sensitivity and by how active a repo is.
2. Choose your migration method.

• For bulk moves with metadata: consider PatNei/GITHUB2FORGEJO, which is designed to fetch repos from GitHub and create matching repos on Forgejo.
• For maximum control: use git mirroring plus custom API scripts for issues/PRs and post-processing.

1. Deploy Forgejo safely before importing anything. Many guides use Docker Compose with PostgreSQL, then add HTTPS, backups, and access controls. Pay attention to version selection: one deployment note highlights that tools/templates may default to a particular Forgejo version (for example, Coolify defaulting to v8) and that users sometimes edit Compose files to target their preferred version—alongside mentions of v8 vs v9+ licensing differences. Whatever you choose, standardize on a version strategy you can upgrade.
2. Migrate in layers. Move git repos first (so developers can fetch/push), then import issues/PRs/wikis/releases, then tackle LFS objects and CI. This reduces blast radius when something goes wrong.
3. Test, then cut over. Validate repository integrity, run CI smoke tests (whether via Forgejo Actions or an alternative CI), and only then update remotes and developer documentation. Decide whether GitHub becomes read-only archival, a redirect point, or a mirror.

For teams thinking more broadly about platform risk and repo strategy, this migration conversation also fits into Supply-chain trust, sovereign AI pushes, and repo exodus — what dev teams must know.

Running Forgejo securely and keeping it maintainable

The hidden cost of leaving GitHub isn’t migration—it’s operations.

At minimum, you need disciplined backups (both database and git storage), monitoring, and a patch process. If you use LFS heavily, plan storage and redundancy explicitly. Security-wise, lock down admin access, use HTTPS/TLS, enforce strong authentication (SSO/OAuth/LDAP where appropriate), enable 2FA, and review audit logs regularly.

Also plan for upgrades: follow Forgejo release/LTS guidance, test upgrades in staging, and keep any third-party templates aligned with the version you’re running. Several migration stories emphasize that self-hosting is a learning curve—especially around Docker and day‑2 operations—so treat this like a production service, not a side project.

The trade-offs to weigh before you jump

Moving to Forgejo is a bet that control is worth responsibility.

You gain autonomy, privacy, and customization. But you take on the operational burden (uptime, storage, backups, upgrades, incident response). You also accept ecosystem friction: GitHub’s breadth—integrations and centralized collaboration habits—is hard to replicate in a lightweight forge.

And costs can shift rather than disappear. Compute, storage (especially LFS), and maintenance time can exceed hosted fees depending on scale and reliability requirements.

One-page migration checklist

• Inventory repos, LFS, CI workflows, webhooks, wikis, and collaborators
• Stand up Forgejo (commonly Docker Compose + PostgreSQL), enable HTTPS, set auth/2FA
• Run migration tooling (e.g., PatNei/GITHUB2FORGEJO) and/or git mirroring + API scripts
• Migrate LFS objects; rework CI for Forgejo Actions or an alternative runner
• Validate integrity and run CI smoke tests in staging
• Cut over: update remotes, communicate changes, set GitHub to read-only/archive if desired
• Turn on backups, monitoring, and a patch/upgrade cadence

What to Watch

• GitHub platform shifts (especially around AI feature integration and policy changes) that influence trust and data-handling comfort
• Forgejo releases and LTS guidance, including security advisories and ecosystem maturity around Actions-like CI
• Migration tooling evolution (API scripts, mirror tools, and templates) that can simplify—or complicate—repeatable upgrades
• Your own operational signals: outages, compliance requirements, or expanding LFS/CI needs that may change the self-hosting cost-benefit

Sources: blog.hloth.dev , github.com , andrlik.org , kamilmarut.com , blog.juyung.com , dasroot.net