GitLab vs Gitea vs Forgejo: which to choose

Which self-hosted Git platform fits your team

GitLab fits teams that want CI, security scanning and compliance evidence in one product, while Gitea or Forgejo fit smaller teams that want a lightweight forge and will assemble the rest of the toolchain themselves. GitLab is open core: the code outside the ee/ directory is MIT licensed, but files inside ee/ are proprietary and need a paid subscription, so the Free tier and the paid tiers come from one codebase. Check the GitLab LICENSE file against the features your auditors will ask about, because vulnerability management and compliance tooling sit behind paid tiers that you should price from a written quote.

Gitea is MIT licensed and combines Git hosting, code review, package management and CI/CD in one Go service, and Gitea Actions is designed to be compatible with GitHub Actions. Forgejo is GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, and Codeberg e.V. owns its domains while project governance stays independent. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions, so workflow files written for GitHub need rewriting or testing before you commit to the platform.

Three questions should decide the shortlist. First, team size and staffing: a lightweight forge is simpler to keep running, while GitLab asks you to follow its monthly minor releases and the required upgrade stops in its upgrade paths. Second, toolchain ambition: if you want one product for merge requests, pipelines, scanning and compliance evidence, GitLab is the consolidated choice, but if you already run separate scanners and registries, Gitea or Forgejo keeps the forge narrow. Third, governance: Gitea has commercial support from CommitGo, Inc. and a paid Gitea Enterprise edition, while Forgejo is community governed. Before you decide, run a representative pipeline on each candidate and confirm which GitHub Actions features it supports.

Which platform fits which scenario

This table matches common team situations to the platform that fits best and the supplied fact behind each choice. Read each row as a condition: the recommendation holds only while the stated requirement holds. Use it to narrow the shortlist before comparing licenses, support windows and CI details.

Scenario	Best fit	Reason and condition
Small team wanting a light, low-footprint forge	Gitea or Forgejo	Both are lightweight self-hosted Git services. Gitea is MIT licensed and runs on small systems such as a Raspberry Pi, per its documentation. Choose on license and governance next.
Regulated team needing SAML service provider support, audit logging and dependency scanning	GitLab (Premium or Ultimate) or Gitea Enterprise	Gitea Enterprise adds SAML 2.0 service provider support, audit logging and dependency scanning. GitLab's security scanning and compliance features sit in Ultimate, which is custom priced. Confirm which features each edition covers in your environment before deciding.
Team migrating existing GitHub Actions workflows	Gitea	Gitea Actions is designed to be compatible with GitHub Actions. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with them, so expect more workflow rework on Forgejo. Test your actual workflows on each platform.
Team that values community governance and copyleft licensing	Forgejo	Forgejo is GPL-3.0-or-later from v9.0 onward, and Codeberg e.V., a non-profit association, owns its domains while project governance stays independent. Confirm the governance terms you need against the Forgejo FAQ.
Team wanting one DevSecOps product with CI, security and compliance in one place	GitLab	GitLab's pricing page lists advanced CI/CD and priority support for Premium, and application security testing, vulnerability management and compliance features for Ultimate. Plan for a monthly minor release cadence and required upgrade stops.
Organization planning high availability for 3,000 or more users	GitLab, with a high availability reference architecture	GitLab's docs generally recommend a high availability strategy at 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Plan that operating effort before choosing GitLab at this scale.
Team that cannot run PostgreSQL and Redis inside Kubernetes	GitLab on VMs or managed services	GitLab's reference architectures say running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. The Cloud Native Hybrid architecture keeps stateful services on VMs or managed services.

Licensing and paid editions by platform

GitLab is an open-core product, so the license depends on which part of the source tree you install. Content outside the ee/ directory is available under the MIT Expat license, which is the Community Edition. Files in the ee/ directory are licensed under the GitLab Enterprise Edition license and need a paid subscription. The GitLab pricing page lists Free at 0 dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced. All three tiers are available for self-managed installations.

Community Edition under MIT: The MIT-licensed portion covers Git hosting and the core DevOps workflow without a subscription.
Free tier at 0 dollars: Free is the tier to use when you need no paid features, though the license is still tied to the Enterprise Edition code path.
Premium at 29 US dollars per user per month: The pricing page lists advanced CI/CD and priority support for Premium, billed annually.
Ultimate, custom priced: Application security testing, software supply chain security, vulnerability management and compliance features sit in Ultimate, and the price comes only from a quote.
Recurring cost: Subscriptions recur per user, so cost grows with headcount and with the share of users who need paid features.

