Prologue — Git is distributed, but the forge is always centralized

Git itself is a distributed version control system that pushes and pulls peer-to-peer. But what we call GitHub or GitLab — issues, pull requests, code review, CI, permissions, wikis, discussions — is not Git. That layer is the forge. And the history of forges is not one of distribution but of centralization.

After GitHub launched in 2008, almost every open-source project migrated to it. Microsofts 2018 acquisition cemented that gravitational pull. By 2026 GitHub is the de facto standard. And yet the pressures that push toward self-hosting are still very real — "we need this inside our network", "we have to comply with Korean or Japanese data protection rules", "we need a backend we control that does not depend on GitHubs uptime". Self-hosted Git forges fill that gap.

In spring 2026 the landscape splits into three camps. On one side sits Gitea, the most popular self-hosted forge — but Gitea went through a governance controversy in 2022 that produced a community fork called Forgejo, led by Codeberg. On the second side sits the open-core giant GitLab, with its free CE and paid EE. OneDev, a Java-based single-binary alternative, has quietly built a small following. The once-prominent RhodeCode effectively folded in 2024 after financial trouble, and Atlassian killed Bitbucket Server in February 2024, leaving only the more expensive Bitbucket Data Center for self-hosting.

The minimalist camp is alive too. Drew DeVaults SourceHut keeps its "a forge that works without JavaScript" identity and has a small dedicated audience. Harness-acquired Gitness (formerly Drone Code) is a newer challenger with CI baked into the core. Static viewers like Cgit and Stagit fill the "this is not a forge, just a website that shows code" niche. ForgeFed is attempting to federate forges over ActivityPub. ArgoCD and Flux are quietly redefining what a forge means once GitOps turns it into the source of truth for system state.

This article maps that whole landscape. It compares twelve tools along the same axes, looks at how Korean and Japanese companies use them, and ends with concrete picks for four kinds of users — individual, team, enterprise, and minimalist. Prices and licenses are as of May 2026 and change often; verify on the official site before deciding.

> "Git is distributed, but the forge is always somebodys server. The only question is whose." — anonymous Codeberg operator, 2023

1. The 2026 self-hosted Git map — three camps

If you draw the 2026 self-hosted Git forge landscape on one screen, it splits into three camps.

**Camp one — the Gitea family (Gitea + Forgejo)**

The most popular self-hosted choice. A single Go binary, a MySQL/PostgreSQL/SQLite backend, and a UX that looks a lot like GitHub. Gitea started in 2014 as a fork of Gogs. After a 2022 governance dispute around the formation of an operating company, the community side forked again into Forgejo. The two projects keep API compatibility but differ in governance. Codeberg is by far the largest Forgejo deployment.

**Camp two — GitLab (CE / EE)**

The flagship of the open-core model. CE (Community Edition, MIT-style license) is free and open source; EE (Enterprise Edition) is the same codebase with paid features layered on top. The single-command Omnibus package is a major selling point. CI/CD sits in the core, and enterprise capabilities such as security scanning and compliance frameworks live in EE. The price you pay is weight.

**Camp three — minimalists (SourceHut / Cgit / Stagit / Gitness)**

Tools that run with no JavaScript or almost none, keeping "only what a forge needs to be a forge". Drew DeVaults SourceHut hosts at git.sr.ht with the code under AGPL; its workflow is mailing-list patches in the kernel style. Cgit is the static-ish viewer that runs git.kernel.org. Stagit goes one step further — a git push hook regenerates plain HTML files, producing a truly static site. Gitness (Harness, formerly Drone Code) is a newer challenger that puts CI in the core.

The axes that split these camps are clear — **how GitHub-like the UI is, how heavy the runtime is, and what license it ships under**. Gitea and Forgejo are GitHub-like and lightweight. GitLab is GitHub-like but heavy. The minimalists are deliberately un-GitHub-like and lightweight. Picking your camp is the first question.

2. Gitea — most popular, governance controversy of 2022

Gitea started in 2014 as a fork of Gogs by Lunny Xiao. A single Go binary with SQLite, MySQL, or PostgreSQL behind it; about 100 MB of memory in a small deployment. Its lightweight footprint made it the de facto standard for "the Git server you run on a Raspberry Pi" by around 2020.

**Architecture and install**

A single Go binary plus a database plus a data directory. The simplest form is SQLite plus one container. One-line Docker install:

docker run -d --name gitea \

