GitLab vs Forgejo: which fits your delivery and governance needs
Choose GitLab when one platform must cover source hosting, CI/CD and security scanning under a single administrative model and your team can operate a larger product. Choose Forgejo when you need a lightweight, self-hosted Git forge with CI on separate runners and can source security controls from other tools. The decision turns on four questions: how much of the DevSecOps toolchain must be built in, which GitLab features would require a paid subscription, whether existing GitHub Actions workflows must run without changes, and how much upgrade work your team can absorb.
Licensing is the first check. GitLab Community Edition is MIT licensed, but files in the ee/ directory are proprietary and need a paid subscription, so any feature your auditors expect should be verified against the tier it sits in, not assumed from the Community Edition name. Ask GitLab in writing which tier each scanning and governance feature requires in your target version. Forgejo is licensed 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. That matters if procurement weighs license terms and governance heavily, though it does not replace a feature comparison. For CI, Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions. Run a sample of your workflows on a Forgejo runner before you commit to migration.
Upgrade cadence is where the two diverge most. GitLab ships a minor release monthly on the third Thursday and backports security fixes to the current and previous two releases, so an instance that lags several months falls out of security coverage and must make larger jumps. Forgejo publishes LTS releases with longer windows: v15 is supported until July 15, 2027, while v17.0.0, released October 15, 2026, is supported until January 28, 2027. A small team that can plan around LTS upgrades usually carries less recurring work. A team that wants the newest built-in scanning and can absorb monthly upgrades will get more from GitLab. Confirm hardware sizing with each vendor's current requirements and your expected user and pipeline volume, since neither figure is fixed by the platform choice alone.
Which platform fits which scenario
This table matches four common team situations to GitLab or Forgejo and gives the supplied fact behind each choice. Read the answer column first, then check the note on GitLab tier features, since several GitLab security capabilities depend on the subscription you buy.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Regulated team that wants security scanning inside the forge | GitLab | GitLab is a full DevSecOps suite, but which scanning features you get depends on tier. Confirm with GitLab which security capabilities sit in Premium and which need Ultimate, since the Community Edition is MIT licensed and ee/ directory files need a paid subscription. |
| Small engineering group that wants a lightweight forge with CI | Forgejo | Forgejo is a community Git forge with built-in Forgejo Actions, and its GPL-3.0-or-later licensing applies from v9.0 onward. Confirm that the runner setup and feature set cover your workflows before you commit. |
| Team migrating existing GitHub Actions workflows | GitLab (or a rewrite on either platform) | Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions, so workflows will need changes. Test a sample pipeline on each platform before choosing, because GitLab uses its own CI syntax and also needs conversion. |
| Organization with a dedicated platform team | Depends on operating model | A platform team can absorb GitLab's monthly minor release cadence, with security backports to the current and previous two releases, and its heavier hardware footprint. Forgejo's LTS line (v15 supported until July 15, 2027) suits teams that prefer slower, planned upgrades. Confirm your own upgrade capacity and hardware sizing with each vendor. |
| Team that must keep the forge fully inside its own network | Confirm for both | Both can be self-hosted, but GitLab's advanced features may require a subscription that changes how you license and support the deployment. Ask both vendors which features work offline and how license keys are handled. |
How each platform is built and what that means for operations
GitLab and Forgejo make different bets about how much runs inside the forge itself. The cards below cover the parts that shape day-to-day operations: what you deploy, where CI jobs execute, how often you must upgrade, and which features sit behind a paid license. Confirm sizing and tier boundaries with each vendor before you commit to a design.
Deployment footprint and sizing
GitLab is a multi-service application with its own bundled components, so the footprint grows with users, repositories and the optional features you enable. Forgejo is a single Go binary backed by a database, which keeps the moving parts few. Hardware sizing for either platform is not something this page can settle. Ask each vendor for reference sizing against your user count, repository volume, CI load and availability target, and ask whether that sizing assumes a single node or a highly available layout.
CI execution model
GitLab CI runs pipelines through GitLab Runner, which you register to the instance and scale separately from the server. Forgejo Actions hands workflows to separate runners as well, so the forge itself does not execute jobs. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions, so existing workflow files and third-party actions need review and likely changes. Check runner registration, isolation for untrusted jobs and how secrets reach each runner before you standardize.
Release and maintenance cadence
GitLab ships a minor release every month on the third Thursday and backports security fixes to the current and previous two releases, with 19.5, 19.4 and 19.3 listed as maintained. Upgrades therefore arrive on a steady monthly rhythm that your team must absorb. Forgejo publishes LTS releases with longer windows, and v15 is supported until July 15, 2027. Plan your upgrade calendar around the cadence you can staff, and confirm backport and patch timing with each vendor's policy before you set a standard.
Licensing boundaries and paid features
GitLab Community Edition is MIT licensed, but files in the ee/ directory are proprietary and need a paid subscription. A team that deploys from the open tree may still find that features it expects sit behind Premium or Ultimate, so map each required capability to its tier in writing. Forgejo is GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, and the project is governed independently of any single company. Confirm which GitLab features your security and compliance controls depend on before you assume they are available in the community tree.
How GitLab and Forgejo compare on CI, security scanning and identity
This table compares licensing, CI design, runner model, GitHub Actions compatibility, security scanning, tier gating, identity and release support windows. Where the supplied facts stop, the cell tells you what to confirm with the vendor's current documentation before you decide.
| Capability | GitLab | Forgejo |
|---|---|---|
| License | 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, with earlier versions under MIT |
| Built-in CI | Built-in CI/CD pipelines are part of the platform; confirm which pipeline features sit in each tier | Forgejo Actions is a built-in CI system that hands workflows to separate runners |
| CI runner model | Runners register with the GitLab instance; confirm runner types and scaling options in current GitLab documentation | Workflows are handed to separate runners, so runner hosts are sized and managed apart from the forge |
| GitHub Actions compatibility | GitLab pipelines use GitLab CI/CD syntax; migration from GitHub Actions requires rewriting workflows | Designed to be familiar to GitHub Actions users but not compatible with GitHub Actions; workflows still need adaptation |
| Built-in security scanning | GitLab offers built-in security scanning features; the exact scanners in each tier must be confirmed in GitLab's current documentation | Confirm with the Forgejo documentation whether any security scanning is built in; the supplied facts do not cover it |
| Features requiring Premium or Ultimate | Some security and compliance features require a paid tier; confirm the exact feature-to-tier mapping with GitLab before purchase | Not applicable |
| Identity integration | Confirm supported SSO and LDAP options for your edition with GitLab's current documentation | Confirm Forgejo's SSO options, including OAuth2 and LDAP support, with the Forgejo documentation |
| Release support windows | Monthly minor releases on the third Thursday; security fixes backported to the current and previous two releases, with 19.5, 19.4 and 19.3 listed as maintained | v15 is the LTS release supported until July 15, 2027; v17.0.0 was released October 15, 2026 with support until January 28, 2027 |
What GitLab and Forgejo license terms mean for your team
GitLab Community Edition is the part of the GitLab codebase published under the MIT license, a permissive license. Your team can install, modify and run it inside its own infrastructure under those terms. The license attaches to specific files, so the practical question is which code your deployment actually uses.
- Permissive terms: MIT allows use, copying, modification and redistribution of the covered code, provided the copyright and license notice stay with it.
- Defined file boundary: The LICENSE file in the gitlab-org/gitlab repository states that files in the ee/ directory are proprietary, so the MIT terms do not reach them.
- No license fee for the code: Community Edition costs come from your hosting, staff time and any support contract you choose to buy.
- Feature gap: Some capabilities exist only in ee/ code, so a Community Edition installation will not include them, whatever your team expects.
Confirm which edition and build your environment runs, and verify with GitLab which features are available in it before you design security or compliance controls around them.
Files in the ee/ directory are proprietary and need a paid subscription. GitLab's paid tiers, Premium and the top paid tier, add capabilities that sit in that code. GitLab sets which features belong to which tier, so the reader must confirm that mapping against current subscription documentation before buying.
- Proprietary code: Files under ee/ fall outside the MIT terms, and running them requires a valid subscription for the instance.
- Feature mapping: Ask GitLab in writing which security scanning, compliance and CI capabilities your team needs, and which tier includes each one.
- Subscription scope: Confirm how the subscription counts users, instances or seats, and how renewals, additions and true-ups are handled.
- Internal use terms: Confirm that the subscription agreement permits use inside your own data center, cloud accounts or air-gapped network, and note any limits on sharing with affiliates or contractors.
Request the subscription agreement and the tier comparison in writing, and send both to counsel before you commit to a tier.
Forgejo is licensed GPL-3.0-or-later from v9.0 onward, while earlier versions are under MIT. According to the Forgejo FAQ, Codeberg e.V. owns the Forgejo domains, and project governance remains independent of that ownership. The version you run therefore determines which license applies, and GPL terms add obligations that MIT does not.
- Version-dependent license: A deployment on a release before v9.0 falls under MIT, while later releases fall under GPL-3.0-or-later, so record the exact version in use.
- Copyleft on distribution: GPL-3.0 requires that copies you distribute, including modified copies, carry source code under the same license. Running Forgejo for your own staff is a different situation from shipping modified binaries.
- Domain ownership and governance: Codeberg e.V. holds the domains while governance stays independent, so ask how that structure affects your continuity planning and any project-level decisions you depend on.
- Naming and branding: Confirm any trademark or naming rules with the project before you rebrand, redistribute or publish a modified build.
Record the Forgejo version in your asset inventory and check the license file that ships with that exact release.
Copyleft and proprietary boundaries shape what your organization must do once software or changes leave its direct control. Whether a copyleft license reaches you often depends on whether you distribute code or only run it internally. Proprietary terms, by contrast, control what you may run, copy and share, whoever wrote the change. Counsel should map each component to the obligations it carries.
- Internal use: Running unmodified or internally modified software for your own staff usually creates fewer license duties than distribution, but counsel should confirm this for your jurisdiction and contracts.
- Distribution to others: Providing copies to customers, partners, subsidiaries or managed service clients can trigger source, notice and license-text requirements under copyleft licenses.
- Proprietary restrictions: Code under a commercial license limits your rights to run, copy or share it, so an internal fork of a proprietary component may still breach the agreement.
- Mixed components: A deployment may combine GitLab, Forgejo, runners, plugins and integrations under different licenses, so keep a bill of materials listing each license.
Give counsel the version list, the license file for each component and a short description of how your teams use the software before you make a decision.
What drives the running cost of GitLab and Forgejo
The running cost of GitLab and Forgejo comes from five places: infrastructure for the forge, runner capacity for CI jobs, the team time spent on upgrades and backups, paid subscriptions for GitLab features your team relies on, and any outside support or retainer. The license terms set the subscription line. GitLab Community Edition is MIT licensed, but files in the ee/ directory are proprietary and need a paid subscription, so that cost appears only if you depend on those features. Forgejo is GPL-3.0-or-later from v9.0 onward, so its license adds no subscription line, and its recurring cost sits mainly in hosting, runners and staff time. Before you budget, confirm with GitLab which features each team needs and whether they sit in ee/.
Separate one-time costs from recurring ones. One-time work includes migrating repositories, users and issues, converting pipelines, and setting up security scanning. Pipeline conversion is the easiest to underestimate: Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with it, so existing workflows need review before they run. Recurring costs are subscriptions, runner capacity and upgrades. User count, pipeline count and job duration drive runner hours, and the number of security features you enable drives both subscription tier and scanner compute. GitLab ships a minor release every month and backports security fixes only to the current and two previous releases, so upgrades are a steady staffing cost. Forgejo v15 is the LTS release supported until July 15, 2027, which lets you plan a longer upgrade window, while v17.0.0 is supported until January 28, 2027.
Ask every bidder for a written quote that itemizes the following: the forge and runner hosts and their sizing assumptions, including the user count, pipeline volume and peak concurrent jobs you supplied; each GitLab feature, the tier it needs and how that subscription is priced; support hours and response expectations; who performs upgrades and how often; backup and restore testing; migration, pipeline conversion and security tooling setup as separate line items; and what is excluded. DeployOpen does not publish a price list. A quote follows from the written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, so ask whether the quote covers them or only the initial build.
How to move repositories and pipelines between GitLab and Forgejo
This sequence moves source, collaboration data and CI from GitLab to Forgejo in an order that keeps the old platform authoritative until the new one has been proven. The output is a documented cutover with a tested pipeline on Forgejo Actions and a decommissioned GitLab instance.
Inventory repositories, users, groups and CI
The platform owner and team leads list every repository, group, user account, issue, merge request, wiki, registry artifact, webhook, and CI configuration in scope, and tag each with an owner and a business purpose. Compare that list with the capabilities in the current import documentation for both platforms, which you should confirm directly with each vendor, since migration tooling changes between releases. The output is a signed-off inventory that shows which items are in scope, which are retired, and which have no clear owner.
Classify data as transferred or rebuilt
The migration lead decides, item by item, what moves as data (Git history, issues, merge request records where the import tooling supports them) and what must be recreated by hand (protected branch rules, approval settings, CI variables, package registry contents, and integrations). Mark anything the tooling cannot carry as a manual task with an owner. The output is a written transfer matrix that the security and compliance teams review before any import runs.
Convert pipeline definitions for Forgejo Actions
Pipeline engineers rewrite each GitLab CI definition into Forgejo Actions workflow files. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions, so any workflow that depends on GitLab CI syntax, GitLab-specific variables, or GitHub Actions marketplace actions must be rewritten or replaced with an equivalent step. Inventory every external action, container image, and secret reference during this work. The output is a version-controlled set of workflows with a short note per pipeline on what changed.
Test pipelines on Forgejo Actions runners
Operators register dedicated Forgejo Actions runners, separate from the GitLab runners, and run each converted workflow against a copy of a representative repository. Testers compare build artifacts, test results, and deployment outputs with the GitLab baseline and record every difference. Security engineers confirm that secrets are scoped correctly and that runner isolation matches the policy for the environment. The output is a test log that shows each pipeline producing equivalent results, with open defects tracked to closure.
Reconnect identity and access controls
The identity team configures single sign-on and group mapping on Forgejo so that users sign in with the same directory accounts and receive the same role boundaries they had in GitLab. Access owners check that repository permissions, team membership, and deploy keys match the approved matrix, and they remove any account that should not carry over. Confirm the authentication options each platform supports in its current documentation before you commit to a design. The output is an access review where every production repository has a named owner and a verified set of permissions.
Run a parallel period with both platforms
Teams mirror active repositories to Forgejo while GitLab stays the system of record, and developers push to both where the workflow allows it. Operators track pipeline results, runner health, and access tickets on both sides during this window and hold a daily review of mismatches. The period ends when the team agrees, in writing, that the Forgejo pipelines and access model meet the acceptance criteria. The output is a reconciliation record that shows the parallel run is clean for each in-scope repository.
Cut over and decommission GitLab
The change board approves a cutover date, the final data sync runs, and developers switch their remotes and CI triggers to Forgejo. GitLab goes to read-only mode, and the team takes and verifies a final backup before any shutdown, keeping the backup under the retention rules set by compliance. Once retention obligations are met, the team removes GitLab runners, integrations, and access, and updates the architecture records. The output is a closed change record, a verified archive, and a decommissioning certificate signed by the platform owner.
Where GitLab and Forgejo projects usually run long
Pipeline conversion and runner capacity are the two items most often underestimated. A GitLab CI configuration written in .gitlab-ci.yml does not move to Forgejo unchanged, because Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions. Each pipeline needs to be inspected, rewritten where its syntax or dependencies differ, and tested on runners that the client hosts. Runner sizing is a separate exercise: concurrency, build caches, container image pulls and any GPU or privileged build jobs all drive capacity, and the team should measure current GitLab runner queue times before deciding how many runners to provision in each environment. Confirm the exact runner executor types and job features your pipelines use against the current Forgejo Actions documentation before scoping this work.
Permission models are the second common source of delay. GitLab groups, subgroups, project roles and, on higher tiers, custom roles and approval rules need to be mapped to Forgejo organizations, teams and repository permissions. Identity integration (SSO, group sync and service accounts for CI) has to be designed against the identity provider the client actually uses, and the mapping should be reviewed by the people who approve access, not only by the engineers doing the configuration. Ask the platform owner to list every GitLab feature that controls who can merge, deploy or view a secret, because the answers determine whether the migration is a direct translation or a redesign.
Upgrade windows are where timelines most often clash with the release cycle. GitLab ships a minor version monthly and maintains the current and previous two releases, so a team that falls behind has a shorter runway than it expects. Forgejo publishes on its own schedule, with v15 as the LTS release supported until July 15, 2027, and v17.0.0 supported until January 28, 2027. A fixed-scope engagement sets scope, deliverables and timelines in writing before work starts, and DeployOpen does not publish timelines or fees, so ask for the backup and restore test plan, the upgrade plan against the release calendar and the runner sizing assumptions to be written into the statement of work before anyone commits to a go-live date.
Questions buyers ask before choosing between GitLab and Forgejo
What drives the cost of running GitLab compared with Forgejo?
The largest cost difference usually comes from licensing tiers and the infrastructure each platform needs, not from the software itself. GitLab Community Edition is MIT licensed, but files in the ee/ directory are proprietary and need a paid subscription, so features you need from those files add a recurring license cost. Forgejo is licensed GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, and does not carry a comparable paid tier in the facts we have. Ask any provider to price the license line separately from implementation, hardware, backup storage and your team's ongoing administration time.
How long does a GitLab or Forgejo implementation take?
Duration depends on scope, not on the product name alone. The main variables are the number of users and repositories to migrate, how many CI pipelines and runners you need, whether you connect single sign-on and existing security scanning, and how many environments (test, staging, production) must be built and hardened. Most engagements are fixed-scope, so the timeline is agreed in writing before work starts and should list each deliverable separately. Ask for the timeline to be tied to named milestones, not a single end date.
What does the work require from our own team?
Your team provides decisions and access, and an implementation partner provides the build and documentation. Expect to name owners for identity integration, network and firewall changes, backup policy, and the list of repositories and projects that move first. Engineers who will run the platform day to day should take part in configuration reviews so they can operate it after handover. Confirm the exact access requirements and approval steps with the partner before work begins, since they vary by cloud account, data center or air-gapped network.
Can we run the migration to Forgejo or GitLab without a partner?
Yes, many teams do, provided they have the time and skills in-house to plan repository moves, test restores, and re-create permissions and CI configuration. A partner adds value where the migration touches regulated evidence, hardening baselines or many integrated systems, because those tasks need documented controls. Estimate the internal effort by listing every repository, pipeline, webhook and integration, then decide which items your team can verify. Retaining a partner for only part of the work is also an option under a written scope.
Can Forgejo Actions run our existing GitHub Actions workflows?
Not without changes. Forgejo Actions is a built-in CI system that hands workflows to separate runners and is designed to be familiar to GitHub Actions users, but the Forgejo documentation states it is not compatible with GitHub Actions. Existing workflows will likely need edits to syntax, actions referenced from marketplaces and secrets handling. Inventory each workflow, check every third-party action it calls, and run a pilot on a non-production repository before planning a bulk move. The Forgejo Actions overview is the right starting point for checking specific features.
Which GitLab features require a paid tier?
Features in the ee/ directory of the GitLab repository need a paid subscription, according to GitLab's LICENSE file, so the Community Edition is not a full copy of the commercial product. Which advanced security scanning, compliance, and governance capabilities sit in each paid tier is set by GitLab's current pricing, and that changes over time. Before comparing, list the specific features your controls depend on, such as scanning, approval rules or audit reporting, and confirm the tier for each with GitLab in writing. Do not assume a feature is free because the Community Edition is MIT licensed.
How do upgrade cadences affect our long-term support plan?
GitLab releases a minor version monthly on the third Thursday and backports security fixes to the current and previous two releases, listing 19.5, 19.4 and 19.3 as maintained, according to its maintenance policy. 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. A monthly cadence means your team must plan regular upgrades, while an LTS track gives longer, predictable windows. Ask any provider to include upgrade testing and rollback in the written scope and to state which branch they will support.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For GitLab vs Forgejo, we start with the decision you need to make, then build and hand over only the platform that fits your environment.
How we scope
- We confirm which GitLab tier or Forgejo release line your pipelines, security scanning and compliance evidence actually require.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
- We document hardware, runner placement and upgrade cadence so the written scope reflects your environment and approval path.
How we build
- We install and configure the chosen forge inside your cloud accounts, data centers or air-gapped network.
- We set up CI runners, Forgejo Actions or GitLab pipelines, and integrate identity, backups and repository access controls.
- We run security testing against the forge and its pipelines before handover, and record the results.
How we hand over
- You receive written documentation covering configuration, runner setup, access model and the upgrade procedure we agreed.
- We walk your platform and operations teams through day-to-day administration, backup restores and release upgrades.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover moving between Forgejo release lines or GitLab monthly releases as your support window requires.
- Ask any quote to itemize one-time implementation work separately from recurring retainer, licensing and runner hosting costs.