Confirm current pricing, user counting rules and renewal terms directly with GitLab, and ask whether your required security or compliance features are included in the tier you are quoted.

How the architecture changes what you run

The first question is how much infrastructure each platform asks you to run. GitLab's Linux package bundles PostgreSQL, Redis and Sidekiq into one installation, and GitLab describes it as the most mature and scalable installation method. GitLab also offers a Helm chart, the GitLab Operator, Docker and source installs. Its reference architectures run from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 requests per second. For 3,000 or more users, the documentation generally recommends high availability built on Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Plan for that stack as a standing operating commitment, not a one-time install. Gitea runs on MySQL, PostgreSQL, SQLite or MSSQL and runs on hardware as small as a Raspberry Pi, so a team of a few dozen developers can often start on a single modest server. Forgejo shares that lightweight model and documents upgrade paths from Gitea. Confirm the database and storage sizing for your own user count with each vendor rather than extrapolating from these tiers.

Kubernetes changes the picture for GitLab specifically. GitLab's reference architectures state that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. The Cloud Native Hybrid architecture is the supported pattern: stateless GitLab components run on Kubernetes while PostgreSQL, Redis and object storage run on virtual machines or managed services. If your platform team already runs everything on Kubernetes, decide early whether you will operate that split topology or keep GitLab on VMs with the Linux package. Gitea and Forgejo are simpler to containerize for small teams, but their own database and storage choices still determine backup and failover work. Ask each vendor, in writing, which components they support inside a cluster and what their backup and restore procedure covers for your chosen database.

Security tooling and governance trade-offs

The three platforms differ less in Git features than in where security controls, SAML, audit logging and scanning live, and who governs the project. Each card below is a decision or check that changes the shortlist, so confirm each one against your own compliance and network requirements before you commit.

Ultimate's security testing scope

GitLab places application security testing, software supply chain security, vulnerability management and compliance features in the Ultimate tier, which is custom priced. If your program depends on built-in scanning and vulnerability tracking inside the forge, the cost of Ultimate belongs in the quote alongside the platform. If you already run a scanner stack elsewhere, ask whether its findings can flow into your ticketing and reporting without Ultimate.

Premium's paid controls

Premium is the tier to price first for most mid-sized teams, since the GitLab pricing page lists advanced CI/CD and priority support at that level. Confirm which governance features your auditors expect at Premium rather than Ultimate, because the split decides whether a per-user subscription is needed for every developer or only for a subset. Recurring subscription fees are the cost that scales with headcount.

Gitea Enterprise's SAML and audit

CommitGo sells Gitea Enterprise, which adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. If your identity provider speaks SAML, this edition is the path to test. Confirm the audit log contents and retention against your evidence requirements, and confirm the edition fits your support needs before you assume the community build is insufficient.

Forgejo's independent governance

Forgejo is licensed GPL-3.0-or-later from v9.0 onward, and Codeberg e.V., a non-profit association registered in Berlin, owns its domains while project governance stays independent. This matters when you want a forge whose direction is not set by a single commercial vendor. Check the license version that applies to the release you deploy, and confirm whether any enterprise identity, audit or scanning features you need exist in your chosen build before you rely on them.

Air-gapped operation

GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Scanners that need vulnerability databases or updates will need an internal mirror process. For Gitea and Forgejo, confirm which CI, package and scanning functions work without outbound access in your network before you assume parity.

Verify SAML, audit and scanning

Gitea and Forgejo capabilities vary by edition, release and configuration, so the feature names on a marketing page are not enough. Ask each vendor or community channel for written confirmation of SAML behavior, audit event coverage, branch protection and scanning in the exact version you will run. Test those controls in a staging environment with your identity provider and log pipeline before the decision is final.

How upgrade cadence affects your operating effort

The release rhythm of each platform decides how often your team must schedule a change window, so budget that time before you choose. GitLab ships a minor release on the third Thursday of each month, and the maintenance policy backports security fixes only to the current and previous two releases, with 19.5, 19.4 and 19.3 listed as maintained. Bug fixes go only to the current stable line, so an instance that falls two or three monthly releases behind loses security coverage on a predictable schedule. GitLab also ships one major release a year, with GitLab 20.0 planned for May 2027, and requires upgrades to pass through stops at versions x.2, x.5, x.8 and x.11. Plan a quarterly path through those stops, and confirm the exact sequence in the upgrade paths documentation before each move.