-p 3000:3000 -p 222:22 \

-v /opt/gitea:/data \

gitea/gitea:latest

For small groups (under 10 users) SQLite is fine. Once you cross 100 users, PostgreSQL plus a separate Redis cache is the recommended setup. Backups are simple — capture the data directory and the database.

**Feature depth**

- Issues / PRs / code review / wiki / project boards

- Gitea Actions (GitHub Actions compatible at the syntax level)

- Packages (containers, npm, Maven, Composer, PyPI, more)

- LFS, OAuth login, LDAP/SAML

- API is nearly 1:1 compatible with the GitHub API

**What happened in 2022**

In October 2022 the long-time community-run Gitea announced the formation of a for-profit entity, Gitea Ltd., and the transfer of trademarks and domains. Some maintainers and community members objected, citing a lack of procedural transparency and no advance consultation with contributors. By December a group centered on Codeberg forked the project as Forgejo.

Gitea Ltd. has since normalized operations, and as of 2026 Gitea remains the most popular self-hosted option. It also runs Gitea Cloud (SaaS) and sells enterprise support contracts. The license is still MIT.

**Weaknesses**

- Some users are uncomfortable with the for-profit governance model

- Past about 1000 users the permission and audit tooling looks thin compared to GitLab

- Gitea Actions is not 100 percent GitHub Actions compatible (OIDC tokens in particular)

3. Forgejo — the Codeberg-led community fork (2022)

Forgejo started in December 2022 as a fork of Gitea. The name is Esperanto for "forge". Codeberg is the primary deployment, and the non-profit Codeberg e.V. handles governance.

**How it differs from Gitea**

- Same starting codebase, slowly diverging

- API compatibility is preserved — Gitea clients such as Tea CLI mostly just work

- Governance: no for-profit company, association-based instead

- License: GPLv3-plus, changed from Gitea's MIT. The change is deliberate, meant to prevent the code from being taken closed-source again

- A few features landed in Forgejo first — federation experiments and a quota system, for instance

**Governance model**

- A maintainer council plus an association board

- All decisions happen in public on Matrix and mailing lists

- "No single person or company can control the project" is an explicit design goal

**Relationship with Codeberg**

Codeberg is a free public Git host run by a German non-profit association. It launched in 2019 on plain Gitea, then migrated to Forgejo after the fork. By 2026 it hosts more than a hundred thousand users free of charge. It is funded by donations. Some open-source projects (mirrors of OBS Studio, KeePassXC, and others) use it as an official or unofficial mirror.

**Install is nearly identical to Gitea**

docker run -d --name forgejo \

-p 3000:3000 -p 222:22 \

-v /opt/forgejo:/data \

codeberg.org/forgejo/forgejo:latest

The config file format, database schema, and backup procedure are compatible with Gitea, which is why a Gitea-to-Forgejo migration is essentially "swap the image".

**When to pick Forgejo**

When your organizational policy requires governance by a community or non-profit instead of a for-profit company, or when GPL compatibility matters. The feature set is nearly identical to Gitea, so the choice is really one of philosophy.

4. GitLab CE / EE — the open-core giant

GitLab started in 2011 as an open-source forge by Dmitriy Zaporozhets. GitLab Inc. was later founded and adopted the open-core model. CE (Community Edition) is under an MIT-style license, and EE (Enterprise Edition) is the same codebase with paid features layered on top.

**Architecture**

It is large. Ruby on Rails plus several Go components (Gitaly for Git storage, Workhorse for HTTP proxying) plus PostgreSQL plus Redis plus optional Sidekiq plus Elasticsearch plus a container registry and more. The Omnibus package bundles all of it into one Debian or RPM that installs with a single command.

sudo apt install gitlab-ce

sudo gitlab-ctl reconfigure

A Kubernetes Helm chart is also officially supported. For small environments running the entire chart is overkill — Omnibus is much lighter.

**Features**

In CE already:

- Issues / merge requests / code review / wiki

- CI/CD via GitLab Runner

- Container registry, package registry

- Basic SAML/LDAP

EE-only:

- CODEOWNERS enforced approvals

- Security scanning (SAST, DAST, container, dependency)

- Compliance frameworks

- Geographic replication (Geo)

- AI Duo, GitLabs coding assistant

**Pricing**

