GitLab vs Forgejo: when each one fits
A platform team with both products on its shortlist should start from one question: how much of the DevSecOps toolchain should live in a single self-managed product. GitLab fits teams that want source control, CI/CD, security scanning and compliance evidence in one product, with paid tiers for the advanced features. Forgejo fits teams that want a lighter GPL-3.0-or-later Git forge with built-in CI through Forgejo Actions, and are willing to assemble scanning, compliance tooling and reporting from other systems. Neither is a universal winner; the right answer depends on where the controls you must prove will live.
The decision turns on four things. First, whether the paid GitLab features are needed. Premium adds advanced CI/CD and priority support, while application security testing, vulnerability management and compliance features sit in the Ultimate tier, which is custom priced. If your security requirements are met by pipeline checks you already run, the Free tier may be enough. Second, team size. GitLab documents high availability guidance for 3,000 or more users, using Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul, which is a materially heavier footprint than a single Forgejo instance. Third, compatibility: Forgejo Actions is not compatible with GitHub Actions, so existing workflow files will need rewriting. Confirm this against your pipeline inventory before you commit.
Upgrade cadence is the cost most teams underestimate. GitLab ships a minor release monthly and requires passing through upgrade stops such as 19.5, 19.8 and 19.11, so someone must own that path continuously. Forgejo offers LTS releases published in the first quarter of each year, with v15 supported until July 15, 2027, which suits a team that plans upgrades annually. Decide who carries that work, whether your staff or a retainer with DeployOpen, and ask each vendor for its current support windows in writing before you select a version.
Which platform fits which team scenario
This table maps common team situations to the platform that usually fits better, with the condition that makes each choice hold. Read each row against your own requirements, and confirm the items in the last column before you shortlist either platform.
| Scenario | Better fit and why | Condition and what to confirm |
|---|---|---|
| Regulated team that wants security scanning and compliance evidence in one tool | GitLab, because the pricing page places application security testing, vulnerability management and compliance features in Ultimate, which is custom priced. Forgejo does not offer an equivalent bundled scanning suite in the supplied facts. | Holds only if you need those features inside the forge itself. Confirm with GitLab which Ultimate features cover your controls, and confirm with Forgejo what scanning you would add as separate tools. |
| Small team that mostly needs hosted Git and simple pipelines | Forgejo, because it is a lightweight forge with built-in Forgejo Actions for CI and a smaller operational footprint than a full DevSecOps suite. | Holds if you do not need the wider GitLab toolchain. Confirm that your pipelines run on Forgejo Actions runners and that your hardware matches the sizing you plan for. |
| Team already running GitHub Actions workflows | Neither platform runs GitHub Actions workflows unchanged. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with it, so Forgejo may need the smallest rework of the two for CI that resembles GitHub Actions. | Confirm by testing your heaviest workflows on Forgejo Actions runners before choosing. Expect rewrites for third-party actions and secrets handling on either platform. |
| Air-gapped network | GitLab, because it documents running self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners. | Holds if your scanners and any AI features must run offline. Confirm offline support for each Forgejo component you plan to use and the update path for packages and runners. |
| Team with no appetite for frequent upgrades | Forgejo LTS releases, because they are published in the first quarter of each year and receive critical bugfixes and security support for one year and three months. GitLab ships a minor release monthly and requires upgrade stops. | Holds if you accept an LTS track and a yearly or slower cadence. Confirm the LTS release you would run and the date its support ends, then plan the next move before that date. |
| Large user base that needs high availability | GitLab, because its reference architectures scale to 50,000 users and its documentation recommends a high availability strategy for 3,000 or more users, with Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul. | Holds if you can run the stateful components on VMs or managed services, since GitLab does not support PostgreSQL or Redis inside Kubernetes. Confirm the user count and API request rate with your own load test before sizing. |
How GitLab and Forgejo are built and deployed
GitLab and Forgejo differ less in features than in what they ask your team to run. GitLab spans a bundled package, a Kubernetes chart and a multi-service high availability design, while Forgejo starts as a single service with separate runners. The cards below set out what each shape means for the people who will patch, back up and scale it.
GitLab Linux package bundling
The Linux package is GitLab's most mature installation method and bundles PostgreSQL, Redis and Sidekiq into one install. That keeps the moving parts inside GitLab's own packaging, so your team patches and backs up one product rather than assembling its database and cache separately. Check whether your operators accept a bundled PostgreSQL for production or whether they will want an external database managed on their own terms.
Helm chart and Operator routes
GitLab also installs through a Helm chart and a GitLab Operator on Kubernetes. Those routes need external PostgreSQL, Redis and object storage, so the chart shifts database and storage ownership to you. Ask whether your platform team already runs stateful services on Kubernetes, because GitLab's reference architectures do not support running PostgreSQL or Redis inside Kubernetes.
Reference architectures and high availability
GitLab publishes reference architectures from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 requests per second. The documentation generally recommends high availability from 3,000 users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Each added component is another system to monitor, patch and recover, so confirm your user count and failover expectations before sizing.
Stateful services stay outside Kubernetes
GitLab's reference architectures state that PostgreSQL and Redis inside Kubernetes are not supported. Its Cloud Native Hybrid pattern runs stateless components on Kubernetes and places stateful services on VMs or managed services. For your team, this means a Kubernetes cluster does not remove the need for database administration skills, and the VM estate for PostgreSQL and Redis must be designed and backed up separately.
Forgejo single-service model
Forgejo runs as a lightweight Git forge in a single service, which keeps the installation surface small for a small platform team. Its operating burden is mainly the forge itself, its database and its upgrade cycle. Confirm which database engine and storage layout your standards require, and whether a single service meets your availability target without extra clustering components.
Forgejo Actions on separate runners
Forgejo Actions is built in, but it hands workflows to separate runners rather than executing them inside the forge. Your team therefore operates runner hosts, their images and their isolation alongside the forge. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions, so check whether existing workflows need rewriting before you plan runner capacity.
Capability comparison: built-in CI, security scanning and upgrades
This table compares licensing, built-in CI, security scanning, release cadence, federation and offline operation for GitLab and Forgejo. Read each row against your own requirements, and treat any cell that says to confirm as a question for the vendor before you shortlist.
| Capability | GitLab | Forgejo |
|---|---|---|
| License | GitLab Community Edition is MIT licensed, but files in the ee/ directory are proprietary and need a paid subscription | GPL-3.0-or-later from v9.0 onward; earlier versions were under MIT |
| Built-in CI | GitLab CI/CD is built into the platform, with advanced CI/CD listed under Premium | Forgejo Actions hands workflows to separate runners and is familiar to GitHub Actions users but not compatible with it |
| Security scanning | Application security testing and vulnerability management are listed under Ultimate; confirm which scanners your tier includes | Not covered by the supplied facts; confirm scanner availability and integration with the vendor |
| Release cadence | Minor release monthly on the third Thursday; major release yearly; security fixes backported to the previous two monthly releases | Stable releases get three months of full support plus a two-week window; LTS releases get one year and three months |
| Federation | Not listed in the supplied facts for this comparison; confirm with the vendor if needed | Experimental, built on the ForgeFed protocol based on ActivityPub, under active development |
| Offline operation | Documents self-managed installs in offline, air-gapped environments, with separate guidance for security scanners | Not covered by the supplied facts; confirm offline install and update steps with the vendor |
What each platform charges for and what stays free
GitLab uses an open-core model with three tiers, and all three are available for self-managed installations. The Free tier costs 0 US dollars. Premium costs 29 US dollars per user per month, billed annually. Ultimate is custom priced, so it requires a quote. The GitLab pricing page places advanced CI/CD and priority support in Premium, and application security testing, software supply chain security, vulnerability management and compliance features in Ultimate.
- Free tier: 0 US dollars, the entry point listed on the pricing page for self-managed installs.
- Premium: 29 US dollars per user per month billed annually, adding advanced CI/CD and priority support.
- Ultimate: custom priced, adding security testing, supply chain security, vulnerability management and compliance features.
- Self-managed availability: all three tiers can run on your own servers, so choosing a tier does not require moving to GitLab.com.
- Community Edition versus ee/: the Community Edition is MIT licensed, while files in the ee/ directory are proprietary and need a paid subscription. Confirm with GitLab what your instance does if a subscription ends.
Check current prices and the feature table on the pricing page before you budget, because tier contents change over time.
Forgejo is licensed under GPL-3.0-or-later from v9.0 onward, and earlier versions are under MIT. Codeberg e.V., a non-profit association registered in Berlin, owns the Forgejo domains, while project governance stays independent. No paid Forgejo edition is documented for this comparison, so the software has no subscription line to budget for, although infrastructure and staff time still cost money.
- License by version: GPL-3.0-or-later from v9.0, MIT before that. The license you inherit depends on the version you deploy, so record it in your inventory.
- Copyleft terms: GPL-3.0-or-later carries obligations if you modify and distribute the software. Review those terms with counsel before you customize it. The Forgejo FAQ is the natural starting point for the project's own position.
- Governance and domains: Codeberg e.V. holds the domains while governance stays independent, which is a question to cover in your vendor risk review.
- Support windows: stable releases receive full support for three months plus a two-week window, and LTS releases receive critical bugfixes and security support for one year and three months.
- Commercial support: no paid support contract is documented here. Ask Forgejo's maintainers or a partner who works with the project which support options exist and which versions they cover.
Confirm the license version you will deploy and the support terms in writing before you treat the software as cost free in your planning.
The software license is only one part of the bill. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure, usually under a fixed-scope agreement. DeployOpen does not publish a price list, and a quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as retainers.
- One-time work: planning, installation, integration, hardening, documentation and repository migration, as agreed in the written scope.
- Recurring subscriptions: GitLab Premium or Ultimate fees per user, renewed on the billing cycle you choose. Forgejo has no paid edition documented here.
- Recurring operations: retainers for support and upgrades, plus your own compute, storage and backup costs, which grow with users and CI load. GitLab's reference architectures begin at 1,000 users, and high availability is generally recommended from 3,000 users.
- Internal staff time: administrators handle upgrades. GitLab ships a minor release monthly and a major release yearly, and it requires upgrade stops, while Forgejo's support windows set its own upgrade cadence.
- What to request in a quote: the scope, tier and seat count, who performs upgrades, which support window is covered, and which lines recur each year.
Ask for one-time and recurring costs as separate lines so you can compare both platforms on the same basis.
What drives the running cost of each platform
The running cost of either platform is mostly staff time and infrastructure, and the subscription line is the one most likely to be mistaken for the whole bill. For GitLab, the per-user subscription is the visible recurring charge: the GitLab pricing page lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, with all three available for self-managed installations. Forgejo has no paid tier to buy from the project itself, so its licensing cost is zero, but you still pay for the instance, the runners, the people who run them and any commercial support you contract separately. Confirm with each vendor whether support is bundled or sold on top before comparing totals.
Most of the one-time cost sits in the first deployment, any migration from an existing forge, and hardening. Recurring cost comes from upgrades, patching, backup testing and runner maintenance. GitLab adds a fixed cadence to plan around: a minor release on the third Thursday of each month, and required upgrade stops that fall at versions x.2, x.5, x.8 and x.11, so a team that skips a stop must take an extra step. Forgejo's cadence is different. Stable releases get three months of full support plus a two-week window, while LTS releases receive one year and three months of critical and security support, so an operator on LTS upgrades less often but must still schedule the move before the window closes. Ask whether each upgrade is covered in the quote or billed as separate work.
The factors that raise or lower cost are user count, whether high availability is needed, how many runners you operate, and how often you upgrade. GitLab documents high availability as the recommended strategy for 3,000 or more users, which brings in Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, and each adds hosts to patch and back up. Runner count drives both compute and staff time, so decide early whether jobs run on a few shared runners or on a pool that scales. In your quote request, ask for the scope in writing, the tier per user and seat count for GitLab, the runner design and who maintains it, a backup and restore test with a recorded result (the GitLab backup and restore documentation describes the procedure), and upgrade support covering both the GitLab stops and Forgejo LTS windows.
Moving a Git and CI estate from one platform to the other
This sequence moves repositories, identities, pipelines and runners from one forge to the other while keeping a tested way back. Each step ends with a check you can record before the next one starts.
Inventory repositories, users, permissions and pipelines
The platform owner lists every repository with its size, default branch, LFS objects, webhooks, protected branches, and open merge requests or issues, plus every user, group and runner. Record which pipelines run on which runners and which external systems they call. The inventory is finished when each repository has an owner and a migrate, archive or retire decision.
Confirm which CI definitions convert
The engineering lead reviews each
.gitlab-ci.ymlfile and checks its keywords, includes, variables, artifacts and services against what Forgejo Actions supports. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, so pipelines are rewritten as Forgejo workflows rather than copied. The check is complete when every pipeline is tagged as ported, rewritten or retired, with the rewritten ones reviewed by the team that owns them.Map identity and SSO before cutover
The identity owner documents how users sign in today, which groups map to which teams, and which SSO or LDAP settings the new forge will use. Confirm the Forgejo authentication options against your directory, and test sign-in with a pilot group before any production repository moves. Accounts and SSH keys are recreated or linked, so the mapping file is signed off when every active user has a matching identity on the target.
Migrate repositories with each platform's import tooling
The platform team uses the import tooling each platform documents, and GitLab's import and migrate documentation is the reference for moving projects into GitLab. Git history, branches and tags transfer through a standard clone and push, while issues, merge request discussions, approvals and CI history depend on what the importer supports. Compare commit counts, branch lists and tag lists on a sample of repositories, and record every item the importer skipped.
Rebuild CI, runners and secrets
The DevOps team registers new runners on the target platform, rebuilds the runner images and network paths, and recreates CI secrets, environment variables and deploy keys. Pipelines run first on a non-production branch with logs compared against the old system. Secrets are not exported in plain text, so the rebuild is done when every ported pipeline passes on the new runners and every secret is recorded in the owning vault.
Test backup and restore on the target
The operations team takes a backup of the new instance and restores it to a separate host to confirm repositories, users, attachments and database content come back intact. Restore is tested on the same schedule the team will run in production, and the restore time and any gaps are written down. The step is complete when a restored copy matches the source inventory and the team can repeat the restore without help from the original builder.
Cut over with a rollback plan
The change owner freezes writes on the old forge for each repository group, runs a final sync, updates clone URLs, webhooks and deploy targets, and announces the new locations to users. The rollback plan states who can reverse the DNS or URL change, which repositories can be pointed back, and how changes made on the new forge during the window would be reconciled. The cutover closes when smoke tests pass for each group and the old forge is kept read-only until the rollback window has passed.
Where implementation projects usually run long
Installation method and runner design shape most GitLab projects, so decide them before anyone writes automation. GitLab can be installed from the Linux package, the Helm chart, the GitLab Operator, Docker or source, and GitLab describes the Linux package as the most mature method. That choice determines where PostgreSQL, Redis and object storage run. Identity integration needs an early decision too: map SSO and directory groups to GitLab roles using the GitLab authentication and authorization documentation, and confirm which options your tier includes. On Forgejo the install is lighter, but the runner plan still matters. Forgejo Actions hands jobs to separate runners, and workflows written for GitHub Actions do not run unchanged.
Upgrade paths and backups are where long projects tend to stall. GitLab requires upgrades to pass through required upgrade stops, which since GitLab 17.5 fall at x.2, x.5, x.8 and x.11, so an instance several releases behind may need multiple hops. Each hop should be preceded by a tested backup and a restore into a separate environment, following the GitLab backup and restore guidance. Forgejo's path is different: transparent upgrades from Gitea are documented up to Gitea v1.22 in two steps, first to Forgejo v10.0.x and then to any later Forgejo release. Teams still on an older Gitea must plan that sequence explicitly and confirm with Forgejo which target release their current version maps to before booking a change window.
Projects overrun in four places: pipeline conversion, permission mapping, air-gapped package delivery and the first upgrade rehearsal. Pipeline conversion grows when existing workflows were written for another CI system, since each one must be rebuilt as GitLab CI/CD pipelines or Forgejo Actions workflows. Permission mapping stalls when groups, projects and runner access are recreated by hand instead of from an inventory. For air-gapped sites, GitLab documents offline environments and separate guidance for its security scanners, so ask early how package and scanner updates reach the network, and confirm the equivalent process for Forgejo. Finally, rehearse the first upgrade on a copy of production data. DeployOpen plans and implements these pieces inside your own infrastructure under fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work starts.
Questions buyers ask before choosing GitLab or Forgejo
What drives the cost of GitLab Premium compared with the top GitLab tier?
Premium is a per-user subscription, so its cost scales with the number of licensed users, while the top tier is custom priced and set by quote. GitLab's pricing page lists Premium at 29 US dollars per user per month billed annually and Free at 0 dollars, and all three tiers are available for self-managed installations. The difference in cost comes from scope. Premium adds advanced CI/CD and priority support. The top tier adds application security testing, software supply chain security, vulnerability management and compliance features. Drivers include seat count, which security features your program needs, the support level and the contract term. Ask GitLab for a written quote for each tier that lists seats, term and the features included. Plan for the one-time migration and integration work separately from the recurring subscription.
Can Forgejo Actions run our existing GitHub Actions workflows?
No. Forgejo Actions is a built-in CI system that hands workflows to separate runners, and it is designed to feel familiar to GitHub Actions users, but Forgejo's documentation states it is not compatible with GitHub Actions. Existing workflows will need review before they run on Forgejo. Check triggers, secrets handling, runner labels and any third-party actions your pipelines call, since each one may need a replacement or a rewrite. A practical approach is to inventory your pipelines, port a representative sample to a staging Forgejo instance and measure the rework before committing to a cutover date. Teams that rely heavily on a large set of marketplace actions should confirm the gap early in the evaluation.
How much staff effort do upgrades take on each platform?
The effort depends on how often the platform changes and how far behind you fall. GitLab ships a minor release monthly on the third Thursday, maintains the current and previous two minor releases for security fixes, and requires upgrade stops at x.2, x.5, x.8 and x.11 since GitLab 17.5, for example 19.5 and 19.8. Staying on a maintained version keeps upgrades to planned hops. Forgejo stable releases get three months of full support plus a two-week window, while LTS releases receive critical bugfixes and security support for one year and three months. Either way, plan staff time for a staging upgrade, backups, restore testing, and the CI or configuration changes each release may need. Ask any vendor or partner for the upgrade scope in writing.
Can our team run the platform without outside help?
A small team can run a single-node Forgejo or a small GitLab instance, but the answer depends on skills and the size of the deployment. GitLab's documentation generally recommends a high availability strategy for 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Operating that stack requires experience with Linux, PostgreSQL, storage, backups, restore testing and upgrade planning. Outside help can cover any part of that work. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. Ask which tasks your staff will own after handover.
How long does a migration take, and what does it depend on?
No duration applies across all teams, so the timeline should come from a scoped inventory of your environment. The main drivers are the number of repositories, their size and history, the number of CI pipelines to convert, and how much issue, merge request or wiki data must move. User mapping, single sign-on setup and integrations with other systems add work. Forgejo Actions is not compatible with GitHub Actions, so pipeline conversion can be the largest item for GitHub-based teams. Confirm which import sources each platform supports for your current forge, and check GitLab's import documentation for your source type. Pilot with a subset of projects, define a cutover and rollback plan, and ask for a timeline in the written proposal that lists each migration step.
Does GitLab work in air-gapped networks?
Yes. GitLab documents running self-managed instances in offline, air-gapped environments, and it publishes separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Before committing, confirm what each feature you plan to use needs from outside the network. Scanner vulnerability data, container images, runner images, package sources and license activation for paid tiers all need a plan, usually a mirror or an approved transfer process inside your boundary. Review the offline guidance for each feature rather than assuming all features behave the same way. Forgejo is also self-hosted, but no offline guidance was supplied for this comparison, so confirm its dependencies on external services with the Forgejo project and in your own test environment.
Which Forgejo release should we choose for support windows?
For production use, choose the release whose support window matches how often you can upgrade. Forgejo v15 is the LTS release supported until July 15, 2027, and v17.0.0 was released on October 15, 2026 with support until January 28, 2027. Stable releases get full support for three months plus a two-week window, while LTS releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months. An LTS line usually suits teams that want fewer upgrades, but it still ends on a fixed date. Check the current release list before deciding, and schedule your next upgrade before the end of support. Confirm with Forgejo which release line fits your plan.
Is Forgejo federation ready for production use?
No, not as a production dependency. Forgejo's FAQ describes federation as experimental and under active development, based on the ForgeFed protocol, which builds on ActivityPub. Do not design a production workflow that depends on cross-instance federation. If your requirement is multi-site collaboration, identity across instances or code sharing between organizations, test the specific behavior you need in a non-production environment and confirm the current status with the Forgejo project. Build the workflow around features you have verified in your own environment, and document the fallback if a federation feature changes or is removed.
How DeployOpen helps teams choose and implement a Git platform
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the GitLab or Forgejo decision is tested against your network, identity setup and delivery workflow before anything is installed. We start from written requirements and deliver to a written scope.
How we scope
- Map which DevSecOps features your teams need in one product and which they already run elsewhere.
- Confirm the GitLab tier or Forgejo release line, including support windows and upgrade cadence your team can staff.
- Agree in writing which deliverables, timelines and hosting environment are included before work starts.
How we build
- Install and configure the chosen platform in your cloud accounts, data center or air-gapped network.
- Connect identity sources, CI runners and existing repositories, and migrate projects with agreed checks.
- Run security testing against the forge and its pipelines, then document the findings and remediation.
How we hand over
- Deliver runbooks for upgrades, backups, restores and runner maintenance written for your operations team.
- Document configuration, access model and the evidence needed for internal or external compliance assessments.
- Walk your administrators through the running system so they can operate it without DeployOpen on call.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
- Plan upgrade windows around the platform's own release and upgrade-stop schedule for your version.
- Revisit the tier, runner and hardware decisions when your user count, pipeline volume or compliance needs change.
