Three self-hosted git platforms are pulling developers in different directions in 2026, and the split is no longer just about features. Gitea keeps its 512MB-RAM footprint and MIT license. Forgejo, the community fork born out of a 2022 governance dispute, just shipped its v15.0 LTS branch and picked up a national government as a customer. GitLab Community Edition still wants 16GB of RAM and eight vCPUs just to boot comfortably, but it throws in a full DevSecOps suite for the trouble. The Netherlands government chose one of these three to escape US jurisdiction over its source code. Gentoo Linux picked another after a dispute with GitHub over Copilot. This comparison walks through the specs, the pricing, the security record, and the real migrations happening right now so you can pick the right one for your team.
Why Self-Hosted Git Is Having a Moment in 2026
Self-hosted git forges used to be a niche concern for enterprises with strict compliance requirements. That changed through 2025 and 2026 as three separate pressures converged: rising GitHub pricing for larger orgs, growing unease about AI training on hosted code, and a wave of digital-sovereignty policy in Europe. The most visible example is the Dutch government’s launch of code.overheid.nl, a self-hosted Forgejo instance built explicitly to keep government source code out of US-controlled infrastructure and free for use by any government organization.
Around the same time, Gentoo Linux announced an official presence on Codeberg in February 2026, with maintainers citing GitHub’s push toward mandatory Copilot integration as a motivating factor. These aren’t isolated incidents. They’re evidence that the calculus around where to host source code has shifted, and Gitea, Forgejo, and GitLab CE are the three platforms absorbing that shift. Each targets a different point on the spectrum between minimal footprint and maximal feature set, and understanding where they diverge is the difference between a smooth migration and a six-month infrastructure headache.
The comparison also matters because these projects move fast. Gitea shipped patch releases in April, May, June, and August 2026 alone. Forgejo cut its 15.0 LTS branch in March 2026 and had already moved development toward a v16 line with new Actions APIs by mid-year. GitLab pushed a coordinated security release across three version branches in July 2026. None of these platforms are static, and a comparison written even six months ago would already be out of date on version numbers, though the underlying architectural tradeoffs remain stable.
There’s also a simpler, less political reason self-hosted git keeps growing: cost predictability. A team of 40 engineers paying for GitLab.com Premium or a comparable hosted seat-based plan is locked into a bill that scales with headcount forever. The same team running Gitea or Forgejo on a single mid-tier VPS pays a fixed infrastructure cost that barely moves whether the team is 10 people or 100, as long as repository size and CI usage stay within reason. That math becomes especially attractive for bootstrapped startups, university labs, and open-source foundations operating on tight budgets, none of which show up in headline-grabbing government migration stories but collectively represent a much larger share of new self-hosted deployments in 2026.
What Is Gitea? The Lightweight Original
Gitea is a self-hosted git service written in Go, designed from the outset to run on minimal hardware. Its own installation documentation lists a bare minimum of one CPU core, 512MB of RAM, and 100MB of disk space plus whatever space your repositories need. Recommended production specs bump that to two or more cores and 2GB or more of RAM with SSD storage. It’s released under the MIT license, meaning you can fork it, embed it in a commercial product, or run it without ever contacting the Gitea team.
As of September 2026, Gitea’s latest stable release is v1.27.1, which shipped in early August 2026 with security fixes and improvements across Gitea Actions, repository workflows, authentication, and pull requests, following the v1.26.x line that ran from April through June 2026. The go-gitea/gitea GitHub repository sits at roughly 57,500 stars as of late August 2026, making it one of the most-starred Go projects on the platform. Gitea supports PostgreSQL 12+, MySQL 8.0+, MariaDB 10.4+, built-in SQLite, and MSSQL 2012 SP4+, giving self-hosters flexibility most competitors don’t offer at this weight class.
Gitea’s governance sits with Gitea Ltd., a commercial entity that also sells Gitea Enterprise and a hosted Gitea Cloud product. That commercial layer is precisely what triggered the Forgejo fork in late 2022, and it’s still the dividing line between the two projects in 2026.
What keeps Gitea attractive despite the governance controversy is how little friction it takes to get running. A single Docker container with an SQLite backend can be online in under five minutes, and the web-based setup wizard walks through database configuration, admin account creation, and basic server settings without ever touching a config file by hand. Gitea also ships a built-in package registry supporting npm, Maven, NuGet, PyPI, and several other ecosystems out of the box, letting small teams consolidate artifact hosting alongside source control without standing up a separate service. For a huge swath of self-hosters, that combination of low resource requirements and immediate usability outweighs any discomfort with the commercial governance model behind it.
What Is Forgejo? The Community Fork That Grew Up
Forgejo started as a hard fork of Gitea in late 2022, created by contributors who wanted a git forge governed by a nonprofit rather than a company. It’s hosted primarily on Codeberg rather than GitHub, and it’s licensed under AGPL, a copyleft license that requires anyone modifying and running Forgejo as a network service to share their changes. That’s a meaningfully different legal posture than Gitea’s permissive MIT terms, and it’s a big part of why organizations with strong open-source commitments gravitate toward Forgejo specifically.
Forgejo’s release schedule shows v15.0 as its current LTS branch, with a cut branch date of March 26, 2026, a release date of April 16, 2026, and end-of-life support running until July 15, 2027. Development has continued past that LTS baseline, too. Forgejo’s own download documentation already references container images at the 16.0.3 build, and the project’s May 2026 monthly report described v16 development work including new Actions APIs for artifacts and workflow logs, plus an “Authorized Integrations” feature for JWT-based authentication from external systems like GitHub Actions, GitLab CI/CD, and AWS.
Because Forgejo lives on Codeberg rather than GitHub, GitHub star counts undercount its real reach. Mirror repositories show around 11,000 stars, far below Gitea’s 57,500, but that number says more about where each project chooses to host its primary repository than about actual adoption. Codeberg itself is the better adoption signal, and it’s grown from roughly 300,000 repositories and 200,000 registered users in November 2025 to over 650,000 projects and more than 390,000 users by June 2026, according to Wikipedia’s Codeberg entry. Forgejo also has experimental ActivityPub federation work underway, aiming to let separate Forgejo instances interact the way Mastodon servers do across the fediverse, though this remains an in-progress feature rather than a shipped, production-ready capability.
Forgejo’s development process also runs differently from Gitea’s day to day. Decisions go through public RFC-style discussions on Codeberg rather than being made unilaterally by a commercial entity’s core team, and the project publishes monthly progress reports summarizing merged features, in-flight work, and governance votes. That transparency is a deliberate design choice, not an accident, and it’s the exact opposite of the closed-door commercial pivot that led to the fork in the first place. For teams evaluating long-term platform risk, that visible decision-making process is arguably as valuable as any individual feature comparison in this article.
What Is GitLab Community Edition? The All-in-One Option
GitLab Community Edition is the free, source-available tier of GitLab’s broader DevOps platform. Unlike Gitea and Forgejo, which focus narrowly on git hosting plus lightweight CI, GitLab CE bundles issue tracking, a built-in container and package registry, GitLab Pages for static site hosting, a wiki, and a CI/CD engine that’s considerably more mature than either of its lighter competitors. That breadth comes at a real infrastructure cost. GitLab’s official installation requirements call for a baseline of 8 vCPUs and 16GB of RAM for a single-node deployment, with a documented minimum of 8GB RAM in constrained environments, plus at least 40GB of storage for the application node and 5 to 12GB for the PostgreSQL database alone.
GitLab patched 13 security vulnerabilities across Community and Enterprise editions in a coordinated release on July 29, 2026, shipping fixes in versions 19.2.1, 19.1.3, and 19.0.5. The flaws reportedly touched data exposure, CI/CD pipeline manipulation, and server availability, underscoring that a platform this feature-rich also carries a larger attack surface to patch and monitor. GitLab uses PostgreSQL exclusively as its backing database, a contrast with Gitea and Forgejo’s support for four different database engines.
Where Gitea and Forgejo are built by volunteers and small commercial teams optimizing for minimal footprint, GitLab is built by a public company optimizing for enterprise DevSecOps consolidation. That’s not a knock on either approach, it’s a different target market, and the specs table below makes the tradeoff concrete.
GitLab has also leaned hard into AI tooling as a differentiator through 2026. Its Duo AI assistant, bundled into paid plans with a credit allotment per user per month, adds code suggestions, merge request summarization, and vulnerability explanation directly inside the platform. Pricing pages for GitLab’s paid tiers in 2026 list compute-minute allotments of 10,000 minutes per user per month on Premium and up to 50,000 on higher tiers, alongside roughly $24 in Duo AI credits per user per month bundled into some plans. Neither Gitea nor Forgejo ship a comparable first-party AI assistant as of September 2026, which is either a non-issue or a dealbreaker depending on how central AI-assisted code review has become to a given team’s workflow.
Gitea vs Forgejo vs GitLab CE: Full Specs Comparison
The table below lines up the core technical specifications across all three platforms as of September 2026, pulled from each project’s own documentation and release notes.
| Specification | Gitea | Forgejo | GitLab CE |
|---|---|---|---|
| License | MIT | AGPL-3.0-or-later | Open-core, source-available CE |
| Latest version (Sept 2026) | v1.27.1 | 15.0 LTS / 16.0.3 builds | 19.2.1 |
| Latest release date | Early August 2026 | April 16, 2026 (LTS) | July 29, 2026 |
| Written in | Go | Go (Gitea fork) | Ruby on Rails, Go |
| Primary host | GitHub / self-hosted | Codeberg / self-hosted | GitLab.com / self-hosted |
| Repo star count | ~57,500 | ~11,000 (GitHub mirror) | ~24,000 (gitlab-org mirror) |
| Minimum CPU | 1 core | 1 core | 8 vCPUs (baseline) |
| Minimum RAM | 512MB | 512MB–1GB | 8–16GB |
| Recommended RAM | 2GB+ | 2GB+ | 16GB+ |
| Minimum disk | 100MB + repos | ~5GB | 40GB+ (app) + 5–12GB (DB) |
| Databases supported | PostgreSQL, MySQL, MariaDB, SQLite, MSSQL | Same as Gitea | PostgreSQL only |
| Built-in CI/CD | Gitea Actions | Forgejo Actions | GitLab CI/CD |
| Container registry | Yes | Yes | Yes (deeper package registry too) |
| Federation (ActivityPub) | No | Experimental | No |
| Governance | Gitea Ltd. (commercial) | Nonprofit / community | GitLab Inc. (public company) |
The RAM gap is the single most consequential line in that table for anyone choosing a platform on a budget. Gitea’s recommended 2GB versus GitLab’s 16GB baseline is an 8x difference, and it’s the reason so many homelab operators and small teams default to Gitea or Forgejo without a second thought. It’s also why GitLab remains the default pick for organizations that already run substantial infrastructure and want one platform instead of five.
The Gitea-Forgejo Fork: What Actually Happened
The 2022 Governance Dispute
Forgejo didn’t emerge from a technical disagreement. It emerged from a governance one. Gitea’s original open, community-driven development model shifted when its lead maintainers formed Gitea Ltd., a commercial company, without what critics described as adequate transparency or community consultation about how that would affect the project’s direction and intellectual property. A group of contributors responded by forking the entire codebase in late 2022, moving it to Codeberg, adopting AGPL licensing to guarantee the fork itself couldn’t be re-commercialized in the same way, and naming it Forgejo, a Latin-rooted term meaning “forge.”
That single decision shaped nearly everything downstream. Forgejo’s AGPL license is stickier than Gitea’s MIT terms specifically because the fork’s founders wanted to prevent a repeat of what they viewed as a bait-and-switch on governance. Codeberg’s nonprofit structure, run as a registered association (Codeberg e.V.) rather than a company, gave the fork an institutional home that couldn’t independently decide to commercialize.
The technical split was almost seamless precisely because Forgejo forked the entire codebase rather than rewriting from scratch. In the earliest months, the two projects were functionally identical aside from branding and licensing, and migration between them was, and still is, a matter of swapping a Docker image tag and pointing it at the same data directory. That low switching cost is itself a strategic asset for Forgejo: it means the fork never had to win users away from Gitea on features alone, it only had to offer a governance model some users preferred while functional parity did the rest of the work.
Where the Projects Stand in 2026
Four years on, both projects are healthy, but they’ve drifted into distinct niches. Gitea kept its permissive license and broader commercial ecosystem, including Gitea Enterprise and Gitea Cloud, which appeals to companies that want paid support without copyleft obligations. Forgejo built a reputation for governance-conscious organizations, particularly in Europe, where the Netherlands government’s adoption is the clearest validation yet that the fork’s founding premise, that community governance matters as much as code quality, resonated with a real constituency. Several self-hosting guides published in 2026 now describe Forgejo as the default recommendation for new deployments specifically because of that governance model, while acknowledging Gitea remains a perfectly reasonable choice for anyone already running it successfully.
It’s worth being precise about what “default recommendation” means in practice, because it doesn’t mean Gitea is losing ground in absolute terms. Gitea’s star count, release cadence, and Docker pull volume all kept climbing through 2026 alongside Forgejo’s. The two projects aren’t in zero-sum competition the way, say, Bun and Deno compete for the exact same runtime niche. They’re serving overlapping but distinct communities: Gitea for teams that don’t weigh governance heavily and want the broadest commercial support ecosystem, Forgejo for teams that do weigh governance heavily and are willing to trade a smaller support ecosystem for that guarantee.
Performance and Resource Usage Benchmarks
Specs sheets tell part of the story, but real-world resource consumption is what actually determines whether a $5-a-month VPS can run your git forge. Gitea’s own documentation lists idle memory usage in the 50MB to 150MB range for small instances, a figure independently echoed by third-party comparison writeups benchmarking Gitea against GitLab in production settings. That’s consistent with community reports on forums like Reddit’s r/Gitea and r/raspberry_pi, where operators describe running Gitea comfortably on Raspberry Pi hardware with 512MB to 1GB of RAM after a year of continuous uptime, with the application itself settling around 512MB of resident memory including its database.
Forgejo, sharing Gitea’s Go codebase and architecture at the time of the fork, exhibits nearly identical resource behavior. Self-hosting guides treat the two as drop-in equivalents for capacity planning purposes, and Codeberg’s own scaling notes describe the platform handling hundreds of thousands of users and projects on a multi-node deployment rather than requiring GitLab-style vertical scaling per instance.
GitLab’s resource profile is a different animal entirely. Beyond the 16GB baseline RAM requirement, GitLab’s own reference architecture documentation describes progressively larger multi-node topologies for anything beyond a few hundred users, splitting out dedicated Gitaly (git storage), Sidekiq (background jobs), and PostgreSQL nodes at scale. Teams evaluating GitLab CE need to budget not just for the initial 16GB single-node minimum but for the operational overhead of monitoring and scaling a genuinely distributed system as usage grows, which is a meaningfully different total cost of ownership than a single Gitea or Forgejo container that can run comfortably on a $6-a-month cloud instance indefinitely.
CI/CD Compared: Gitea Actions vs Forgejo Actions vs GitLab CI/CD
CI/CD is where GitLab’s maturity gap over the lightweight forges is most obvious, though both Gitea and Forgejo have closed ground fast. Gitea Actions uses YAML workflow syntax deliberately compatible with GitHub Actions, so teams migrating away from GitHub can often reuse existing .github/workflows files with minimal changes. Gitea’s 1.26.0 release added concurrency group syntax, the ability to rerun failed jobs individually, per-runner pause and disable controls, and improved artifact handling, while 1.26.1 added an event.schedule context for cron-triggered runs and fixed concurrency-group leaks across branches.
Forgejo Actions inherited the same GitHub-compatible foundation but has pushed further on integration flexibility. The “Authorized Integrations” feature under development for the v16 line lets external systems, including GitHub Actions, GitLab CI/CD, and AWS, authenticate via JWT tokens, aimed at organizations running hybrid CI setups during a migration window rather than forcing an all-or-nothing cutover. Forgejo has also been adding dedicated Actions APIs for artifacts and workflow logs, closing functional gaps with more established CI platforms.
GitLab CI/CD remains the most fully-featured of the three by a wide margin. It’s a first-class citizen of the platform rather than a bolted-on feature, with native support for multi-stage pipelines, built-in SAST and dependency scanning (more extensively in paid tiers), auto-DevOps templates, and deep integration with GitLab’s container and package registries. For teams that need integrated security scanning without stitching together separate tools, that built-in depth is the strongest argument for GitLab CE over either lightweight alternative, even accounting for the heavier infrastructure bill.
Runner architecture is another practical difference worth flagging before you commit to any of the three. Gitea and Forgejo both use a lightweight external runner binary (act_runner for Gitea, forgejo-runner for Forgejo) that connects outward to the main instance, which means runners can live on entirely separate, disposable machines and scale horizontally without touching the core application’s configuration. GitLab’s Runner architecture works similarly at a conceptual level, registering runners against a GitLab instance or group, but GitLab’s runner fleet management, tagging, and autoscaling integrations with Kubernetes and cloud providers are considerably more developed, reflecting years of enterprise CI/CD investment that the younger Actions implementations in Gitea and Forgejo haven’t yet matched. Teams that already run a dedicated Jenkins or GitHub Actions pipeline alongside their git hosting should weigh whether consolidating onto one of these forge-native CI systems is worth the migration effort versus keeping CI and hosting decoupled.
Security Track Record: CVEs and Patches in 2026
No self-hosted platform is immune to vulnerabilities, and 2026 delivered notable disclosures for both ends of this comparison. Gitea’s 1.26.0 release in April 2026 patched three CVEs simultaneously: CVE-2026-28737, a stored XSS vulnerability in Gitea’s 3D file viewer triggered through the glTF extensionsRequired field, alongside CVE-2026-22555 and CVE-2026-27780. More seriously, a separate flaw tracked as CVE-2026-27771 was disclosed by security firm NoScope and covered by SecurityWeek, describing an access control issue that could have allowed unauthenticated attackers to pull private container images from more than 30,000 exposed Gitea deployments before it was patched.
GitLab’s July 2026 security release addressed 13 separate vulnerabilities across Community and Enterprise editions simultaneously, spanning data exposure risks, CI/CD pipeline manipulation vectors, and server availability issues, patched in the coordinated 19.2.1, 19.1.3, and 19.0.5 releases. That’s a substantially larger single-release vulnerability count than either lightweight forge disclosed in any comparable window in 2026, which tracks with GitLab’s larger codebase and feature surface. Forgejo, sharing much of Gitea’s core, inherited the same underlying fixes where the vulnerable code predated the 2022 fork, and has continued shipping its own security patches within its 15.0 LTS branch independently.
The practical takeaway isn’t that any one platform is inherently less secure. It’s that patch cadence and exposure monitoring matter regardless of which forge you choose, and self-hosting means that responsibility sits entirely with your own team rather than a managed provider’s security operations center.
That responsibility argues strongly for a few basic operational habits regardless of which platform you pick: subscribing to each project’s security mailing list or RSS feed, enabling automatic minor-version updates where your risk tolerance allows it, and never exposing an admin panel or container registry directly to the public internet without authentication in front of it. The CVE-2026-27771 disclosure specifically involved an access-control gap on container registries, which is precisely the kind of secondary surface area that’s easy to overlook when the primary focus during setup is getting git push and git pull working.
Pricing Breakdown: Free vs Paid Tiers
All three core platforms are free to self-host, but the paid tiers around them differ substantially in what they unlock and how they’re priced.
| Tier | Gitea | Forgejo | GitLab CE / Self-Managed |
|---|---|---|---|
| Free self-hosted | $0 (MIT, unlimited use) | $0 (AGPL, unlimited use) | $0 (Community Edition) |
| Paid support tier | Gitea Enterprise (custom pricing) | Community support only | Premium: $29/user/month, billed annually |
| Top tier | Gitea Cloud (hosted, custom pricing) | N/A | Ultimate: custom pricing, industry estimates $99–149/user/month |
| What paid tiers add | Managed hosting, SLA support | N/A | Advanced security scanning, compliance, portfolio management |
GitLab’s official pricing page lists Premium self-managed at $29 per user per month billed annually, while Ultimate pricing has moved to a “contact sales” model, with third-party benchmarking sites estimating real-world enterprise rates somewhere between $99 and $149 per user per month depending on contract size and negotiated terms. That’s a meaningful recurring cost that scales linearly with headcount, in sharp contrast to Gitea and Forgejo, where the software itself never has a per-seat charge regardless of team size. The only cost that scales with Gitea or Forgejo is your own infrastructure bill, and given the RAM requirements discussed above, that bill stays flat and small compared to what a growing GitLab deployment eventually demands.
It’s worth running the actual numbers for a mid-sized team to see how fast that gap compounds. A 50-person engineering org on GitLab Premium self-managed pays roughly $1,450 a month at the $29-per-user list rate, or about $17,400 a year, before factoring in the infrastructure to actually run that 16GB-plus deployment. The same 50-person team on Gitea or Forgejo pays for a single VPS, commonly in the $20-to-$80-a-month range depending on repository size and CI load, or well under $1,000 a year total. That doesn’t make GitLab the wrong choice for that team, since the calculation changes completely if GitLab’s built-in security scanning replaces two or three other paid tools the team would otherwise need. But it does mean the decision should be made with the full annual cost in view, not just the sticker price of “free and open source” versus “$29 a seat.”
Real-World Examples: Who’s Running What in 2026
The Netherlands government’s Forgejo migration. In May 2026, the Dutch government launched code.overheid.nl, a sovereign, self-hosted Forgejo instance built explicitly to keep government source code under domestic legal jurisdiction rather than relying on GitHub. It’s free for any Dutch government organization to use, and migration tooling built around it now supports transferring repositories, issues, pull requests, labels, releases, and wikis either as a one-time import or via continuous mirroring from GitHub.
Gentoo Linux’s move to Codeberg. In February 2026, the Gentoo Linux project announced an official presence on Codeberg, with maintainers citing GitHub’s pressure toward mandatory Copilot integration as a factor in the decision. Gentoo remains a large, high-profile open-source distribution, and its move added meaningful visibility to Forgejo-based hosting within the broader Linux community.
Codeberg as the reference deployment. Codeberg.org is the largest public Forgejo instance in existence and one of the project’s most significant contributors. It grew from roughly 300,000 repositories and 200,000 registered users in November 2025 to more than 650,000 projects and 390,000-plus users by June 2026, demonstrating that Forgejo’s architecture scales to genuinely large, publicly-accessible deployments rather than just small private teams.
Enterprises consolidating on GitLab Ultimate. Organizations with dedicated platform engineering teams and compliance requirements around SAST, DAST, dependency scanning, and container security continue to standardize on GitLab CE paired with Ultimate add-ons specifically because it replaces four or five separate point tools with one integrated suite, even though that consolidation carries the heaviest infrastructure and per-seat licensing cost of the three options here.
Homelab and small-team Gitea deployments. Across self-hosting communities on Reddit and elsewhere, the most common Gitea deployment pattern described in 2026 is a single Raspberry Pi or a $5-to-$6-a-month VPS running Gitea with a MySQL or SQLite backend, serving a handful of personal or small-team repositories indefinitely on well under 1GB of RAM. It’s the clearest illustration of why Gitea and Forgejo dominate the budget-conscious end of this comparison.
Taken together, these five examples span the entire spectrum this comparison is built around, from a single hobbyist repository to a national government’s entire source-code infrastructure. What’s notable is that none of them picked their platform on feature checklists alone. The Dutch government picked Forgejo for jurisdiction and governance. Gentoo picked Codeberg for the same reasons plus a specific dispute over AI tooling. Enterprises pick GitLab for consolidation math that only pencils out above a certain team size. And homelab operators pick Gitea because it’s the smallest, simplest thing that reliably works. Each decision was rational for its context, and that’s the strongest argument against treating this as a single “best overall” comparison rather than a fit-to-use-case one.
Which Platform Fits Which Use Case
The right answer depends heavily on team size, budget, and how much you value integrated tooling versus a minimal footprint. Here’s how the decision typically breaks down in practice.
- Solo developers and homelabs: Gitea, for its rock-bottom hardware requirements and permissive MIT license that removes any licensing ambiguity for personal or small commercial use.
- Open-source communities and governance-conscious teams: Forgejo, specifically because of its nonprofit governance model and AGPL license, which guarantees the platform itself can’t be quietly re-commercialized the way Gitea’s history shows can happen.
- Government agencies and regulated industries with data-sovereignty requirements: Forgejo, following the Netherlands’ precedent, particularly for organizations that need to demonstrate their source code never leaves domestic jurisdiction.
- Enterprises needing integrated DevSecOps: GitLab CE paired with Premium or Ultimate, since bundled SAST, DAST, dependency scanning, and compliance reporting outweigh the higher infrastructure and per-seat costs for teams with dedicated platform budgets.
- Teams also standardizing self-hosted identity and database tooling: pair whichever forge you pick with a self-hosted identity provider like the ones covered in our Keycloak vs Ory vs Zitadel comparison, and a self-hosted schema migration tool such as those in our Flyway vs Liquibase vs Atlas breakdown, to keep the entire toolchain under the same sovereignty and cost model.
- Teams migrating away from GitHub Actions workflows: Either Gitea or Forgejo, since both offer close syntax compatibility with existing .github/workflows files, minimizing the CI rewrite burden during migration.
- Resource-constrained environments (Raspberry Pi, low-cost VPS, edge deployments): Gitea or Forgejo interchangeably, given their near-identical sub-1GB RAM footprints at idle.
- Organizations already running a working Gitea instance: Stay on Gitea. Migrating to Forgejo purely for governance reasons is a valid choice but not an urgent one if the current setup is stable and the commercial licensing terms aren’t a practical concern.
Migration Guide: Moving to a Self-Hosted Git Platform
Migrating an existing GitHub, GitLab.com, or Bitbucket organization to a self-hosted forge follows a broadly similar path regardless of which of the three platforms you choose. Here’s the general sequence.
Before You Migrate
- Inventory every repository, including forks, wikis, issue trackers, CI configuration files, webhooks, and any third-party integrations currently wired into your existing platform.
- Choose your database backend. Gitea and Forgejo support PostgreSQL, MySQL, MariaDB, SQLite, or MSSQL; GitLab CE requires PostgreSQL. Pick PostgreSQL if you want backend flexibility to switch platforms later without a database migration.
- Provision infrastructure sized to your choice: a single small VPS (1–2 vCPUs, 2–4GB RAM) for Gitea or Forgejo, or a properly-sized multi-node setup for GitLab CE per its reference architecture documentation if you’re above a few hundred users.
- Set up TLS certificates and DNS for your self-hosted domain before cutting over any traffic.
Running the Migration
- Install your chosen platform via Docker, which all three officially support and document, using docker pull gitea/gitea, docker pull codeberg.org/forgejo/forgejo:16.0.3, or GitLab’s official Omnibus or Docker image respectively.
- Use each platform’s built-in repository migration tool. Gitea and Forgejo both ship a “New Migration” feature in their web UI that pulls directly from GitHub, GitLab, or Gitea/Forgejo instances, including issues, pull requests, labels, milestones, and releases. GitLab CE includes an equivalent importer for GitHub and other GitLab instances.
- For continuous mirroring during a transition period rather than a hard cutover, configure push or pull mirrors so both the old and new platform stay in sync while your team gradually moves over.
- Migrate CI/CD configuration. If you’re moving from GitHub Actions to Gitea Actions or Forgejo Actions, most .github/workflows YAML files need only minor adjustments given the syntax compatibility both platforms maintain. Migrating to GitLab CI/CD requires a more substantial rewrite into GitLab’s .gitlab-ci.yml format.
- Reconfigure webhooks, deploy keys, and any external integrations (issue trackers, chat notifications, deployment triggers) pointing at your old platform to point at the new one.
- Run both platforms in parallel for at least one full sprint cycle before decommissioning the old one, giving your team time to catch any missed integration or workflow gap.
Teams that have gone through a Bitbucket to GitHub migration or a GitHub to GitLab move in the past will recognize most of this sequence. The main new wrinkle with Gitea and Forgejo is that you’re now responsible for the underlying server, backups, and updates yourself, which is exactly the tradeoff that makes them cheaper and more private but also more operationally demanding than a managed SaaS platform.
After the Cutover
Migration doesn’t end the moment repositories finish importing. Budget time for a handful of follow-up tasks that teams routinely underestimate: verifying that every branch protection rule and required-reviewer policy carried over correctly, since importers don’t always preserve these settings faithfully; re-issuing SSH deploy keys and personal access tokens, since old credentials generally don’t transfer between platforms even when repository history does; and setting up automated backups of your new self-hosted instance immediately, covering both the database and the underlying git repository data on disk. Gitea and Forgejo both support built-in dump commands that package a full instance backup into a single archive, and that backup job should be one of the first things configured on a new instance, not an afterthought scheduled for “later.” Finally, document the new platform’s URL, backup schedule, and update procedure somewhere your whole team can find it, since the operational knowledge that a managed SaaS platform used to hold implicitly now lives with whoever set up the server.
Pros and Cons of Each Platform
Gitea pros: minimal hardware requirements, permissive MIT license, mature GitHub Actions-compatible CI, broad database support, large and active GitHub-hosted community. Gitea cons: commercial governance model that some organizations want to avoid, feature set narrower than GitLab’s integrated DevSecOps suite, past CVEs affecting container registry access controls.
Forgejo pros: nonprofit governance immune to the kind of commercial pivot that triggered its own creation, AGPL license appealing to copyleft-committed organizations, proven at scale via Codeberg’s 650,000-plus projects, growing adoption among sovereignty-focused government deployments. Forgejo cons: smaller commercial support ecosystem than Gitea, ActivityPub federation still experimental rather than production-ready, GitHub star count understates real adoption because its primary home is Codeberg.
GitLab CE pros: the most complete built-in feature set of the three, including native SAST, DAST, dependency scanning, container registry, and package registry, mature CI/CD engine, strong reference architecture documentation for scaling. GitLab CE cons: 8x the recommended RAM footprint of Gitea or Forgejo, PostgreSQL-only database support, Premium and Ultimate pricing scales linearly per user, larger codebase historically associated with a higher volume of disclosed CVEs per release cycle.
The Verdict: Which Self-Hosted Git Platform Wins in 2026
There isn’t a single winner here, and treating this as a horse race misses the point of what each platform is actually optimized for. For solo developers, homelabs, and small teams that just need reliable git hosting with light CI, Gitea remains the pragmatic default: it runs on 512MB of RAM, carries no licensing friction, and has a four-year track record of stable releases. For teams and organizations that care deeply about governance, or that operate under data-sovereignty mandates like the Dutch government’s, Forgejo is the better long-term bet, and its growing adoption curve through Codeberg and now national government infrastructure suggests that bet is paying off.
GitLab CE earns its 8x RAM premium only when an organization actually needs the integrated DevSecOps suite that comes with it, replacing what would otherwise be four or five separate tools for security scanning, package management, and CI/CD orchestration. If your team is evaluating that tradeoff purely on infrastructure cost, Gitea or Forgejo will win every time. If you’re evaluating it on total engineering hours saved by not stitching together a scanning pipeline from scratch, GitLab CE can absolutely justify its footprint. The honest recommendation for most new self-hosted deployments starting from scratch in September 2026 is Forgejo, on the strength of its governance model and Gitea-equivalent resource requirements, with GitLab CE reserved for organizations that have already outgrown a lightweight forge’s feature set.
Frequently Asked Questions
Is Forgejo a complete replacement for Gitea?
Yes. Forgejo started as a direct fork of Gitea’s codebase, and migration guides describe switching from Gitea to Forgejo as often requiring nothing more than changing the Docker image tag, since both platforms share the same underlying data structures at the point where they diverged.
Can Gitea or Forgejo run on a Raspberry Pi?
Yes. Community reports on Reddit describe both platforms running comfortably on Raspberry Pi hardware with 512MB to 1GB of RAM for small personal or team repositories, with the application itself consuming around 512MB of resident memory after a year of continuous uptime.
Does GitLab Community Edition include CI/CD for free?
Yes. GitLab CI/CD is included in the free Community Edition tier. Advanced security scanning features like SAST and DAST are more extensively available in the paid Premium and Ultimate tiers, but the core CI/CD pipeline engine itself is not gated behind a paywall.
Why did the Netherlands government choose Forgejo over Gitea or GitLab?
Reporting on the code.overheid.nl launch points to digital sovereignty and jurisdictional control as the driving factors, and Forgejo’s nonprofit governance and AGPL licensing align with a government’s need to avoid dependence on a single commercial vendor’s roadmap or ownership structure.
Which platform has better GitHub Actions compatibility?
Both Gitea Actions and Forgejo Actions were built for close YAML syntax compatibility with GitHub Actions, since both share the same underlying Actions implementation prior to the 2022 fork. Most existing .github/workflows files require only minor changes to run on either platform.
Is Forgejo’s AGPL license a problem for commercial use?
Not for simply running Forgejo internally to host your organization’s own repositories. AGPL’s copyleft obligations apply if you modify Forgejo’s source code and offer that modified version as a network service to others, which is a narrower scenario than most self-hosting teams ever encounter.
How much RAM does GitLab CE actually need for a small team?
GitLab’s official documentation lists 16GB as the baseline recommendation for a single-node install, though it notes the platform can function with as little as 8GB in constrained environments. Either figure is substantially above what Gitea or Forgejo require for comparable team sizes.
What database does GitLab Community Edition require?
PostgreSQL exclusively. Unlike Gitea and Forgejo, which support PostgreSQL, MySQL, MariaDB, SQLite, and MSSQL, GitLab CE does not offer alternative database backend options for its main application database.