The SaaS GitLab.com has Free / Premium / Ultimate tiers. Self-hosted CE is free; EE is roughly nineteen to ninety-nine US dollars per user per month as of May 2026 (Premium / Ultimate). It looks expensive for a large org, but if you factor in that scanning and compliance tooling are bundled, some teams find it cheaper than separate licenses for Snyk, Sonar, and Checkmarx.

**An honest take on the weight**

Below four vCPU and 8 GB of RAM, GitLab CE is painful. With 100-plus users plan for 16 GB or more. Omnibus upgrades go fairly smoothly; Helm-chart upgrades take time to master. The common verdict is "GitLab CE is heavy but stable".

**Korean adoption**

Large Korean SI and enterprise shops — LG CNS, Samsung SDS, KT — run GitLab CE/EE in many sites. In the financial sector a common pattern is GitLab inside an isolated network with one-way mirroring from external GitHub.

5. OneDev — modern, Java-based

OneDev is a Java-based Git forge built since 2018 by a single developer, Robin Shen. It runs as a single JAR or Docker image with embedded H2 or PostgreSQL / MySQL behind it. License: MIT.

**Why look at OneDev**

- A single binary / Docker image with one config surface

- CI/CD in the core — no separate runner install; pipelines defined in OneDevs "build spec" DSL

- Deep issue tracker — custom fields, milestones, boards, time tracking

- Fast code search via Lucene; no semantic search but solid regex and symbol search

- Lots of small touches: concurrent builds per PR, auto-link of issues, and similar

**Comparison**

Compared to Gitea, the CI depth is a notch deeper. Compared to GitLab CE, it is much lighter. OneDev sits somewhere between Gitea and GitLab.

**Weaknesses**

- Single-maintainer risk — Robin Shen writes almost all of it

- A small community, so Stack Overflow has few answers

- The UI is just different enough from Gitea and GitLab that new users need adjustment time

- A Java dependency (JDK 17 or higher)

**Who should pick it**

Small to mid-size teams (5–30 people) for whom GitLab CE feels too heavy and Gitea's CI feels too thin. Shops that already operate Java in production (banking, insurance) tend to find it familiar.

6. RhodeCode — financial trouble in 2024

RhodeCode is a Python-based forge that supports Git, Mercurial, and Subversion in one UI, going back to around 2010. It had Community Edition and Enterprise Edition variants. In the mid-2010s it occupied a real niche as an alternative to Atlassian Stash (later Bitbucket Server).

**What happened in 2024**

Mid-2024 RhodeCode Inc. essentially scaled back operations due to financial trouble. The official site is still online but updates have nearly stopped, and the GitHub repo is largely frozen. Some maintainers tried to fork (Kallithea is an older fork that is also low-activity). As of 2026 it is hard to recommend to new users.

**Remaining users**

Shops that still carry legacy Mercurial repositories run RhodeCode. Mozilla and parts of Facebook had Mercurial monorepos historically, and some of those traces remain. New installs, though, are not recommended.

**Alternatives**

If you need Mercurial support, look at SCM-Manager (Cloudogu, Java-based) or Heptapod (a GitLab CE fork with Mercurial support re-added, maintained by octobus.net).

Treat this section as historical context — in 2026 there is essentially no reason to choose RhodeCode for a new deployment.

7. Bitbucket Data Center — Atlassian's last self-hosted option

Atlassian acquired the Australian startup Bitbucket in 2010 and tied it to its Jira and Confluence ecosystem. The self-hosted edition was called Bitbucket Server (originally Stash).

**February 2024 — Bitbucket Server EOL**

In February 2024 Atlassian put all Bitbucket Server versions into end-of-life. After that, the only self-hosted option was Bitbucket Data Center — a much more expensive license with active-active clustering and large-organization features. Small teams that had been running single-node Bitbucket Server were nudged onto GitHub Enterprise or other tools.

**What Bitbucket Data Center offers**

- Active-active clustering, geographic distribution

- Deep integration with Jira and Confluence

- Per-user licensing that is expensive — designed around organizations starting at hundreds of seats

- Operationally complex, with DBA and JVM tuning skills required

**Why small teams had to move**

As Atlassian shifted strategy toward the cloud (bitbucket.org SaaS), it effectively abandoned the single-node self-hosted market. Most departing Bitbucket Server users moved to GitHub Enterprise, then to GitLab CE/EE, and some to Gitea or Forgejo.

**In Korea**

