Which self-hosted Git host fits your team
If you are leaving GitHub and want a forge you run yourself, GitLab fits teams that need one platform for source, CI/CD, security scanning and compliance across many groups, and that can staff the operating weight of a larger install. Forgejo fits teams that want a GPL-3.0-or-later Git forge with community governance and a GitHub-like Actions experience, and Gitea fits teams that want a small, MIT-licensed footprint and can accept a commercial edition for SAML, audit logging and mandatory two-factor authentication. The core trade-off is scope against weight. GitLab covers the most ground, but its reference architectures start at 1,000 users, and the 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 and Gitea run on far less, which matters if you are a smaller team or a single site.
Licensing needs a precise read before you commit. GitLab Community Edition is MIT licensed, but files in the ee/ directory are proprietary and need a paid subscription, so GitLab is open core rather than fully open source as a whole. 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. Gitea is MIT licensed, and CommitGo, Inc. sells Gitea Enterprise, which adds SAML 2.0 service provider support, audit logging and IP allowlisting. Ask each vendor which features your compliance controls depend on, and confirm whether they sit in the free build or a paid tier before you plan around them.
Plan the CI/CD and migration path before you pick. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, while Gitea Actions is designed to be compatible, so check how many of your existing workflows must run unchanged. Confirm the upgrade path with the vendor: Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps, and GitLab requires passing through required upgrade stops. Run a pilot import of a representative repository set and a sample pipeline on your candidate before committing to the forge.
Which Git host fits which scenario
This table matches common team situations to the Git host that fits best, with the reason tied to licensing, offline guidance, footprint and governance. Read each row as a starting point, then confirm the items marked as points to confirm against the current product documentation and your own environment before deciding.
| Scenario | Best fit | Reason and what to confirm |
|---|---|---|
| Regulated team needing air-gapped operation and a full security scanning suite | GitLab | GitLab documents offline, air-gapped self-managed installs and separate guidance for running its security scanners offline. Its scanning and compliance features sit in the Ultimate tier, which is custom priced. Confirm the exact scanner set for your tier and whether each scanner works offline in your environment. |
| Regulated team needing air-gapped operation with a lighter footprint | Gitea or Forgejo | Both run on modest hardware and support self-hosted installs. Gitea Enterprise adds SAML 2.0, audit logging and mandatory two-factor authentication, while Forgejo is GPL-3.0-or-later. Confirm offline installation steps and any scanning or audit features with the vendor before relying on them. |
| Small team wanting a lightweight forge | Gitea | Gitea is MIT licensed, written in Go, and covers Git hosting, code review, package management and CI/CD in one service. It runs on small systems such as a Raspberry Pi. Confirm that its database and package registry choices match your backup and retention needs. |
| Small team that values a single-binary, minimal-effort forge with community governance | Forgejo | Forgejo is GPL-3.0-or-later from v9.0 and has an LTS release line with a stated support window. Its governance stays independent of any company. Confirm the upgrade path that applies to your current version and the support window for the release you plan to run. |
| Community or public-sector team valuing GPL governance | Forgejo | Forgejo is GPL-3.0-or-later from v9.0, earlier versions are MIT, and Codeberg e.V. owns its domains while project governance remains independent. Confirm with your procurement or legal team how the license change from MIT to GPL affects any earlier version you already run. |
| Public-sector team that needs a commercial support contract with a paid tier | GitLab Premium or Ultimate, or Gitea Enterprise | GitLab Premium lists advanced CI/CD and priority support, and Ultimate lists security and compliance features. Gitea Enterprise is sold by CommitGo, Inc. Confirm which tier includes the controls your auditors ask for, since prices and feature availability are set by each vendor. |
| Team already on Kubernetes with GitOps | GitLab with Cloud Native Hybrid layout, or Forgejo or Gitea alongside Argo CD or Flux | GitLab's reference architectures do not support running stateful components such as PostgreSQL and Redis inside Kubernetes, so the Cloud Native Hybrid layout keeps them on VMs or managed services. Argo CD and Flux, both Apache-2.0, handle the deployment side regardless of which forge hosts the Git repositories. Confirm your database and runner placement before choosing. |
| Team that wants GitHub Actions workflow reuse | Gitea, with a compatibility check | Gitea Actions is designed to be compatible with GitHub Actions. Forgejo Actions is designed to be familiar but is not compatible. Confirm that the specific actions and runners you depend on work on the target forge before migrating workflows. |
| Team with high user counts needing a high availability plan | GitLab | GitLab's reference architectures range from 1,000 to 50,000 users, and it generally recommends a high availability strategy at 3,000 or more users. Confirm the sizing with the reference architecture documentation and your own load profile, since Gitea and Forgejo high availability guidance is outside the supplied facts. |
What the license and paid tiers mean for GitLab, Forgejo and Gitea
GitLab is an open-core product, and the license line runs through the source tree. Content outside the ee/ directory is MIT licensed, while files inside ee/ are proprietary and need a paid subscription, according to the LICENSE file in the gitlab-org/gitlab repository. GitLab Free costs 0 US dollars, Premium costs 29 US dollars per user per month billed annually, and Ultimate is custom priced. All three tiers are available for self-managed installations, so the tier you buy does not change where you host. Premium adds advanced CI/CD and priority support. Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features. Those features matter when your auditors or security team need scanning and vulnerability workflows inside the forge itself. If you do not need them, Free may cover the platform, and you should confirm current tier contents on the GitLab pricing page before budgeting.
Forgejo takes a different position. It is licensed GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, and Codeberg e.V., a non-profit association, owns its domains while project governance stays independent, according to the Forgejo FAQ. For a self-hosted team, this means the core forge has no paid edition to purchase and no separate enterprise code path to track. The licensing question shifts to the version you deploy: a team staying on a pre-v9.0 build is under MIT, while newer builds carry the copyleft obligations of GPL-3.0-or-later when you modify and distribute them. Legal and procurement teams should read the current license file in the Forgejo repository and the Forgejo FAQ rather than assume one license covers every version in the field.
Gitea is MIT licensed, and the core product carries no copyleft conditions. CommitGo, Inc. provides leadership and commercial support and 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. These controls matter when an identity team must federate logins through SAML, when auditors ask for a change trail, or when policy requires every account to use a second factor. Teams that can meet those controls with reverse proxies, external identity tooling and their own review processes may run the free build. Ask CommitGo for the current Enterprise terms, support scope and per-seat or per-instance pricing in writing, and confirm that the feature list matches the version you intend to run.
How GitLab, Forgejo and Gitea compare on capability
This table compares GitLab, Forgejo and Gitea on license, CI/CD, package registries, databases, operating systems, high availability, offline installation, upgrade paths and managed options. Read each row as a question to answer for your own environment, and treat any cell marked for confirmation as a point to check in the vendor documentation before you commit.
| Capability | GitLab | Forgejo | Gitea |
|---|---|---|---|
| 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, earlier versions under MIT | MIT licensed, written in Go |
| Governance | GitLab Inc. develops the open-core product and sells paid tiers | Project governance stays independent, with Codeberg e.V. owning its domains | CommitGo, Inc. provides leadership and commercial support |
| Built-in CI/CD | GitLab CI with advanced CI/CD listed for the Premium tier | Forgejo Actions, designed to be familiar to GitHub Actions users but not compatible with them | Gitea Actions, designed to be compatible with GitHub Actions |
| Package registries | Confirm supported package types for your tier in GitLab documentation | Confirm supported package types in Forgejo documentation | More than 20 registry types, including npm, PyPI, Maven, container images and Helm charts |
| Databases | Bundled PostgreSQL in the Linux package, with PostgreSQL and Redis as core components | Confirm supported database engines in Forgejo documentation | MySQL, PostgreSQL, SQLite and MSSQL |
| Operating systems | Linux package, Helm chart, GitLab Operator, Docker or source installation | Confirm supported operating systems and install methods in Forgejo documentation | Linux, macOS and Windows, including small systems such as a Raspberry Pi |
| High availability guidance | Docs generally recommend HA for 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul | Confirm HA architecture and supported topologies with Forgejo | Confirm HA architecture and supported topologies with Gitea documentation |
| Offline installation | Documented for offline, air-gapped environments, with separate guidance for security scanners | Confirm offline installation and update process in Forgejo documentation | Confirm offline installation and update process in Gitea documentation |
| Upgrade paths | Required upgrade stops since GitLab 17.5 at x.2, x.5, x.8 and x.11 | Stable releases get three months of full support plus a two-week window, LTS releases one year and three months of critical fixes | Transparent upgrades from Gitea up to v1.22 in two steps through Forgejo v10.0.x |
| Managed option | Available as a SaaS service in addition to self-managed tiers | Confirm managed hosting options with Codeberg or other providers | Gitea Cloud, a managed service alongside self-hosted installs |
GitLab, Forgejo and Gitea in brief
All three are self-hosted Git forges that can replace GitHub for code hosting, review and CI. They differ in license model, who steers the project, and how much release discipline and upgrade planning they ask of your team.
GitLab as an open-core platform
GitLab is the broadest option here, combining Git hosting, CI/CD, security scanning and compliance features. The Community Edition code outside the ee/ directory is MIT licensed, while ee/ files need a paid subscription, so confirm which tier covers each feature you plan to use. A monthly minor release ships on the third Thursday, and maintained versions are currently 19.5, 19.4 and 19.3. Required upgrade stops fall at x.2, x.5, x.8 and x.11, so plan upgrades around them. Install methods include the Linux package, Helm chart, GitLab Operator, Docker and source.
Forgejo under community stewardship
Forgejo is a community-governed forge. Since v9.0 it is licensed GPL-3.0-or-later, with earlier versions under MIT. Codeberg e.V., a non-profit association registered in Berlin, owns its domains while project governance stays independent. Check the support window before you standardize: v17.0.0 is supported until January 28, 2027, and the LTS release v15 is supported until July 15, 2027. Forgejo Actions is familiar to GitHub Actions users but is not compatible with GitHub Actions, so existing workflows need rework.
Gitea with MIT licensing
Gitea is MIT licensed and written in Go, and it runs on small systems as well as servers. It bundles Git hosting, code review, package registries for more than 20 types and Gitea Actions, which is designed to be compatible with GitHub Actions. The latest release noted here is v28.1.0, published October 6, 2026. CommitGo, Inc. provides leadership and commercial support and sells Gitea Enterprise, which adds SAML 2.0, audit logging and mandatory two-factor authentication. Ask CommitGo which support terms apply to your deployment.
Choose by governance and upgrade load
The three options split on who controls the roadmap and how much operating work they demand. GitLab suits teams that want one vendor-backed platform and can staff planned upgrades and the reference architecture. Forgejo suits teams that prefer community governance and an LTS track. Gitea suits teams that want a lightweight MIT forge with an optional commercial edition. Confirm each project's current support window before you commit.
How much operating effort each Git host needs
The main driver of effort is how many users the Git host must serve and how much high availability you need to build around it. GitLab publishes reference architectures from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 API requests per second, and its documentation generally recommends a high availability strategy for 3,000 or more users. That recommended setup uses Gitaly Cluster with Praefect for repository storage, PostgreSQL with Patroni, Redis Sentinel and Consul. Each of those components is a system your team must install, tune, monitor and recover. The reference architectures documentation also states that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. If you plan a container platform, the Cloud Native Hybrid pattern keeps stateless services on Kubernetes and places stateful services on VMs or managed services, so budget for that split before you pick a layout. Ask GitLab to confirm which architecture matches your user count, peak API load and availability target, and whether your planned deployment method is covered.
Gitea sits at the other end of the range. It supports MySQL, PostgreSQL, SQLite and MSSQL, and it runs on Linux, macOS and Windows, including small systems such as a Raspberry Pi. A small team can run it on one modest host with an embedded or existing database, which removes most of the clustering work. That advantage holds only while your load, repository count and CI volume stay modest and you accept the availability you get from a single node with backups. Before you commit, ask CommitGo, Inc. and your own engineers to confirm the sizing for your user count, the database they recommend at that scale, and how high availability is handled, if at all, for your workload. Forgejo, which descends from the same codebase, should be checked the same way against its own documentation.
Recurring work is where most of the cost sits after go-live, and it applies to every option. Upgrades need a planned window, a tested rollback and a check of the vendor's upgrade path. GitLab requires upgrades to pass through required upgrade stops, which fall at versions x.2, x.5, x.8 and x.11 since GitLab 17.5, so a multi-version jump needs staged work. Backups must cover repositories, the database and configuration, and restores must be rehearsed on a schedule, using the GitLab backup and restore documentation as a starting point. Security patching means tracking each release line's support window: GitLab backports security fixes to the current and previous two releases, and Forgejo stable releases receive three months of full support. Put these tasks in a written runbook with named owners and a quote that prices them separately from the initial build.
How to plan a migration from GitHub to a self-hosted forge
This sequence moves repositories, CI and access from GitHub to a forge you run, with each step ending in a check that proves the previous one worked before production cutover.
Inventory repositories, workflows and packages
The engineering lead and a platform owner list every repository, its size and history depth, branch protection rules, webhooks, and the GitHub Actions workflows and packages (container images, npm, PyPI, Maven, Helm charts) each one depends on. Record which repositories are active and which are archived, because archived projects often do not need to move. The output is a single inventory sheet with an owner and a move decision for each item, reviewed by the security team before any import work starts.
Confirm the target forge and its license terms
The architect compares GitLab, Forgejo and Gitea against the inventory, weighing license terms, which paid tier or edition is needed for features such as SAML, audit logging or advanced CI, and whether the team can run the stated resource footprint. Confirm current release support windows with each vendor, since Forgejo publishes LTS and stable support periods and GitLab backports security fixes to a limited set of releases. The check is a signed decision record that names the host, the edition and the support model.
Build a staging instance and test imports
The platform team installs the chosen forge in a staging environment that matches the intended production layout, using the installation method the vendor documents for that platform. They then import a representative sample of repositories, including one large repository, one with long history and one with LFS or large binaries, using the vendor's import documentation. Verify commit counts, tags, branch protection, issues and pull requests against the source. The check is a import report signed off by the repository owners.
Port CI definitions and test them
Developers rewrite GitHub Actions workflows into the target CI system. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, and Gitea Actions is designed to be compatible with GitHub Actions. Each workflow is therefore checked action by action: third-party actions, secrets, runner labels and cache steps must be confirmed on the chosen platform rather than assumed. Runners are registered as separate agents. The check is a green pipeline run on staging for every production-critical workflow.
Configure authentication, access and secrets
The identity team connects the forge to the corporate identity provider using the protocols the chosen edition supports, maps groups to roles, and enforces multi-factor authentication. Deploy keys, personal access tokens and CI secrets are reissued rather than copied, and the owners of each service account are named. The check is a documented access matrix and a test login by each role, with a record of which accounts were removed.
Plan upgrades and backups before production
Before production, the operations team writes the upgrade procedure and the backup and restore procedure. For GitLab, this means following the required upgrade stops published in its upgrade paths documentation and its backup and restore guidance. For Forgejo, it means checking the upgrade guide and the support window of the release line in use. Restore a backup into a separate instance and confirm repositories, CI history and packages come back intact. The check is a tested restore with a recorded time and an owner for each upgrade.
Run a pilot with a small set of teams
One or two teams work in the new forge for a defined period while GitHub stays read-only for their repositories. They report issues with pull requests, CI runners, notifications and packages, and the platform owner tracks each defect to closure. Pilot exit criteria are agreed in writing before the pilot starts, covering pipeline success, access reviews and restore tests. The check is a pilot report listing open defects and their accepted risk.
Cut over and retire GitHub access
The team schedules a cutover window, freezes pushes to GitHub for the migrating repositories, runs a final import of changes, updates remote URLs, webhooks and deployment references, and switches CI triggers to the new forge. GitHub repositories are set to read-only and kept for an agreed retention period. The check is a post-cutover verification of pushes, pipelines and deployments, followed by a sign-off from the engineering and security owners.
Choosing a forge by team size and governance needs
An enterprise DevSecOps team usually needs one platform that covers source control, CI/CD, security scanning, and compliance reporting under a single administrative model. GitLab is the option that most often fits this profile, because its paid tiers add the scanning and governance features these teams are asked to prove. Premium adds advanced CI/CD and priority support, and Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features, according to GitLab's pricing page.
- Feature breadth: GitLab Ultimate groups security scanning and compliance features that otherwise need separate tools to integrate and maintain.
- Paid tier cost: Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced, so the per-seat cost recurs for every user who needs the feature set.
- Upgrade discipline: GitLab requires passage through upgrade stops, so teams need a planned upgrade calendar and a tested rollback path.
- Resource footprint: Reference architectures scale from 1,000 users to 50,000 users, and high availability is generally recommended from 3,000 users, which means dedicated capacity and operator time.
- When another option wins: If the team only needs Git hosting with light CI and does not need the Ultimate feature set, a lighter forge such as Forgejo or Gitea usually lowers both seat cost and operating load.
Confirm the exact feature mapping for your required controls with GitLab's current tier documentation before you commit to a tier.
Regulated and air-gapped operators care most about where the code and build data live, who can audit configuration, and whether the platform can run without internet access. GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners. Forgejo is a strong candidate when the governance of the software matters as much as its features, because its license moved to GPL-3.0-or-later from v9.0 onward and its project governance stays independent of any single company.
- Offline operation: GitLab has published guidance for offline environments, including scanner and GitLab Duo Self-Hosted considerations, so review each of those pages against your network design.
- Governance clarity: Forgejo's FAQ states that Codeberg e.V. owns its domains while project governance stays independent, which many public sector buyers treat as a procurement point.
- Enterprise identity controls: Gitea Enterprise adds SAML 2.0 service provider support, audit logging, IP allowlisting and mandatory two-factor authentication, per the Gitea Enterprise page.
- Support windows: Forgejo LTS releases receive critical bugfixes and security support for one year and three months, so the upgrade calendar must match that window.
- When another option wins: If your auditors require a commercial support contract with defined response commitments, check each vendor's support terms directly, because the supplied facts do not describe SLAs.
Ask each vendor for written answers on offline installation, audit log coverage and support terms for your exact version before scoring.
A small or community team usually values low resource use, simple installation, and a license that does not require a paid tier to get the core workflow. Gitea is MIT licensed, written in Go, and runs on small systems including a Raspberry Pi, per its documentation. Forgejo is a close alternative when the team wants a GPL forge with community governance. Both avoid the operating load of a multi-component platform.
- Light footprint: Gitea supports MySQL, PostgreSQL, SQLite and MSSQL, so a small team can start with SQLite and move to a larger database later.
- Package registries: Gitea supports more than 20 package registry types, which covers many small team needs without a separate registry service.
- Community governance: Forgejo's governance stays independent, and its CI, Forgejo Actions, is built in but not compatible with GitHub Actions, so pipelines must be rewritten when moving from GitHub.
- Compatibility of CI: Gitea Actions is designed to be compatible with GitHub Actions, which can reduce workflow rewriting for teams leaving GitHub.
- When another option wins: If the team grows past a few hundred developers or needs integrated security scanning, GitLab's tiered model becomes easier to justify despite its higher operating load.
Check whether your current CI workflows depend on GitHub Actions features before choosing between Gitea Actions and Forgejo Actions.
A Kubernetes-first platform team often wants Git as the source of truth for cluster state, which shifts the forge question toward how it integrates with GitOps controllers. The forge still hosts the repositories, but the reconciliation work belongs to Argo CD or Flux. Both are Apache-2.0 and both integrate with Git-hosted manifests, so the forge choice matters mainly for webhooks, access control and runner placement.
- GitOps integration: Argo CD runs as a Kubernetes controller with a web UI, manages multiple clusters and integrates SSO over OIDC, OAuth2, LDAP and SAML 2.0.
- Multi-tenancy model: Flux uses Kubernetes RBAC with impersonation for multi-tenancy and supports Helm, Kustomize and OCI artifacts.
- Stateful components: GitLab's reference architectures say stateful components such as PostgreSQL and Redis should not run inside Kubernetes, so the Cloud Native Hybrid pattern keeps those on VMs or managed services.
- Runner placement: GitLab Runner and Forgejo runners execute jobs separately from the forge, so decide early whether runners run in the cluster or on dedicated hosts.
- When another option wins: If the team wants everything inside one cluster with no separate stateful services, a lighter forge with a smaller footprint may simplify operations.
Confirm the GitLab reference architecture and runner placement against your cluster design before you finalize the forge.
How to choose and pilot a self-hosted Git host
This sequence turns the GitLab, Forgejo and Gitea comparison into a decision your team can defend. It ends with a pilot on your own repositories and a tested recovery path, not a feature checklist.
Define must-have features first
Platform, security and engineering leads list the requirements that would block a decision: CI/CD style, SSO and role mapping, audit logging, branch protection rules, package registries, air-gapped installs and expected user counts. Mark each item as must-have or nice-to-have. The step is done when the list is short enough that each item can be tested in a pilot.
Check license and tier against requirements
For each candidate, compare the must-have list against the license and edition it would run under. For GitLab, confirm which features sit in the MIT-licensed Community Edition and which require a paid subscription in the ee/ directory. For Gitea, check whether SAML 2.0, audit logging or IP allowlisting are in Gitea Enterprise. For Forgejo, confirm the license version for your release. Ask each vendor in writing which features your tier includes for self-managed use. Done when every must-have maps to a named edition or a named gap.
Size the environment with each vendor
Ask each vendor, or the team that will run the platform, for a sizing recommendation based on your user count, repository volume, CI job concurrency and peak API load. GitLab publishes reference architectures that scale by user count and requests per second, and recommends a high availability design for larger user counts, so confirm which layout applies to you. Forgejo and Gitea sizing depends more on database and runner choices, so request their guidance in writing. Done when you have a sizing document per vendor that lists compute, database, storage and runner counts.
Run a pilot with real repositories and CI jobs
Import a representative set of repositories, including large histories, LFS content, and at least one project that depends on your package registries. Move a few real pipelines, with their runners and secrets handling, onto each candidate. Test webhooks, merge request or pull request review flows, and SSO sign-in with a non-admin account. Record job failures, runner setup effort and any workflow that needed rewriting. Done when each pilot has a written list of what moved cleanly, what needed changes and what was not possible.
Test backup, restore and upgrade paths
Take a backup from the pilot instance, restore it to a separate host, and confirm repositories, users, permissions, CI configuration and attachments come back intact. Then rehearse an upgrade. For GitLab, check the required upgrade stops in its upgrade paths documentation. For Forgejo, confirm the support window of your chosen release line and whether you are on the LTS track. For Gitea, check the release line you target and the migration guidance for your current version. Done when you can state the restore time you observed, the upgrade steps you rehearsed and any manual work they required.
Confirm air-gap, hardening and compliance needs
If the platform must run offline or under a hardening baseline, check the offline installation guidance and hardening recommendations for each candidate, and identify which scanners or AI features need separate offline setup. Ask your compliance lead which evidence the assessors will request, such as access reviews, audit logs and change records, and confirm that each candidate can produce it. DeployOpen can prepare systems and evidence for these reviews, but independent auditors issue any attestation. Done when each open item has an owner and a confirmed answer.
Decide and write down the cost of switching
Score each candidate against the must-have list, the pilot results and the sizing documents. Write down the recurring costs: subscriptions or edition fees, infrastructure, runner capacity, and the staff time to patch and upgrade. Note the one-time costs of migration and any workflow rewrites. Ask for a written, fixed-scope quote from any implementation partner before committing. Done when the decision memo states the chosen platform, the rejected options with reasons, and the migration path you would need if the choice changes later.
Self-hosted Git hosting questions buyers ask
What drives the cost of self-hosting GitLab compared with Forgejo or Gitea?
The software license is not the main difference. GitLab Community Edition is MIT licensed, Forgejo is GPL-3.0-or-later from v9.0 onward, and Gitea is MIT licensed, so none of them charges a license fee for the core product. The cost comes from the paid tiers, the infrastructure and the people who run it. The GitLab pricing page lists Premium at 29 US dollars per user per month billed annually and Ultimate as custom priced, and both are available for self-managed installations. The larger cost is usually the platform footprint: GitLab's reference architectures scale from 1,000 users to 50,000 users, and the docs generally recommend a high availability strategy at 3,000 or more users. Ask any vendor for a written sizing against your user count, your CI volume and your storage growth, and ask which parts of the bill recur every year.
How much operating effort does each Git forge need to run?
Effort scales with the number of moving parts you choose to operate. A single-node Gitea or Forgejo install with SQLite or PostgreSQL is a small service to keep patched and backed up. GitLab's Linux package bundles PostgreSQL, Redis and Sidekiq, which keeps installation simple, but a high availability layout adds Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. GitLab also ships a major release yearly and a minor release monthly, and it requires upgrades to pass through required upgrade stops such as 18.5, 18.8 and 19.2. Forgejo stable releases receive full support for three months plus a two-week window, and its LTS releases receive support for one year and three months, so you will schedule upgrades on a shorter cycle. Confirm the upgrade cadence you can staff before choosing a version line.
Can a small team run a self-hosted Git server on its own?
A small team can run Gitea or Forgejo alone for a modest user base, provided one person owns backups, upgrades and monitoring. Gitea runs on Linux, macOS and Windows and supports SQLite, PostgreSQL, MySQL and MSSQL, so the starting footprint is small. GitLab is a heavier system. The GitLab reference architectures start at 1,000 users, and the docs generally recommend high availability at 3,000 or more users, so a small team should plan a single-node layout and confirm that the upgrade cadence fits its capacity. Teams that need CI, package registries and security scanning on the same platform should count those services as additional work. If nobody on staff can absorb monthly or quarterly upgrades, a fixed-scope implementation with a written support plan or a retainer is a common option, and DeployOpen offers both.
How long does a migration to a self-hosted Git forge take, and what drives that time?
No supplied fact gives a migration duration, so treat any timeline as something to agree in writing. The main drivers are the number of repositories, the size of history and binary assets, the number of users and SSO configurations to move, and how much CI configuration must be rewritten. Forgejo documents transparent upgrades from Gitea up to Gitea v1.22 in two steps, which matters if you are already on that line. GitLab documents import tools for moving projects, but pipelines and integrations usually need manual work. Forgejo Actions and Gitea Actions are not GitHub Actions compatible in the Forgejo case, while Gitea Actions is designed to be compatible, so workflow rewrites differ by target. Ask for a migration inventory, a pilot with a representative set of repositories and a cutover rehearsal before you agree on a schedule.
What does the work need from our own staff?
Expect your staff to make decisions and own outcomes even when an implementation partner does the build. Your team needs identity owners who can configure SSO, a network or platform owner for the hosts, backup and restore owners who can test recovery, and developers who will review pipeline changes. GitLab's authentication documentation covers several sign-in methods, and Gitea Enterprise adds SAML 2.0 service provider support, so confirm which method your directory supports. GitLab documents offline and air-gapped installs, which affects how you mirror packages and scanner data. Ask the vendor or partner to list each role, the hours per month it implies and the handover documents it will produce.
Does GitLab Community Edition cover our needs?
GitLab Community Edition covers core Git hosting, but it does not include the files under the ee/ directory, which are proprietary and need a paid subscription. The open-core split means the MIT licensed portion covers the basics, while advanced CI/CD and priority support sit in Premium and application security, supply chain security, vulnerability management and compliance features sit in Ultimate. Check each requirement against the GitLab pricing page and the LICENSE file before you decide. If you need SAML 2.0 service provider support, audit logging, IP allowlisting or mandatory two-factor authentication, confirm whether those features are in Community Edition for your version, because the answer depends on the feature and the release. A written feature checklist from the vendor is the safest starting point.
Which forge should we choose if we need CI and package registries built in?
All three forges include built-in CI and package features, but their depth and compatibility differ. GitLab bundles CI/CD with its platform, and its Premium tier lists advanced CI/CD. Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts, and Gitea Actions is designed to be compatible with GitHub Actions. Forgejo Actions hands workflows to separate runners and is familiar to GitHub Actions users, but it is not compatible with GitHub Actions. If your workflows are written for GitHub Actions, the compatibility claim matters most, so test your actual pipelines on a pilot instance before choosing. Ask each vendor for the runner layout they recommend, including how runners are isolated and scaled.
How DeployOpen scopes and delivers a Git hosting project
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Git hosting project, that means agreeing the forge choice, its supporting services and its operating model in writing before any build work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the chosen forge, its database, CI runners, identity integration and any package or container registry features in use.
- Scoping records license and edition decisions, such as which GitLab features are in scope, so procurement sees exactly what is being paid for.
How we build
- Installation follows the chosen method, such as Linux package, Helm chart, Docker or a Forgejo or Gitea binary, in your environment.
- Work covers integration with your identity provider, CI runner placement, repository mirroring and any required hardening steps.
- Security testing of the deployed forge and its CI pipeline can be included in the written scope.
How we hand over
- Handover includes documentation of the deployed architecture, configuration, backup and restore procedures and upgrade steps.
- Your team receives runbooks for migrations from the current host, including how repositories, users and CI definitions are moved.
- Compliance-relevant evidence, such as access settings and audit logging configuration, is documented for your assessors. DeployOpen prepares this evidence but does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning follows the vendor's published release and support windows, which your retainer scope should state.
- Ask for the retainer scope in writing, covering response expectations, upgrade cadence and which versions are covered.
