Forgejo is becoming the owned forge between mirror and platform

Forgejo matters in 2026 because Git hosting has stopped being a neutral background utility for many teams. A repository host now carries code review, identity, packages, CI, project memory, moderation, and the political question of who can change the rules. Forgejo's useful promise is not that it can copy every GitHub habit. Its promise is narrower and more operational: teams can own a modern forge surface, move gradually, and keep enough compatibility to make the first migration leg survivable.[1][3][4]

As of 2026-04-23T00:02:20Z UTC, the current upstream signal is Forgejo v15.0, released on 2026-04-16 as the project's 100th release and a Long Term Support release. The release notes give v15 support through 2027-07-15, while the previous LTS line, v11.0, remains supported through 2026-07-16 to give operators an upgrade runway.[1][2] That matters more than a feature checklist. A self-hosted forge is a system of record. If the release clock is unclear, the migration becomes a private maintenance bet.

A packed FOSDEM 2024 lecture hall with an audience facing a speaker at the front of the room. — FOSDEM 2024 in Brussels, photographed by Iopensa. Forgejo's adoption story belongs to this public infrastructure culture: code forges are social systems before they are feature matrices.[8]

The shallow migration is a mirror. Push code into a new remote, tell contributors there is another URL, and leave the real workflow somewhere else. That can be a useful start, but it does not test the thing Forgejo actually wants to replace. The real test begins when pull requests, issue templates, branch protection, packages, Actions runners, access tokens, backup policy, and admin routines move onto the same owned surface.[3][4][5]

Codeberg shows the public-instance version of that argument. Its FOSDEM stand page describes Codeberg as a nonprofit providing Git hosting, CI/CD, and Pages for free and open-source projects, and says Codeberg has hosted the Forgejo project since December 2022. The same page frames Forgejo federation as a path away from single points of failure, connecting public and self-hosted instances and, eventually, other forges.[6] For a team deciding whether to self-host, that is the correct framing: Forgejo is strongest when treated as infrastructure with governance and interoperability stakes, not as a cheaper repository screen.

Start With The Ownership Boundary

The first adoption question is not "Can Forgejo import our repositories?" It can. The better question is "Which collaboration contracts are we willing to operate ourselves?" Repository storage is the easy part. The hard parts are identity, project history, CI execution, incident response, storage growth, abuse handling, and upgrade discipline.

Forgejo's installation documentation exposes those boundaries quickly. A binary install means installing git and git-lfs, creating a dedicated git user, assigning data directories such as /var/lib/forgejo, setting configuration under /etc/forgejo/app.ini, choosing a database, and putting the service under systemd or an equivalent supervisor.[3] SQLite can be enough for small installations, but the minute a team adds heavy LFS, package storage, or many repositories, the owner has to think like an operator rather than a tool evaluator.[3]

That is why the right first rollout is a pilot with a real repository, not a toy demo. Pick one project with active pull requests, at least one release artifact, two or three regular reviewers, and one nontrivial workflow. Mirror the code first. Then move issue intake, review, and one CI path. If the team cannot explain who owns runner capacity, backups, admin access, and offboarding after that pilot, the migration is still only a mirror.

The Release Clock Is Part Of The Product

Forgejo publishes stable releases on a fixed quarterly schedule. The schedule page lists v14.0 with a 2026-01-15 release date and 2026-04-30 end of life, v15.0 LTS with a 2026-04-16 release date and 2027-07-15 end of life, and future quarterly trains already mapped into 2027.[2] That is a strong signal for platform teams because it gives them a calendar for change windows, test instances, and patch policy.

The v15 release also shows where the project is moving. It adds repository-specific access tokens, improves release-list responsiveness, supports editing Git notes from pull-request commit views, and expands Forgejo Actions with reusable workflow expansion, OpenID Connect, simpler runner registration, and ephemeral runners.[1] Those are not flashy features in isolation. Together, they point toward a forge that is trying to carry more of the collaboration and deployment surface without pretending hosted SaaS convenience comes for free.

The adoption consequence is simple: do not start on a dead-end branch. A team on the v11 LTS line has a short runway to v15. A team starting fresh after April 2026 should treat v15 as the default baseline unless a package channel forces a temporary constraint.[1][2] Build the pilot around the release line you intend to operate for a year, then document the next upgrade window before the service becomes politically hard to move.

Actions Compatibility Is A Lane, Not A Free Pass