Plenty of large-enterprise SI shops in Korea were running Bitbucket Server. After the 2024 EOL, the patterns split — some migrated to GitLab CE/EE or GitHub Enterprise, others swallowed the cost and stayed on Bitbucket Data Center. Financial firms tend to be in the latter group because their Atlassian (Jira, Confluence) lock-in is strong.

8. SourceHut — Drew DeVaults minimalist forge

SourceHut launched in 2019. The domain is sr.ht ("sir-hat"). The code is AGPL, hosted service starts at about two US dollars per month, and self-hosting is free.

**Philosophy**

- Works without a single line of JavaScript — read interfaces really do render with HTML and CSS only

- Mailing-list-based patch workflow — patches built with git format-patch, mailed in, applied with git am

- Components are separated by purpose: git.sr.ht (repos), lists.sr.ht (mailing lists), todo.sr.ht (issues), builds.sr.ht (CI), pages.sr.ht (static sites), man.sr.ht (man pages / wiki)

- No tracking pixels, no analytics

**Who uses it**

Sway window manager (by Drew himself), wlroots, postmarketOS, and other Wayland and Linux desktop ecosystem projects use sr.ht regularly. It plays well with kernel-style developers comfortable with email patch workflows.

**Builds.sr.ht — the CI piece**

Image definitions are simple YAML, and FreeBSD, NetBSD, and OpenBSD builds are first-class. Whereas GitHub Actions is Linux-centric, builds.sr.ht is BSD-friendly.

**Weaknesses**

- The UI is intentionally conservative, so GitHub users get lost at first

- Mail patches in place of PRs are a real onboarding wall

- Self-host install is more involved than other tools — each component is its own daemon

**A note on Drew DeVault**

Drew is famously opinionated and blogs often. Some of his writing is controversial enough to spill onto SourceHuts reputation. The code and operations themselves, though, remain consistent.

9. Gitness — the Harness (formerly Drone Code) challenger

Gitness was announced by Harness Inc. in 2023. It was originally called Drone Code, then renamed Gitness for marketing consistency. Tight integration with Drone CI (Harnesss CI product) is the differentiator.

**Highlights**

- A single Go binary

- One-line Docker install (Gitea-style)

- A pipeline engine in the core — Drone CI YAML syntax as-is

- Reasonably fast code search

- License: Apache 2.0

docker run -d -p 3000:3000 \

-v /var/run/docker.sock:/var/run/docker.sock \

-v /opt/gitness:/data \

harness/gitness

**Relationship with the Harness product**

Harness sells a DevOps platform — CI/CD, feature flags, more — as a SaaS. Gitness is the entry point, designed to let Harness customers have Git hosting in the same screen. Harnesss paid cloud plan integrates Gitness, and self-hosted Gitness is free and open source.

**Weaknesses**

- A young 2023 product with few validated production stories

- Small community

- Vulnerable to the parent companys strategy shifts (the Drone Code rename is one such signal)

- Feature set is thinner than Gitea or Forgejo

**Who should look at it**

Teams where CI-first workflows dominate, Drone YAML is familiar, and Git hosting is wanted as a lightweight side effect.

10. Tea CLI — for Gitea and Forgejo

Tea is the official command-line client for Gitea and Forgejo. A single Go binary. Same niche as GitHubs gh CLI.

**Install**

brew install tea # macOS

go install code.gitea.io/tea@latest

**Basic usage**

tea login add --name myserver \

--url https://git.example.com \

--token YOUR_TOKEN_HERE

tea repos list

tea issues list

tea pulls create --title "Fix bug" --description "..."

tea pulls checkout 42

**Why it is good**

- The mental model matches gh CLI almost exactly

- Compatible with both Gitea and Forgejo — same API, same behavior

- Shell completion for zsh, bash, and fish

- Auto-detects the right server from the local git remote

**Weaknesses**

- Less depth than gh CLI (no equivalent of ghs rich alias system)

- It does not target the GitHub API surface 100 percent, so some commands differ

- Small community, so fewer answers when you get stuck

**Who should use it**

Anyone using Gitea or Forgejo daily, almost without exception. One of the biggest historical pains of self-hosted Git was "no CLI as smooth as gh"; Tea fills that gap.

11. Cgit / Stagit — static viewers

Two read-only Git viewers. Both play the role of "not a forge, just a website that shows code".

**Cgit**

A C-based CGI program. Light and fast. git.kernel.org runs on Cgit. The typical stack is nginx plus fcgiwrap plus cgit.

location /cgit/ {

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;

fastcgi_pass unix:/var/run/fcgiwrap.socket;

}

