What happens when three tools look almost identical on the surface but behave completely differently the moment your team grows past a dozen people? That question sits at the heart of the Gitea vs Forgejo vs GitLab decision. All three host Git repositories, open pull requests, and run pipelines. Yet the choices baked into their architecture, how many moving parts they need, how they handle storage, and who controls the roadmap, will shape your operating costs and your team’s daily friction for years. Picking wrong in 2027 is not a disaster you can’t fix, but it is a migration you’d rather avoid.
Why the Fork History Still Matters in 2027
The short version: Forgejo is a hard fork of Gitea, created in 2022 after Gitea’s governance moved to a for-profit company, Gitea Ltd. A community of contributors, anchored by the German non-profit Codeberg e.V., decided they wanted a project governed by a foundation rather than a company. That single governance decision is the root of nearly every downstream difference you’ll notice today.
Why should an infrastructure lead care about governance? Because governance predicts release cadence, how features get accepted, and what happens when a commercial interest conflicts with a community one. When you self-host a forge, you’re not just adopting code. You’re adopting a decision-making process you’ll live with for the life of the deployment.
The practical consequence is that Gitea and Forgejo have diverged. They share a common ancestor and a similar shape, but their CI systems, licensing, and feature priorities have drifted apart. Treating them as interchangeable because they “look the same” is the most common mistake teams make.
The Deployment Model: One Binary vs a Small Fleet
This is the architecture decision that hits your budget and your on-call rotation first.
Gitea and Forgejo both ship as a single Go binary with an embedded SQLite option, while still supporting external databases like MySQL, PostgreSQL, and MSSQL. You download a binary, point it at a config file, and it runs. For a small team, that means one process on one modest VM. Backups are a database dump plus a data directory. Upgrades are swapping a file.
GitLab is a different animal. It’s a Ruby on Rails monolith surrounded by supporting services: Sidekiq for background jobs, PostgreSQL, Redis, and Gitaly for Git storage. Self-managed GitLab typically arrives as an Omnibus package or a Helm chart, and the official guidance publishes reference architectures for different scale tiers. You are, in effect, operating a small platform.
| Dimension | Gitea | Forgejo | GitLab |
|---|---|---|---|
| Core runtime | Single Go binary | Single Go binary | Rails monolith plus services |
| Database | SQLite or external | SQLite or external | PostgreSQL |
| Git storage | Local disk | Local disk | Gitaly (gRPC service) |
| Typical footprint | 1 VM | 1 VM | Multiple nodes |
| Upgrade style | Swap binary | Swap binary | Orchestrated migration |
Neither model is “better” in the abstract. A single binary is a gift to a five-person team and a limitation to a five-thousand-person org. A service fleet is overkill for a startup and a necessity for an enterprise with compliance requirements. If you want to understand how that single-binary philosophy compares with other lightweight deployment patterns, the tradeoffs echo the ones in this breakdown of serverless computing architecture and event-driven functions, where operational simplicity competes directly with control.
Gitaly and the Storage Abstraction Question
Here’s a detail that separates GitLab from the other two in a way that matters at scale: Gitaly. GitLab abstracts all Git repository access behind a gRPC service. Instead of Rails processes reaching directly into a filesystem, they talk to Gitaly, which owns the repositories.
That abstraction buys real things. You can move repositories to dedicated storage nodes. You can isolate Git traffic from web traffic. You can scale Git operations separately from the rest of the app. For a large organization with heavy clone traffic and strict availability targets, that separation is worth the complexity.
Gitea and Forgejo skip that layer entirely. Git lives on local disk, served directly. This is faster to set up and easier to reason about, and for most teams under a few hundred users it performs perfectly well. The catch is that scaling Git storage independently isn’t really a knob you turn. You scale the whole box, or you shard across instances.
If you’re weighing storage strategy more broadly, the same flat-namespace thinking appears in this piece on object storage architecture and flat namespaces at scale — useful context when you’re deciding whether repository data belongs on local disk or behind an abstraction layer.
CI/CD: Three Different Bets
Continuous integration is where the three projects genuinely part ways, and it’s often the deciding factor.
GitLab ships GitLab CI as a first-class citizen, defined in a `.gitlab-ci.yml` file, backed by runners you register and scale. It’s mature, deeply integrated, and the reason many teams choose GitLab in the first place. The cost is that runners are another fleet to operate. (GitLab CI/CD documentation)
Forgejo introduced Forgejo Actions, a CI system compatible with GitHub Actions syntax. That compatibility is a strategic bet: teams can often reuse workflow files they already have. Since the fork, Forgejo’s Actions implementation has diverged from Gitea’s own version, so the two are no longer the same product under the hood.
Gitea has its own Actions implementation as well, but the compatibility story and feature set differ from Forgejo’s. This is exactly the kind of detail that changes between releases, so check each project’s current release notes rather than trusting a comparison table written a year ago.
A practical tip from teams running these in production: decide early whether your CI lives inside the forge or beside it. Many organizations run Gitea or Forgejo for code hosting and pair it with an external CI system. That decoupling gives you freedom to change either piece independently. The same architectural reasoning shows up in this comparison of Kafka vs RabbitMQ for 2026 throughput and use cases — the lesson is that coupling your messaging layer to your application layer is convenient until you need to swap one.
Licensing as an Architecture Decision
Licensing isn’t legal paperwork bolted on at the end. It’s an architecture decision, because it determines what you can redistribute, modify, and build a product on top of.
Gitea is licensed under MIT, a permissive license that lets you embed it in commercial offerings with minimal obligations. Forgejo relicensed to GPLv3+ around 2023, a copyleft license that requires derivative works to stay open. GitLab splits into a Community Edition under an open-source license and an Enterprise Edition with proprietary features.
For an internal-only deployment, license choice barely matters. For a company that ships an appliance, resells hosting, or embeds a forge in a product, it matters enormously. Choosing Forgejo because you like its governance and then discovering GPLv3+ obligations conflict with your distribution model is a painful, expensive surprise. Read the license before you read the feature list.
Governance, Roadmaps, and the Codeberg Proof
Governance sounds abstract until you need a feature or a fix. Gitea’s roadmap is steered by Gitea Ltd., a commercial entity. Forgejo’s is steered by Codeberg e.V., a German non-profit, with community input.
The best evidence that Forgejo’s model works in production is Codeberg.org itself, which runs Forgejo as its production forge. That makes it one of the largest public Forgejo deployments and a real-world reference for operational maturity. When a non-profit runs the software for a large public user base, you get a live stress test you can learn from. (Forge (software)))
GitLab’s governance is corporate, and its roadmap is shaped by its commercial strategy. That’s not a criticism; it’s a tradeoff. Corporate stewardship tends to produce polished enterprise features and predictable support. Foundation stewardship tends to produce community responsiveness and resistance to vendor lock-in. Neither is universally right.
How to Decide: A Practical Sequence
Rather than starting with feature checklists, work through the constraints in order. This sequence saves teams from the classic mistake of picking a tool and discovering a blocker later.
- Define your scale ceiling. Count users, repositories, and expected clone traffic for the next three years. Under a few hundred users, the single-binary model is almost always the right call.
- Settle your CI strategy. Decide whether pipelines live inside the forge or in a separate system. This single choice eliminates options fast.
- Check licensing against your distribution model. If you redistribute or embed the software, read the license text before anything else.
- Assess your operational capacity. Be honest about whether your team can run a multi-service platform. A GitLab deployment nobody maintains is worse than a Gitea box that just works.
- Test the migration path. Spin up all three in a lab, import a real repository with its history, and run a pipeline. An afternoon of testing beats a month of regret.
- Review governance fit. Decide whether you want a company or a foundation steering your roadmap.
The most common mistakes are predictable. Teams underestimate the operational load of a service fleet. They assume Gitea and Forgejo are drop-in equivalents. They pick based on a blog comparison from two years ago. And they forget that backup and recovery differ enormously between a single binary and a distributed platform — a topic worth studying through resources on cloud disaster recovery architecture for systems that must survive failure, because your restore procedure is part of your architecture, not an afterthought.
Conclusion
The Gitea vs Forgejo vs GitLab question in 2027 isn’t really about which tool has more features. It’s about which set of architectural tradeoffs fits your team’s size, skills, and obligations. Gitea offers a permissive-licensed, single-binary forge backed by a commercial steward. Forgejo offers a near-identical shape with foundation governance, copyleft licensing, and a proven public deployment behind it. GitLab offers a full platform with service-oriented architecture, a mature CI system, and the operational weight that comes with it.
Start with your constraints, not the feature matrix. Test with real repositories. Read the licenses. And state the date of any comparison you rely on, because these projects move fast and yesterday’s parity is tomorrow’s divergence.
FAQ
Is Forgejo a fork of Gitea?
Yes. Forgejo is a hard fork of Gitea, created in 2022 after Gitea’s governance moved to a for-profit company. It is stewarded by the German non-profit Codeberg e.V. and has since diverged in CI implementation, licensing, and feature priorities.
Can I migrate from Gitea to Forgejo easily?
Because they share a common codebase ancestor and the same single-binary architecture, migration is generally straightforward: swap the binary, point it at the same database and data directory, and verify. Always run it in a lab with a copy of production data first, and check current release notes for schema changes.
Which is easier to self-host, Gitea or GitLab?
Gitea and Forgejo are considerably easier to self-host for small teams. Both run as a single Go binary with an embedded SQLite option. GitLab requires PostgreSQL, Redis, Sidekiq, and Gitaly, typically deployed via Omnibus or Helm, which means more nodes and more operational work.
What is Gitaly and why does it matter?
Gitaly is GitLab’s gRPC service that owns and abstracts all Git repository access. It lets you scale and isolate Git storage separately from the web application, which matters at large scale. Gitea and Forgejo serve Git directly from local disk instead.
Does Forgejo Actions work with GitHub Actions workflows?
Forgejo Actions is designed to be compatible with GitHub Actions syntax, which lets teams reuse many existing workflow files. Compatibility is not absolute and has diverged from Gitea’s implementation since the fork, so validate your specific workflows before migrating.
What license does each project use?
Gitea uses the permissive MIT license. Forgejo relicensed to GPLv3+ around 2023, which carries copyleft obligations for derivative works. GitLab offers a Community Edition under an open-source license plus a proprietary Enterprise Edition.
