Moving from GitHub to Forgejo: Self-Hosting, CI Compatibility and Contributor Trade-Offs

That is the central trade-off in How-To Geek contributor Arol Wright’s account of moving to the free, self-hosted Git platform. Wright describes gaining direct control over code, project records and infrastructure while taking on backups, updates and the challenge of attracting contributors outside GitHub.

Forgejo’s documentation reinforces that conclusion—and adds some important qualifications. Migration is not the same as mirroring, familiar workflow syntax does not guarantee compatible automation, and choosing a long-term-support release does not remove the need for security maintenance.

What Forgejo puts under your control​

In Wright’s account, Forgejo supplies the familiar building blocks of a development platform: repositories, pull requests, issues, labels, milestones, wikis, releases and a package registry. The attraction is not a radically different development workflow. It is having those services run on infrastructure the operator controls.

The project’s governance deserves a precise description. Forgejo’s official FAQ says its contributors collectively define its governance, while the nonprofit Codeberg e.V. holds its domains. It also explicitly says Forgejo’s governance structures remain independent of Codeberg’s. Describing the project simply as “managed by Codeberg” misses that distinction. The FAQ further says Forgejo has not registered any trademarks, contrary to the claim that Codeberg holds its trademarks.

For someone seeking independence, that structure matters. But ownership is best understood as the ability to make decisions—and the responsibility to live with them—not a promise that infrastructure becomes effortless.

A small deployment still needs an operator​

Forgejo’s official Docker documentation provides a basic deployment using one server service and persistent storage. It also warns that the storage directory must have ownership matching the configured user and group IDs; incorrect permissions can prevent the container from starting. The launch may be simple, but the filesystem still gets a vote.

Wright recommends SQLite for a small personal installation and PostgreSQL for a busier service. That should be treated as deployment guidance, not a rule that a second user automatically requires a separate database server. Likewise, his roughly 100MB memory figure is not a useful capacity guarantee for an installation that will also store packages or run builds.

The distinction between hosting the forge and executing builds is especially important. Forgejo’s administrator guide says Forgejo Runner is installed and configured separately. The server coordinates workflows; runners fetch and execute the work. A basic repository-hosting container therefore does not, by itself, supply a complete CI environment.

A specific warning for v15 container deployments​

There is also a concrete security consideration missing from the migration account.

Forgejo’s v15 Docker documentation warns that container images before v16 defaulted security.REVERSE_PROXY_TRUSTED_PROXIES to *. Combined with an exposed web port and enabled reverse-proxy authentication, that configuration can have serious security consequences. The default changed in v16, but not in v15 LTS because it was a breaking change.

For affected deployments, Forgejo advises:

• Preventing untrusted networks from directly accessing the backend web port, normally port 3000.
• Replacing the wildcard trusted-proxy setting with the actual trusted proxy addresses or networks.

The practical lesson: HTTPS at the front door does not excuse leaving the service entrance unsecured.

Moving code is easier than moving a project​

Wright reports that Forgejo’s migration tools can bring across GitHub repositories and associated material, including issues, pull requests, labels, milestones and releases. He also cautions that not every feature or metadata field transfers perfectly.

That makes a trial import more valuable than a dramatic cutover. As migration-planning advice, inspect representative issues, release assets, attachments and contributor attribution before declaring the move complete.

Mirroring serves a different purpose. Forgejo’s official guide describes synchronization of Git branches, tags and commits—not full synchronization of issue discussions, reviews or other collaboration records. A mirror can preserve access to the code without reproducing the entire project workspace.

Two documented restrictions are particularly useful:

• Pull mirroring must be selected when creating the repository. An existing repository cannot subsequently be converted into a pull mirror.
• Push mirroring can overwrite destination changes. Without a branch filter, Forgejo uses git push --mirror.

The sensible interpretation is to choose an authoritative home for development rather than treating two mirrored repositories as interchangeable places to accept changes. Otherwise, synchronization can become an efficient way to distribute a mistake.

Forgejo Actions is familiar—not interchangeable​

Wright found Forgejo Actions approachable, but Forgejo’s own compatibility documentation is deliberately cautious: the goal is familiarity with GitHub Actions, not complete compatibility. Both use repository-based YAML workflows and runners, yet meaningful differences remain.

The v15 comparison guide identifies several:

• Some values in the github context are missing.
• Certain job subkeys, including permissions and continue-on-error, are ignored.
• OIDC token generation uses enable-openid-connect, rather than GitHub’s permissions: id-token: write.
• Default execution environments differ.

For Windows developers, the migration question is therefore broader than “does the YAML parse?” A prudent acceptance test is whether the pipeline still produces and tests the required Windows artifacts with the expected tools, credentials and failure behavior. Treat that as a validation requirement, not an assumption that similarly named workflow keys behave identically.

Runner security needs equal attention. Forgejo explicitly warns that runners perform remote code execution and can threaten their host and network. Our operational recommendation is to treat build infrastructure as a separate trust boundary, especially when accepting outside contributions—not as another harmless process beside the repositories.

LTS means a longer runway, not deferred maintenance​

The account highlights Forgejo 15.0’s long-term support, but readers should distinguish the LTS branch from the newest stable line.

Forgejo’s official documentation currently identifies 17.0.1 as latest and 15.0.11 as LTS. Its schedule lists these support boundaries:

Those dates mean v16 is already outside its scheduled support period as of November 15, 2026, while v15 remains a supported LTS choice. Staying on an LTS branch is not the same as staying on its original release indefinitely.

The hardest thing to migrate is participation​

Wright’s largest reservation is social rather than technical: moving a repository does not automatically move its audience. He describes additional friction for contributors accustomed to GitHub accounts and integrations, alongside the work of maintaining old project links and directing people to the new location.

That concern deserves equal weight with server specifications. A personal repository and a public community project have different success criteria. The former may chiefly need reliable private access; the latter also needs an obvious, low-friction route for reporting bugs and submitting changes.

Our assessment is to evaluate a Forgejo move in three separate parts:

1. Data: Did the code and necessary project records arrive intact?
2. Automation: Do builds, tests and publishing behave correctly?
3. Participation: Can existing and prospective contributors understand where to work?

Wright’s experience makes Forgejo a credible alternative for developers who value control and accept the administration burden. Its documentation shows why the decision needs more than enthusiasm for self-hosting: mirrors have limits, workflows need testing, and supported deployments still require careful configuration.

The reward is genuine independence. The price is becoming the person responsible when that independence stops answering requests.