Properties:

- Commit, branch, diff, and blame in one screen

- Search is plain grep

- Atom feeds supported

- No authentication, no issues, no PRs — read-only for real

**Stagit**

Stagit (by Hiltjo Posthuma from the suckless camp) goes more extreme. There is no dynamic CGI — a git push hook regenerates the HTML. The result is a fully static site.

stagit -c .cache repo.git

generates repo.git/index.html, log.html, files.html ...

Properties:

- Actually static HTML, deployable to S3, CDN, or any static host

- One CSS file, zero lines of JavaScript

- No search built in (use grep externally)

- suckless.org self-hosts its own code with it

**Who uses these**

Solo developers who want a site to show their dotfiles and small libraries, plus kernel-style projects that take patches over mailing lists. The collaboration tools (issues, PRs) live elsewhere; the code presentation is just static.

12. ForgeFed — federated git

ForgeFed is a draft standard for federating Git forges on top of ActivityPub. It started around 2019, and Forgejo plus a few other forges have experimental implementations.

**What it tries to do**

- An issue on gitea.example.com is delivered as an ActivityPub message to a user on forgejo.other.org

- A user on instance A follows, stars, or forks a repository on instance B

- A PR on instance A crosses into a repository on instance B

- Just as Mastodon federates posts, ForgeFed federates code collaboration

**Where it stands (May 2026)**

- The ForgeFed draft lives in the W3C Social Web Community Group

- Forgejo is the most active implementer; some instances have it enabled experimentally

- Gitea has signaled interest but lower priority

- SourceHut prefers its own mail-based federation style

**A realistic view**

There still are not many cases where ForgeFed actually works end-to-end. Hard problems remain — message formats, permissions, conflict resolution. But the recognition that "Git collaboration trapped inside one company is fragile" keeps growing, and federation is the only real alternative. A common view is that 2027 to 2028 will bring meaningful progress.

13. ArgoCD / Flux — GitOps redefines what a forge is

GitOps is the pattern in which declarative infrastructure state lives in Git and a controller reconciles a cluster toward that state. ArgoCD (originally Intuit, now a CNCF graduated project) and Flux (Weaveworks-originated, also CNCF graduated) are the two main tools.

**Why include this here**

GitOps changes the meaning of a forge. The forge is no longer just a code host — it becomes the **source of truth for system state**. ArgoCD and Flux are forge-agnostic (GitHub, GitLab, Gitea, Forgejo, Bitbucket all work), but two things matter more when self-hosting.

**Concern 1 — availability**

If your forge goes down, ArgoCD cannot sync. So either run the forge highly available, or have a fast recovery procedure. GitLab CE has Geo (EE-only feature), Gitea has straightforward SQL backups, Forgejo supports active-passive setups, and so on.

**Concern 2 — webhooks vs polling**

ArgoCD detects changes through webhooks (instant) or polling (default three minutes). When self-hosting, verify that the forge can actually reach the cluster over webhooks. In network-isolated environments polling may be the only option.

**ArgoCD install example**

kubectl create namespace argocd

kubectl apply -n argocd \

-f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

**Flux install example**

flux bootstrap gitea \

--hostname=git.example.com \

--owner=platform \

--repository=flux-clusters \

--branch=main \

--path=clusters/prod

Flux bootstrap creates a Git repository and pushes its own manifests there. Gitea, GitLab, GitHub, and Bitbucket are first-class; Forgejo and Gitness use the Gitea compatibility mode as of May 2026.

14. Mirror tooling — git-mirror, gitea-mirror

A common self-hosted forge use case: "mirror the official GitHub repos into our internal Git server". A few tools that help.

**Built-in mirror in Gitea / Forgejo**

Check the "Mirror this repository" option at repo creation and the forge will periodically pull from an upstream Git. Simplest path.

**git-mirror (Python)**

git-mirror --source https://github.com/foo/bar \

--target ssh://git@internal.example.com/mirrors/bar.git \

--interval 3600

**Org-level mirrors — gitea-mirror, forgejo-mirror**

Automatically mirror every repository in a GitHub organization. New repositories get auto-registered.

source:

type: github

org: kubernetes

target:

type: gitea

url: https://git.example.com

org: github-mirror-kubernetes

schedule: "0 */6 * * *"

**Why run mirrors**

- Pull external code into an air-gapped network

- Hedge against GitHub outages

- Comply with policies that require keeping dependency code in-house