Forgejo offers two tracks. Stable releases get full support for three months plus a two-week window, so a stable instance must be moved roughly every quarter. Long-term support releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months. Forgejo v15 is the current LTS line, supported until July 15, 2027, and v17.0.0 is supported until January 28, 2027. For a team with a small platform group, running the LTS track usually means one planned upgrade per year plus a yearly review, which is a materially lighter calendar than a monthly GitLab cadence. Confirm the LTS and stable dates on the Forgejo releases page at the time you schedule work.

Gitea's recent releases show a steady feature cadence rather than a published long-term support window in the sources supplied: v28.0.0 arrived on September 29, 2026, v28.1.0 on October 6, 2026, and the v1.27 line shipped v1.27.3 on August 29, 2026. Before you commit, ask CommitGo or your Gitea contact to state in writing how long each line receives security fixes and whether a Gitea Enterprise subscription changes that window. Whichever platform you pick, turn the cadence into a calendar: name an owner for each upgrade, reserve a monthly or quarterly window, rehearse on a restored backup in a staging copy, and count the staff hours per cycle as an ongoing line item rather than a one-off project.

What drives the running cost of each platform

Licence fees are rarely the largest line item for a self-hosted Git platform. Staff time for upgrades, backups, runner capacity and hosting usually decides the total, and the three platforms shift that work in different directions. Use the cards below to separate one-time setup from recurring cost, then ask each vendor or partner for the same line items in writing.

Hosting footprint

GitLab's reference architectures start at 1,000 users and scale to 50,000, and GitLab recommends a high availability strategy for 3,000 or more users. That means multiple application, Gitaly, PostgreSQL, Redis and object storage components, all of which recur as compute and storage. Gitea and Forgejo are single binaries that run on small hosts, including a Raspberry Pi, so their footprint is mostly a question of sizing for your user count. Ask each party for a sizing estimate at your expected load and for the number of nodes it assumes.

Database and backup

GitLab's high availability pattern uses PostgreSQL with Patroni, Redis Sentinel and Consul, so backup and restore must cover several stateful services. Gitea and Forgejo support MySQL, PostgreSQL, SQLite and MSSQL, so a team can choose a database it already operates. Recurring cost comes from backup storage, restore testing and the staff hours spent proving restores work. Ask whether backup tooling, retention and restore drills are included in scope or left to your team.

Upgrade labor

GitLab ships a minor release monthly and requires passing through upgrade stops, which fall at versions x.2, x.5, x.8 and x.11 since GitLab 17.5. Each stop is a planned change window, and the current maintenance policy backports security fixes only to the latest releases. Forgejo stable releases get three months of full support, and its LTS releases receive support for one year and three months, so the cadence you pick sets your annual labor. Ask for the upgrade calendar and whether it is in the retainer.

CI runner capacity

GitLab CI runs on GitLab Runner, which needs its own hosts or Kubernetes capacity sized for peak pipeline concurrency. Gitea Actions and Forgejo Actions use separate runners as well, and Gitea Actions is designed for compatibility with GitHub Actions workflows. The runner fleet recurs as compute, image storage and cache costs, and it grows with build frequency more than with user count. Ask each party what concurrency the quote assumes and who maintains runner images and patching.

Subscription cost

GitLab Free costs nothing, Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced. Seat counts multiply that fee every year, and the security and compliance features that matter to regulated teams sit in Ultimate. Gitea Enterprise and Forgejo's model differ, so ask CommitGo or your partner for the commercial terms in writing. Confirm which features you need before you compare seat prices, because the tier that unlocks them sets the recurring line.

Staff time and one-time setup

Installation, migration, SSO integration and hardening are one-time costs that you pay for once, whether to your team or to an implementation partner. Ongoing staff time covers patching, monitoring, on-call response and version tracking, and it recurs for the life of the platform. GitLab's larger footprint usually needs more operator hours, while a single-binary forge needs fewer but still needs an owner. Request a quote that splits one-time setup from recurring operations and names the hours, roles and response times it assumes.

How to move between the three platforms

This sequence turns a move between GitLab, Gitea and Forgejo into a tested cutover with a rollback path, so each repository, pipeline and permission is confirmed on the target before users depend on it.