Forgejo Actions is the tempting migration bridge because many organizations already have YAML workflows. The docs are careful about the boundary. The reference says GitHub Actions documentation can help when Forgejo does not document a key, but GitHub Actions and Forgejo Actions are not the same and workflows may need changes.[4] The administrator guide says Actions is enabled by default as of Forgejo v1.21 and can be disabled in app.ini.[4]

That is the right mental model: compatibility is a lane, not a contract of identical behavior. Audit every workflow that uses hosted-runner assumptions, GitHub-specific API calls, third-party marketplace actions, cache behavior, OIDC claims, and long-lived deployment secrets. Then decide which workflows should run on Docker labels, host runners, restricted ephemeral runners, or outside Forgejo altogether.[1][4]

The v15 Actions changes make that audit more worthwhile. Reusable workflow expansion reduces the old compromise where a referenced workflow could collapse into a hard-to-read setup log, and OIDC gives teams a path away from static deployment tokens when third-party systems support federation.[1] Ephemeral runners help advanced operators avoid reusing runner credentials after a job completes.[1] Those are real improvements, but they are also operational duties. The team now owns the runner fleet, the labels, the network path, and the blast radius of a compromised workflow.

Backup And Upgrade Are The Governance Test

Forgejo's upgrade guide is blunt in the way infrastructure docs should be. It says to perform a full backup before upgrading, with a synchronized point-in-time snapshot as the reliable method, and it recommends verification afterward with forgejo doctor check --all --log-file /tmp/doctor.log plus a manual web-interface checklist.[5] It also states that upgrades from Gitea are supported through Gitea v1.22 in two steps: first to Forgejo v10.0.x, then to any Forgejo version greater than v10.[5]

That turns migration into a governance test. If a team wants to leave a commercial forge because it wants more control, the team has to show that control in boring places: restoration drills, admin role review, runner isolation, storage accounting, upgrade rehearsals, and a written rollback path. The moral case for ownership collapses quickly if the owned forge cannot be restored after a failed upgrade or if only one person knows where the app.ini and database snapshots live.

There is a useful pattern here. Treat Forgejo like an internal platform with an SLO, not like a sidecar service. Define a restore objective. Keep an off-host backup. Run a staging upgrade before LTS cutover. Track Actions runner versions separately from the Forgejo application. Keep external identity configuration under review. Document the policy for abandoned repositories, spam, and user removal. Those tasks sound unglamorous because they are the work that turns a forge into infrastructure.

The External Signal Is Gradual Migration

The strongest outside adoption signal is not a wave of dramatic abandonments. It is gradual dual-running by projects that already understand source infrastructure. Phoronix reported on 2026-02-16 that Gentoo had begun using Codeberg as an alternative contribution path while treating the move as gradual, with the ebuild repository first and broader migration later. The same report notes that Codeberg is based on Forgejo and hosted in Germany as a nonprofit.[7]

That kind of move is more informative than a clean-room benchmark. A mature project does not migrate because a feature matrix looks tidy. It migrates by testing whether contributors can still submit changes, whether maintainers can review without losing context, and whether the new surface can coexist with existing canonical infrastructure long enough to earn trust.[7]

For smaller teams, the lesson is to copy the shape rather than the politics. Start with a mirror and a contribution pilot. Move one workflow class. Decide whether package registry, releases, and wiki content belong in the first phase or the second. Keep GitHub or another forge as a read-only or fallback surface until the team has evidence that restores, upgrades, and contributor onboarding work under pressure.

When Forgejo Fits

Forgejo fits teams that want to own the collaboration layer and are ready to operate it. It fits open-source projects that care about non-profit public infrastructure, organizations that need a private forge without buying a larger platform, and engineering groups that can accept some workflow edits in exchange for a more controllable code-hosting surface.[1][4][6]

It fits less well when the team mainly wants a zero-ops GitHub clone, relies deeply on hosted-runner economies and marketplace actions, or cannot assign a durable owner for upgrades and backups. In that case, Forgejo will not fail because it is too small. It will fail because the team asked a self-hosted forge to behave like a vendor-run service while removing the vendor.

The practical migration sequence is therefore disciplined. Use v15 LTS as the baseline. Mirror first. Move a real repository's pull-request path second. Audit Actions third. Add backups and restore drills before widening the service. Treat federation as strategic direction rather than a day-one dependency. If those steps hold, Forgejo becomes more than an escape hatch. It becomes the owned forge between a static mirror and a full internal platform.

cronfeed.work