- Mirror LFS objects too, so even large repositories can be built internally

15. Korea and Japan — Toss, Kakao, Mercari, Pixiv

**Korea — Toss and Kakao**

Toss (Viva Republica) has publicly mentioned that it runs internal Git infrastructure. The exact implementation is private, but it follows the common Korean fintech pattern of a self-hosted GitLab or GitHub Enterprise. The Toss tech blog covers internal developer-environment topics.

Kakao reportedly runs GitHub Enterprise for some teams and GitLab for others. There is a culture of team autonomy rather than group-wide standardization. The Kakao tech blog (tech.kakao.com) carries regular DevOps and platform posts.

NAVER also runs internal Git hosting. NAVER D2 (d2.naver.com) occasionally publishes infrastructure-related posts. NAVER tends to build many of its internal tools or aggressively patch open source to fit its environment.

**Japan — Mercari and Pixiv**

Mercari runs GitHub Enterprise as its primary host, as repeated mentions on its engineering blog confirm. Mercari Engineering (engineering.mercari.com) is one of the most English-content-rich engineering blogs in Japanese IT.

Pixiv, the illustration community company, has mentioned running GitLab CE for internal Git. inside.pixiv.blog publishes development-culture posts regularly.

LINE (now LY Corporation) runs GitHub Enterprise as its primary host with some in-house tooling. engineering.linecorp.com covers DevOps and platform topics.

**The common pattern**

Korean and Japanese large enterprises typically pick one of three:

1. GitHub Enterprise (and Enterprise Server self-hosted in air-gapped settings)

2. Self-hosted GitLab CE/EE

3. Bitbucket Server (now migrating to GitHub or GitLab after the 2024 EOL)

Gitea and Forgejo do not yet have widely reported large-enterprise deployments in Korea and Japan. But for startups and small or mid-size shops they are spreading. Plenty of student-club Gitea instances run on a Raspberry Pi.

16. Comparison table — twelve tools at a glance

One-liner per tool:

- Gitea: most popular self-hosted, MIT, lightweight

- Forgejo: community fork of Gitea, GPLv3-plus, governance-first

- GitLab CE: open core, heavy but feature-rich

- GitLab EE: CE plus enterprise features, expensive but security and compliance included

- OneDev: Java-based, strong CI, single maintainer

- RhodeCode: effectively folded in 2024, not recommended for new use

- Bitbucket Data Center: Atlassian, expensive, Jira/Confluence lock-in

- SourceHut: no JS, email-based, minimalist

- Gitness: Harness-born, CI in the core, young

- Cgit: dynamic-ish static viewer, runs git.kernel.org

- Stagit: truly static, suckless.org uses it

- Tea CLI: Gitea/Forgejo-friendly CLI, the gh-equivalent

**Axis comparison**

License freedom, most to least: SourceHut / Forgejo (GPL) > Gitea / Gitness (MIT / Apache) > OneDev (MIT) > GitLab CE (MIT-style) > GitLab EE / Bitbucket DC (commercial)

Operational weight, lightest to heaviest: Cgit / Stagit > Gitea / Forgejo / Gitness > SourceHut > OneDev > GitLab CE > GitLab EE / Bitbucket DC

GitHub UX familiarity, most to least: Gitea / Forgejo / Gitness > OneDev > GitLab > Bitbucket > SourceHut > Cgit / Stagit

17. Who should pick what — four types

**Type 1 — individual, hobby, small club**

Answer: Gitea or Forgejo. SQLite backend, one-line Docker install, runs comfortably in 100 MB of RAM. Feature-wise they are nearly identical, so pick Forgejo if governance philosophy matters and Gitea if "biggest community" matters more. Install Tea CLI alongside. A Raspberry Pi 4 is plenty.

**Type 2 — a 5–50 person team where CI is central**

Answer: OneDev or GitLab CE. OneDev is light and CI-first. GitLab CE is heavy but proven, with a huge community. If the team is twenty-plus people and you can spare an 8 GB-plus instance, GitLab CE is the safer bet. Smaller than that, OneDev. Gitea with a separate Drone CI is also a sensible combo.

**Type 3 — enterprise (air-gapped, compliance)**

Answer: GitLab EE or GitHub Enterprise Server or Bitbucket Data Center. If you need security scanning, audit logs, SAML/SCIM, enforced CODEOWNERS, and geographic replication, these three are it. Pricing is in the same neighborhood. With strong Jira/Confluence lock-in, Bitbucket DC; otherwise GitHub Enterprise or GitLab EE. Korean finance leans GitLab EE.