Inventory repositories and CI workflows
The platform owner lists every repository, branch protection rule, webhook, mirror and CI workflow, and marks which pipelines use GitLab CI syntax, GitHub Actions syntax or custom runners. Moving from GitLab means reviewing .gitlab-ci.yml features such as includes, variables and protected environments, because GitLab CI does not run unchanged on Gitea or Forgejo. The step is done when every item has an owner and a destination decision (migrate, rewrite or retire).
Check package registry needs
The team records which package types, container images and Helm charts are published and consumed, and which clients point at them. Gitea documents support for more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts, so confirm each type you use is covered on the target and in the edition you run. The check closes when every registry consumer has a named endpoint and a test install has succeeded.
Test workflows on the target runner
Engineers run representative pipelines on a staging instance with the runners the target platform will use. Gitea Actions is designed to be compatible with GitHub Actions, while Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with it, so confirm each action your workflows call on the chosen platform. The step is complete when test runs pass, artifacts and secrets behave as expected, and the team has a list of workflows that needed rewriting.
Plan identity and permission integration
The security lead maps groups, roles, SSO and two-factor requirements from the current platform to the target. Confirm which identity protocols the target edition supports in your environment, since SAML 2.0 service provider support and audit logging sit in Gitea Enterprise, and GitLab tier features differ by subscription. Review repository and organization permissions after import, because migrated accounts and teams do not always carry over their original rights. The step is done when a test group of users signs in and sees exactly the access the plan specifies.
Migrate data and check the upgrade path
The operator imports repositories, issues and metadata to a staging copy, then verifies commit history, tags and LFS objects against the source. If the move is an upgrade within the same product, follow its documented path: Forgejo documents transparent upgrades from Gitea up to v1.22 in two steps, first to Forgejo v10.0.x and then to a later Forgejo version. GitLab requires upgrades to pass through required upgrade stops, so confirm the stop versions before any version change. The step closes when the staged copy matches the source on a defined set of checks.
Run cutover with a rollback plan
Before the switch, the team takes a fresh backup of the source, freezes pushes for the repositories in scope, runs the final sync and repoints DNS, clone URLs, webhooks and CI runners. Keep the source readable and its backups intact until the target has run through normal work, so a rollback means repointing those same URLs. The step is done when a sample of developers and pipelines works against the target and the rollback steps have been rehearsed.
Confirm support and decommission the source
Once the cutover is stable, the platform owner confirms the support window and release cadence for the chosen edition, so patching is scheduled rather than reactive. Record the final state of permissions, pipelines and registries, then retire the old instance only after a documented retention period set by your own policy. The sequence closes when the runbook, backups and ownership records are current and the old platform is marked read-only or removed.

What buyers ask before choosing a self-hosted Git platform

How much operating effort does each self-hosted Git platform need?

Effort depends mostly on how much you enable and how many users you serve. Gitea documents support for MySQL, PostgreSQL, SQLite and MSSQL and runs on Linux, macOS and Windows, including small systems such as a Raspberry Pi, so a single small instance is the simplest start. GitLab's reference architectures range from 1,000 to 50,000 users, and its docs generally recommend a high availability strategy at 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Forgejo's stable releases get full support for three months plus a two-week window, so plan a regular upgrade cycle or choose its LTS line, which receives support for one year and three months. Confirm the hardware and staffing for your user count with each vendor before you commit.

Can our team run a self-hosted Git platform without outside help?

Yes, for a single Gitea or Forgejo instance on a small team, as long as someone owns upgrades, backups, TLS certificates and runner hosts. A standalone GitLab instance is also self-managed, but larger deployments are harder to run. GitLab's high availability layout combines several stateful services, and GitLab requires upgrades to pass through required upgrade stops, such as 19.2, 19.5, 19.8 and 19.11. Outside help is most useful for the parts your team has not run before: a high availability build, an air-gapped install (GitLab documents running self-managed instances in offline environments), a migration from an existing forge, or hardening. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and a fixed-scope engagement is agreed in writing before work starts.

What drives the cost of a fixed-scope Git platform engagement?

The written scope sets the price, and DeployOpen does not publish a price list. The main drivers are the number of users and instances, whether you run a single node or high availability, how many repositories, CI pipelines, package registries and runners must move, how far the platform must integrate with your identity provider and audit tooling, and any air-gapped or regulated constraints. Costs split into one-time work (design, build, migration, hardening and documentation) and recurring costs (licenses or subscriptions, hardware or cloud capacity, staff time, and any retainer for support, upgrades or testing). Licenses are a separate line: the GitLab pricing page lists Premium at 29 US dollars per user per month billed annually, while Gitea and Forgejo are open source. Ask each quote to list deliverables, assumptions about user count and migration volume, acceptance criteria, timelines and exclusions.

How long does a Git platform migration take and what does it depend on?

No duration can be given without an inventory, so the timeline depends on the work list. Start with repositories and their size and history, users and groups, permissions, CI definitions, package registries, webhooks, LFS objects and integrations, then decide what moves and what gets archived. Gitea Actions is designed to be compatible with GitHub Actions, while Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with it, so workflows need review on each target. GitLab documents its import and migrate options, but pipelines must be translated to GitLab CI. Other dependencies include database size, identity mapping, runner rebuilds and a cutover window with a rollback plan. Ask for a written migration plan with a trial run on a copy before any date is set.

Is GitLab Free enough for a self-managed team?

GitLab Free fits a team whose requirements are covered by the Free tier's feature list, and you should check that list on the GitLab pricing page before deciding. The same page says all three tiers are available for self-managed installations, lists advanced CI/CD and priority support for Premium, and lists application security testing, software supply chain security, vulnerability management and compliance features for the top paid tier. GitLab Free costs 0 dollars, Premium costs 29 US dollars per user per month billed annually, and the top tier is custom priced. The Community Edition is MIT licensed, while files in the ee/ directory are proprietary and need a paid subscription, so confirm which build you install and which features it contains. Map each control your organization requires to a tier before you buy.

Do we need Gitea Enterprise or GitLab Premium for SAML and audit logging?

For Gitea, the Gitea Enterprise page lists SAML 2.0 service provider support and audit logging, along with organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. For GitLab, the pricing facts available here do not place SAML or audit logging in a specific tier, so confirm the tier for each feature on the GitLab pricing page before you buy. Be precise about the requirement: SAML sign-in, provisioning, audit event detail, retention and export may each be packaged differently. Then price the option. GitLab Premium is listed at 29 US dollars per user per month billed annually, and Gitea Enterprise pricing comes from CommitGo, Inc. An audit log supports a control only if someone reviews and retains it, which is your process. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.

Can Forgejo take over an existing Gitea instance?

Forgejo documents a transparent upgrade path from Gitea, but only up to Gitea v1.22, and it runs in two steps: first to Forgejo v10.0.x, then to any later Forgejo version. If your Gitea instance is on a later line, such as the v1.27 line that the Gitea release facts show, the documented path does not cover it, so confirm the route with Forgejo before you plan. Before any move, back up the database, repositories, attachments and configuration, rehearse the upgrade on a copy, and retest your Actions workflows. Licensing also changes: Forgejo is GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, so have legal review the terms. Check the support window against your policy, since Forgejo's stable releases get three months of full support plus two weeks, and LTS releases get one year and three months. DeployOpen can plan and carry out this kind of upgrade as fixed-scope work.

How DeployOpen helps you choose and implement

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and supports self-hosted open-source platforms inside your own infrastructure. For GitLab vs Gitea vs Forgejo, we start with the decision that matters most: how much of the DevSecOps toolchain you want in one product, and who will run it after go-live.

How we scope

We confirm user count, repository volume, CI workload and whether air-gapped operation is required before recommending an edition.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We document which GitLab tier, if any, your required features need, and confirm the current license terms with the vendor.

How we build

We install and configure the chosen platform in your cloud accounts, data centers or air-gapped network, with the database and storage layout you approve.
We set up CI runners or Forgejo Actions runners, and test whether your existing GitHub Actions workflows run unchanged or need rework.
We migrate repositories, users and access controls, then test authentication, backup restore and the upgrade path before cutover.

How we hand over

You receive architecture notes, configuration documentation, runbooks for backup, restore and upgrades, and a record of the decisions made.
We walk your platform and security teams through administration, including how to plan upgrades against the vendor's published release and support windows.
Compliance evidence, such as access reviews and configuration records, is prepared for your assessors. We do not issue audit reports or certifications.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover tracking maintained release lines, applying upgrades and re-testing after changes to CI or access configuration.
Ask any provider to confirm the support window, the upgrade process and who is responsible for patching before you sign.

GitLab vs Gitea vs Forgejo