**Type 4 — minimalist / mail patches / static site**

Answer: SourceHut or Cgit / Stagit. SourceHut if you like mail-patch workflows and JavaScript-free UI. If collaboration tools live elsewhere and you just want code on display, Cgit (dynamic CGI) or Stagit (truly static). Both pair well with dotfiles and small libraries.

**Type 5 (bonus) — GitOps-first**

Answer: any of the above plus ArgoCD or Flux. The GitOps pattern matters more than the forge choice. ArgoCD and Flux are forge-agnostic, but you have to handle the availability of your self-hosted forge. Flux supports Gitea and Forgejo well, making GitOps bootstrap easy in small environments.

Epilogue — in GitHubs shadow, but still standing

GitHub will remain the de facto standard in 2026. Self-hosted Git is not going to replace it. But it is not going away either. Air-gapping, data sovereignty, compliance, and a desire not to depend on one company — all of these create steady demand.

In spring 2026 the most solid feet on that ground belong to Gitea and Forgejo. The very fact that the two diverged is evidence of the appetite for a forge that no single company controls. GitLab CE/EE has cemented itself as the open-core giant. OneDev and Gitness give small teams fresh options. SourceHut, Cgit, and Stagit keep the alternative path open — a forge does not have to look like GitHub. ForgeFed is still an experiment, but it keeps the door to real federation open. ArgoCD and Flux quietly stretch the meaning of a forge from "code archive" to "source of truth for system state".

Choosing where your code lives looks like a small decision, but it ends up answering a big question: who decides the fate of your code. For those who want to keep that answer to themselves, the 2026 self-hosted Git ecosystem offers more, and sturdier, options than ever.

References

- Gitea — https://about.gitea.com/

- Gitea on GitHub — https://github.com/go-gitea/gitea

- Forgejo — https://forgejo.org/

- Forgejo on Codeberg — https://codeberg.org/forgejo/forgejo

- Codeberg — https://codeberg.org/

- Codeberg e.V. (non-profit association) — https://codeberg.org/Codeberg/org

- GitLab CE vs EE — https://about.gitlab.com/install/ce-or-ee/

- GitLab mirror on GitHub — https://github.com/gitlabhq/gitlabhq

- GitLab Helm Chart — https://docs.gitlab.com/charts/

- OneDev — https://onedev.io/

- OneDev on GitHub — https://github.com/theonedev/onedev

- RhodeCode — https://rhodecode.com/

- Kallithea (early RhodeCode fork) — https://kallithea-scm.org/

- Heptapod (Mercurial-friendly GitLab fork) — https://heptapod.net/

- SCM-Manager — https://scm-manager.org/

- Bitbucket Data Center — https://www.atlassian.com/software/bitbucket/enterprise

- Bitbucket Server EOL FAQ — https://www.atlassian.com/migration/assess/server-eol-faq

- SourceHut — https://sourcehut.org/

- SourceHut sr.ht instance — https://sr.ht/

- Drew DeVaults blog — https://drewdevault.com/

- Gitness — https://gitness.com/

- Gitness on GitHub — https://github.com/harness/gitness

- Tea CLI — https://gitea.com/gitea/tea

- gh CLI (comparison) — https://cli.github.com/

- Cgit — https://git.zx2c4.com/cgit/

- git.kernel.org (Cgit deployment) — https://git.kernel.org/

- Stagit — https://codemadness.org/stagit.html

- suckless.org (Stagit deployment) — https://git.suckless.org/

- ForgeFed standard — https://forgefed.org/

- ForgeFed repository — https://codeberg.org/ForgeFed/ForgeFed

- ActivityPub (W3C Recommendation) — https://www.w3.org/TR/activitypub/

- ArgoCD — https://argo-cd.readthedocs.io/

- ArgoCD on GitHub — https://github.com/argoproj/argo-cd

- Flux — https://fluxcd.io/

- Flux on GitHub — https://github.com/fluxcd/flux2

- Kakao tech blog — https://tech.kakao.com/

- Toss tech blog — https://toss.tech/

- NAVER D2 — https://d2.naver.com/

- Mercari Engineering — https://engineering.mercari.com/

- Pixiv inside blog — https://inside.pixiv.blog/

- LINE Engineering — https://engineering.linecorp.com/