Skip to content
Published on

セルフホスト Git プラットフォーム 2026 — Gitea / Forgejo / GitLab CE/EE / OneDev / SourceHut / Gitness 徹底比較

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — Git は分散だが、フォージは中央集権だ

Git そのものは 1 対 1 で push / pull する分散型バージョン管理システムだ。だが私たちが「GitHub」「GitLab」と呼ぶもの — issue、PR、コードレビュー、CI、権限管理、wiki、ディスカッション — は Git ではない。それはフォージ(forge)だ。そしてフォージの歴史は分散ではなく中央集権の歴史である。

2008 年に GitHub が登場して以降、ほぼすべてのオープンソースが GitHub に集まり、2018 年の Microsoft 買収でその流れが固まった。2026 年の時点で GitHub は事実上の標準だ。しかしそれと同時に「社内に置きたい」「韓国 / 日本のデータ保護規制を守りたい」「GitHub に依存しない自前のバックエンドが必要だ」という要求も依然として存在する。セルフホスト Git フォージはその隙間で成長してきた。

2026 年春、その光景は以下の三つの陣営に分かれる。一方には最大手の Gitea がある。しかし Gitea は 2022 年のガバナンス論争を経て Codeberg 主導のコミュニティフォーク Forgejo に分かれた。もう一方にはオープンコアの巨人 GitLab がある。CE は無料 / オープンソース、EE は有料 / ソース公開。そして Java ベースの OneDev がシングルバイナリで静かにファンを増やしている。一時期強かった RhodeCode は 2024 年の財政難で事実上消え、Atlassian は 2024 年 2 月に Bitbucket Server を EOL として Data Center のみを残した。

ミニマリスト陣営も健在だ。Drew DeVault の SourceHut は「JavaScript なしで動くフォージ」という自己宣言を守り、小さな熱心なファンを抱える。Harness が買収した Gitness(旧 Drone Code)は CI をコアに据えた新参者だ。Cgit / Stagit は「フォージではなく、コードを見るだけのサイト」の役割を果たす。その上に ForgeFed が ActivityPub の上でフォージをフェデレーションしようとし、ArgoCD / Flux は GitOps によってフォージの意味を再定義する。

本稿ではその光景をまとめて整理する。同じ軸で 12 のツールを比較し、韓国 / 日本の事例も短く見て、最後に「あなたは何を選ぶべきか」を個人 / チーム / エンタープライズ / ミニマリストの 4 タイプで答える。価格とライセンスは 2026 年 5 月時点のもので、よく変わるので決める前に公式サイトを確認してほしい。

「Git は分散だが、フォージは常に誰かのサーバーだ。問題はその誰かが誰かということだ。」 — 匿名の Codeberg 運営者、2023

1. 2026 年セルフホスト Git マップ — 三つの陣営

2026 年のセルフホスト Git フォージを 1 画面に描けば、三つの陣営に分かれる。

第一陣営 — Gitea ファミリー (Gitea + Forgejo)

最も人気のあるセルフホスト選択肢。Go で書かれたシングルバイナリ、MySQL / PostgreSQL / SQLite バックエンド、GitHub に似た UX。Gitea は 2014 年に Gogs のフォークとして始まり、2022 年の運営会社設立をめぐるガバナンス論争の後、コミュニティ側が Forgejo として再びフォークした。両プロジェクトは API 互換性を保つがガバナンスモデルが異なる。Codeberg は Forgejo の最大の利用先だ。

第二陣営 — GitLab (CE / EE)

オープンコアモデルの代表。CE(Community Edition、MIT に近いライセンス)は無料 / オープンソース、EE(Enterprise Edition)は同じコードベースに有料機能を追加した商用版。1 コマンドで入る Omnibus パッケージが大きな強み。CI/CD がコアに組み込まれ、セキュリティ / コンプライアンス / SAST / DAST などのエンタープライズ機能が EE に入っている。重さが弱点。

第三陣営 — ミニマリスト (SourceHut / Cgit / Stagit / Gitness)

JavaScript なしまたはほぼなしで動く、「フォージの本質だけを残した」ツールたち。Drew DeVault の SourceHut は git.sr.ht がホスティング版で、コードは AGPL。メーリングリストベースのパッチワークフローが特徴。Cgit は kernel.org などが使う静的的 git ビューア。Stagit はさらに一歩進んで、git push フックが HTML を再生成する本当の静的サイト。Gitness(Harness、旧 Drone Code)は CI をコアに据えた新参者だ。

この三つの陣営を分ける軸は明快だ — どれだけ GitHub に似ているか、どれだけ重いか、ライセンスは何か。Gitea / Forgejo は GitHub 風で軽い。GitLab は GitHub 風で重い。ミニマリストはあえて GitHub と違うように見せながら軽い。この三つのどの陣営があなたに合うかが最初の問いだ。

2. Gitea — 最人気、2022 年のガバナンス論争

Gitea は 2014 年に Gogs(Lunny Xiao 作)のフォークとして始まった。Go で書かれたシングルバイナリ、SQLite / MySQL / PostgreSQL バックエンド、約 100MB のメモリで動く軽さが最初からの強みだった。2020 年頃から Raspberry Pi にも入れる「ホビー Git サーバー」の事実上の標準になった。

アーキテクチャとインストール

シングル Go バイナリ + データベース + データディレクトリ。最も簡単な形は SQLite + 単一コンテナ。Docker 1 行で入る。

docker run -d --name gitea \
  -p 3000:3000 -p 222:22 \
  -v /opt/gitea:/data \
  gitea/gitea:latest

小規模(10 名以下)なら SQLite で十分回る。100 名以上なら PostgreSQL + 別の Redis キャッシュが推奨。バックアップはデータディレクトリと DB だけ取れば良い。

機能の深さ

  • Issue / PR / コードレビュー / Wiki / プロジェクトボード
  • Actions(GitHub Actions 互換、Gitea Actions と呼ぶ)
  • Packages(コンテナ / npm / Maven / Composer / PyPI など)
  • LFS、OAuth ログイン、LDAP / SAML
  • API は GitHub API とほぼ 1 対 1 互換

2022 年に何が起きたか

長年コミュニティ運営だった Gitea が 2022 年 10 月に「Gitea Ltd.」という営利法人を作り商標とドメインを移管したと発表すると、一部のメンテナーとコミュニティが反発した。手続きの透明性不足、貢献者との事前協議の欠如が主な批判点だった。結果として Codeberg を中心としたグループが同年 12 月に Forgejo としてフォークした。

その後 Gitea Ltd. は運営を正常化させ、2026 年時点でも Gitea は依然として最も人気のあるセルフホスト選択肢だ。Gitea Cloud(SaaS)も運営中で、企業向けサポートパッケージも販売している。ライセンスは依然として MIT。

弱点

  • ガバナンスモデルが非営利コミュニティではないことを不快に感じる人がいる
  • ユーザーが 1000 人以上になると GitLab ほど精巧な権限 / 監査ツールが不足する
  • Actions が GitHub Actions と 100 パーセント互換ではない(特に OIDC トークン)

3. Forgejo — Codeberg 主導のコミュニティフォーク (2022)

Forgejo は 2022 年 12 月に Gitea フォークとして始まった。「Forgejo」はエスペラント語で「フォージ」を意味する。Codeberg が主な運営先で、非営利協会 Codeberg e.V. がガバナンスを担当する。

Gitea との違い

  • 同じコードベースから出発したが徐々に分かれている
  • API 互換性は保持 — Gitea クライアント(例: Tea CLI)はほぼ動く
  • ガバナンス: 営利法人なし、協会ベース
  • ライセンス: GPLv3 以上に変更(原本の Gitea は MIT)。これはフォークのコードを再びクローズドソースに戻せなくする意図的な選択
  • 一部の機能は Forgejo が先に取り入れた — 例: Federation 実験、クォータシステム

ガバナンスモデル

  • メンテナー評議会 + 協会理事会
  • すべての決定が公開の Matrix チャットとメーリングリストで進行
  • 「一人 / 一企業が支配できない構造」が明示的な設計目標

Codeberg との関係

Codeberg はドイツの非営利協会が運営する無料の公開 git ホスティング。2019 年の出発時点では Gitea をそのまま使い、フォーク以降 Forgejo に移った。2026 年現在約 10 万人以上のユーザーが無料でコードをホスティングする。寄付で運営され、一部のオープンソースプロジェクト(例えば Codeberg にミラーされた OBS Studio、KeePassXC など)が公式または非公式のミラーとして使う。

インストールは Gitea とほぼ同一

docker run -d --name forgejo \
  -p 3000:3000 -p 222:22 \
  -v /opt/forgejo:/data \
  codeberg.org/forgejo/forgejo:latest

設定ファイル形式、データベーススキーマ、バックアップ手順が Gitea と互換性がある。Gitea から Forgejo へのマイグレーションが事実上「イメージ差し替え」で終わるのはそのためだ。

いつ Forgejo を選ぶべきか

ガバナンスが営利法人ではなく協会 / コミュニティであるべきというポリシーがある所、または GPL 互換性が重要なプロジェクト。機能は Gitea とほぼ同じなので「哲学」が選択基準になる。

4. GitLab CE / EE — オープンコアの巨人

GitLab は 2011 年に Dmitriy Zaporozhets が始めたオープンソース git フォージ。その後 GitLab Inc. が設立されオープンコアモデルが定着した。CE(Community Edition)は MIT に近いライセンス、EE(Enterprise Edition)は同じコードベースに有料機能を追加した商用版。

アーキテクチャ

巨大だ。Ruby on Rails + Go コンポーネント(Gitaly: git ストレージ、Workhorse: HTTP プロキシ) + PostgreSQL + Redis + 選択的 Sidekiq + Elasticsearch + Container Registry + ... Omnibus パッケージはこれらすべてを 1 つの Debian / RPM パッケージにまとめて 1 コマンドで入れられるようにしている。

sudo apt install gitlab-ce
sudo gitlab-ctl reconfigure

Kubernetes チャートも公式サポート(GitLab Helm Chart)。ただし小規模環境で Kubernetes チャート全体を回すのは過剰 — Omnibus の方がはるかに軽い。

機能

CE に既に入っているもの:

  • Issue / Merge Request / コードレビュー / Wiki
  • CI/CD(GitLab Runner)
  • Container Registry、Package Registry
  • 基本的な SAML / LDAP

EE 限定:

  • コードオーナーシップ強制(CODEOWNERS の強制承認)
  • セキュリティスキャン(SAST / DAST / Container / Dependency)
  • コンプライアンスフレームワーク
  • マルチマスター / 地理的レプリケーション(Geo)
  • AI Duo(GitLab のコードアシスタント)

価格

GitLab.com SaaS は Free / Premium / Ultimate の三段階。セルフホストは CE は無料、EE はユーザーあたり月 19 ~ 99 米ドル(2026 年 5 月時点、Premium / Ultimate)。大組織には高く見えるが、セキュリティスキャンとコンプライアンスツールが全部入っていることを考えれば Snyk + Sonar + Checkmarx のような別ツールのライセンスより安いという評価もある。

重さに対する率直な評価

GitLab CE を 4 vCPU + 8GB RAM 未満に入れると苦労する。100 名以上なら 16GB 以上を推奨。Omnibus パッケージのアップグレードは比較的うまく回るが、Helm チャートのアップグレードは慣れるのに時間がかかる。「GitLab CE は重いが安定している」が一般的な評価だ。

韓国での位置

LG CNS、Samsung SDS、KT などの大企業 SI / Enterprise 環境に GitLab CE/EE のインストール事例が多い。金融業界では、ネットワーク分離環境に GitLab を入れて外部 GitHub と一方向同期するパターンが一般的だ。

5. OneDev — Java ベースのモダン

OneDev は一人の開発者(Robin Shen)が 2018 年から作っている Java ベースの git フォージ。シングル JAR または Docker イメージで動かし、組み込み H2 または PostgreSQL / MySQL を使う。ライセンスは MIT。

なぜ OneDev を見るのか

  • シングルバイナリ / Docker。設定が一箇所に集まる
  • CI/CD がコア。別途 Runner インストールなしで「build spec」という独自 DSL でパイプラインを定義
  • イシュートラッカーが深い — カスタムフィールド、マイルストーン、ボード、時間追跡
  • コード検索が速い — Lucene ベース、セマンティック検索はないが正規表現 / シンボル検索はよく効く
  • プルリクエストの同時ビルド / イシュー自動リンクなど細かな便利機能が多い

機能比較

Gitea と比較すると CI/CD の深さが一段上。GitLab CE と比較すると軽い。GitLab と Gitea の間のどこかに位置するツールだ。

弱点

  • 単一メンテナーリスク。Robin Shen がほぼすべてのコードを書く
  • コミュニティが小さい。Stack Overflow に答えが少ない
  • UI が Gitea / GitLab と微妙に違って、初めて使う人は適応時間が必要
  • Java 依存性(JDK 17 以上必要)

誰が選ぶべきか

小チーム(5 ~ 30 名)で GitLab CE は重すぎ、Gitea の CI は不足だと感じるなら OneDev が答えになり得る。Java 運用に慣れた環境(銀行、保険など)にも親和性が高い。

6. RhodeCode — 2024 年の財政難

RhodeCode は 2010 年頃からある Python ベースの git / mercurial フォージ。Community Edition(CE)と Enterprise Edition(EE)に分かれ、Mercurial と Subversion まで 1 画面で扱えるのが強みだった。2010 年代中盤には Atlassian Stash(Bitbucket Server)の代替として一定の地位を占めていた。

2024 年に何が起きたか

2024 年中盤、RhodeCode Inc. が財政難で事実上運営を縮小した。公式サイトは生きているが更新がほぼ止まり、GitHub リポジトリも事実上凍結された。一部のメンテナーがフォーク(Kallithea というより古いフォークもあったがこちらも活動が少ない)を試みたが、2026 年時点では新規ユーザーに勧めにくい。

残っているユーザー

レガシーな Mercurial リポジトリを抱えている所で依然として RhodeCode を回している。Mozilla、Facebook の一部モノレポが一時期 Mercurial だった歴史で RhodeCode を使ったことがあり、その痕跡が残っている。しかし新規インストールは推奨されない。

代替

Mercurial サポートが必要なら SCM-Manager(Cloudogu、Java ベース)や Heptapod(GitLab CE フォークに Mercurial サポートを再付与したプロジェクト)が候補。Heptapod は octobus.net がメンテナンスしている。

この節は「歴史的文脈」として置くのが正しい — 2026 年に新規ユーザーが RhodeCode を選ぶ理由はほとんどない。

7. Bitbucket Data Center — Atlassian 最後のセルフホスト

Atlassian は 2010 年にオーストラリアのスタートアップ Bitbucket を買収し、自社協業ツール(Jira、Confluence)と接続した。セルフホスト版は Bitbucket Server(元の名前は Stash)と呼ばれた。

2024 年 2 月 — Bitbucket Server 終了

Atlassian は 2024 年 2 月に Bitbucket Server の全バージョンを EOL(End of Life)にした。以降のセルフホスト選択肢は Bitbucket Data Center 一つだけ残った — こちらはアクティブ-アクティブクラスタリングと大規模組織向け機能を持つより高価なライセンスだ。単一ノード Bitbucket Server を使っていた小チームは GitHub Enterprise や他のツールへの移行を勧められた。

Bitbucket Data Center の特徴

  • アクティブ-アクティブクラスタ、地理的分散
  • Jira / Confluence との深い統合
  • ライセンスがユーザー単位で高い — 500 名以上から始まる価格帯(Atlassian がそう設計した)
  • 運用複雑度が高い。DBA + JVM チューニングの経験が必要

なぜ小チームは移行しなければならなかったか

Atlassian がクラウド(bitbucket.org SaaS)中心に戦略を移しながら、単一ノードセルフホスト市場を事実上放棄した。Bitbucket Server ユーザーが最も多く移った先は GitHub Enterprise、次に GitLab CE/EE、そして Gitea / Forgejo へ一部。

韓国では

大企業 SI 環境で Bitbucket Server を回していた所がかなりあった。2024 年 EOL 以降 GitLab CE/EE や GitHub Enterprise に移ったか、Bitbucket Data Center をそのまま維持してライセンス費用を負担するかの二つのパターンに分かれた。金融業界は後者が多い — Atlassian エコシステム(Jira、Confluence)のロックインが強いためだ。

8. SourceHut — Drew DeVault のミニマリスト

SourceHut は Drew DeVault が 2019 年に始めた git フォージ。sr.ht ドメイン(読み方は「sir-hat」)。コードは AGPL、ホスティング版は有料(月 2 米ドルから)、セルフホストは無料。

哲学

  • JavaScript なしで動作 — 本当に 1 行も使わない(読み取りインターフェース基準)。すべての UI が HTML + CSS だけで描かれる
  • メーリングリストベースのパッチワークフロー — git format-patch で作ったパッチをメールで送り、git am で適用
  • 別コンポーネントに分離: git.sr.ht(リポジトリ)、lists.sr.ht(メーリングリスト)、todo.sr.ht(イシュー)、builds.sr.ht(CI)、pages.sr.ht(静的サイト)、man.sr.ht(man ページ / wiki)
  • 追跡コード(トラッカー)なし、解析なし

誰が使うか

Sway ウィンドウマネージャ(Drew 本人作)、wlroots、postmarketOS などの Wayland / Linux デスクトップエコシステムが sr.ht をよく使う。メールワークフローに慣れたカーネルスタイルの開発者に親和的。

Builds.sr.ht — CI

イメージ定義がシンプルな YAML で、FreeBSD / NetBSD / OpenBSD ビルドもサポートするのが差別点。GitHub Actions が Linux 中心なのに対し、builds.sr.ht は BSD 親和的だ。

弱点

  • UI が意図的に保守的なので GitHub に慣れたユーザーは最初に道に迷う
  • PR の代わりにメールパッチという点が参入障壁
  • セルフホストインストールが他のツールより複雑(複数のコンポーネントがそれぞれ別デーモン)

Drew DeVault について余談

Drew は自分の意見が非常に強い開発者として知られ、ブログによく文を上げる。彼の文がときに論争的で SourceHut の評判にも影響を与える — しかしコードと運用の一貫性は変わらず維持されている。

9. Gitness — Harness(旧 Drone Code)の新参者

Gitness は Harness Inc. が 2023 年に発表した git フォージ。元々は Drone Code という名前だったがマーケティング統一のため Gitness に改名された。Drone CI(同じ会社の CI 製品)との統合が強み。

特徴

  • Go で書かれたシングルバイナリ
  • Docker 1 行で入る(Gitea のように)
  • コアにパイプライン(CI)が組み込まれている — Drone CI YAML 構文そのまま使用
  • コード検索が速い方
  • ライセンス Apache 2.0
docker run -d -p 3000:3000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /opt/gitness:/data \
  harness/gitness

Harness 本製品との関係

Harness は元々 CI/CD / Feature Flag などの DevOps プラットフォームを売る SaaS だ。Gitness はその入口の役割 — Harness ユーザーが Git ホスティングまで 1 画面でやれるようにするのが目的。Harness Cloud Plan(有料)には Gitness が統合されており、セルフホスト Gitness は無料 / オープンソース。

弱点

  • 2023 年に登場した新参者なので検証事例が少ない
  • コミュニティが小さい
  • 会社の戦略変更によって運命が変わるリスク(Drone Code から Gitness への改名もそのシグナルの一つ)
  • Gitea / Forgejo ほど機能が多くない

誰が見るべきか

CI 中心のワークフローが絶対的で、Drone YAML に慣れており、Git ホスティングを軽く一緒に回したいチーム。

10. Tea CLI — Gitea / Forgejo 親和

Tea は Gitea / Forgejo の公式 CLI クライアント。Go で書かれたシングルバイナリ。GitHub の gh CLI と同じ位置にある。

インストール

brew install tea          # macOS
go install code.gitea.io/tea@latest

基本使用

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

なぜ良いか

  • gh CLI に慣れたユーザーならほぼ同じメンタルモデル
  • Gitea と Forgejo の両方互換 — 同じ API なので動作が同じ
  • シェル(zsh / bash / fish)自動補完を提供
  • ローカル git remote から自動的にどの Gitea / Forgejo サーバーかを推論

弱点

  • 機能の深さは gh CLI より浅い(例えば gh のような豊富な alias システムがない)
  • GitHub API と 100 パーセント互換な表面を使うのではなく、一部のコマンドが異なる
  • コミュニティが小さく答えが少ない

誰が見るべきか

Gitea / Forgejo を毎日使う人ならほぼ無条件に。セルフホスト git の最大の不便の一つが「GitHub ほど滑らかな CLI がない」ことだったが、Tea がその席を埋める。

11. Cgit / Stagit — 静的ビューア

読み取り専用 git ビューアの 2 つのツール。両方とも「フォージではなく、ただコードを見るサイト」の役割を果たす。

Cgit

C で書かれた CGI プログラム。軽くて速い。git.kernel.org が Cgit で動いている。nginx + fcgiwrap + cgit が一般的な組み合わせ。

location /cgit/ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
    fastcgi_pass unix:/var/run/fcgiwrap.socket;
}

特徴:

  • 1 画面に commit / branch / diff / blame を表示
  • 検索は単純な grep
  • Atom フィードサポート
  • 認証 / イシュー / PR なし。本当に読み取り専用

Stagit

Stagit(suckless 陣営の Hiltjo Posthuma 作)はもっと極端だ。動的 CGI でさえない — git push フックが HTML を再生成する。その結果完全な静的サイトになる。

stagit -c .cache repo.git
# repo.git/index.html, log.html, files.html ... を生成

特徴:

  • 本当に静的 HTML、S3 / CDN / 静的ホスティングにそのまま上げる
  • CSS は 1 ファイル、JavaScript 0 行
  • 検索機能なし(grep は外部ツールで)
  • suckless.org が自分のコードホスティングとして使用

誰が使うか

「自分の dotfiles と小さなライブラリを見せるサイト」が必要な個人開発者、そしてメーリングリストベースでパッチを受けるカーネルスタイルプロジェクト。協業ツール(イシュー / PR)は他の所にあり、コード表示だけ静的にしたい時に答えになる。

12. ForgeFed — Federated Git

ForgeFed は git フォージを ActivityPub の上でフェデレーションしようとする標準ドラフト。2019 年頃に始まり、Forgejo と一部の他のフォージが実験的に実装中だ。

何をしようとしているか

  • gitea.example.com の issue が forgejo.other.org のユーザーに ActivityPub メッセージとして配信される
  • A インスタンスのユーザーが B インスタンスのリポジトリを follow / star / fork
  • A インスタンスの PR が B インスタンスのリポジトリへ横断して開く
  • Mastodon がツイートをフェデレーションするように、フォージがコード協業をフェデレーション

現状(2026 年 5 月)

  • ForgeFed 標準ドラフトは W3C Social Web Community Group で作業中
  • Forgejo が最も積極的 — 実験的機能として一部のインスタンスが有効化
  • Gitea は関心を表明したが優先順位が低い
  • SourceHut は独自のメールベースフェデレーションを好む

現実的な評価

ForgeFed が実際に動作する事例はまだ少ない。メッセージフォーマット、権限、衝突解決のような難しい問題が残っている。しかし「GitHub という 1 つの会社にコードエコシステムが丸ごと閉じ込められている」状況の本当の代替はフェデレーションしかないという認識が次第に強まっている。2027 ~ 2028 年頃には意味ある進展があるだろうというのが一般的見通し。

13. ArgoCD / Flux — GitOps がフォージの意味を再定義する

GitOps は「宣言的なインフラ状態を git に置き、コントローラーがその状態にクラスタを収束させる」というパターン。ArgoCD(Intuit 発、CNCF 卒業)と Flux(Weaveworks 発、CNCF 卒業)が二大ツールだ。

なぜこの記事で扱うか

GitOps はフォージの意味を変える — フォージは単なるコードホスティングではなく「システム状態の source of truth」になる。ArgoCD / Flux は自分が使うフォージが何であっても(GitHub、GitLab、Gitea、Forgejo、Bitbucket など)よく動くが、セルフホストフォージを使う時には次の二つが重要になる。

考慮事項 1 — 可用性

フォージが落ちると ArgoCD が sync できない。したがってフォージを高可用性で回すか、少なくとも素早い復旧手順が必要だ。GitLab CE の Geo 機能(EE 専用)、Gitea のシンプルな SQL バックアップ、Forgejo のアクティブ-パッシブ構成のようなオプションがある。

考慮事項 2 — Webhook とポーリング

ArgoCD が変更を検知する 2 つの方式 — webhook(即時)またはポーリング(デフォルト 3 分)。セルフホストフォージが webhook をクラスタへちゃんと送れるか確認する必要がある。ネットワーク分離環境ではポーリングのみ可能なこともある。

ArgoCD インストール例

kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Flux インストール例

flux bootstrap gitea \
  --hostname=git.example.com \
  --owner=platform \
  --repository=flux-clusters \
  --branch=main \
  --path=clusters/prod

Flux はブートストラップ自体が Git リポジトリを作って自分のマニフェストをそこに push する。Gitea / GitLab / GitHub / Bitbucket をすべてサポートするが、Forgejo と Gitness は Gitea 互換モードで回る(2026 年 5 月基準)。

14. ミラーツール — git-mirror、gitea-mirror

セルフホストフォージのよくある使用パターン — 「GitHub の公式リポジトリを社内 git サーバーへミラーリング」。このためのツールいくつか。

Gitea / Forgejo の内蔵ミラー

リポジトリ作成時に「Mirror this repository」オプションをチェックすると周期的に外部 git から pull する。最もシンプル。

git-mirror (Python)

git-mirror --source https://github.com/foo/bar \
  --target ssh://git@internal.example.com/mirrors/bar.git \
  --interval 3600

組織単位ミラー — gitea-mirror、forgejo-mirror

特定 GitHub Organization のすべてのリポジトリを自動でミラー。新しいリポジトリが追加されると自動でミラー登録。

source:
  type: github
  org: kubernetes
target:
  type: gitea
  url: https://git.example.com
  org: github-mirror-kubernetes
schedule: "0 */6 * * *"

なぜミラーを回すか

  • ネットワーク分離環境で外部コードを内部に取り込む
  • GitHub 障害時に備える
  • 会社ポリシー上、依存性コードを社内に保管する必要がある時
  • LFS オブジェクトまでミラーすれば大きなリポジトリも内部でビルド可能

15. 韓国 / 日本 — Toss、Kakao、メルカリ、Pixiv

韓国 — Toss、Kakao

Toss(Viva Republica)は社内 git インフラを運営していると公開的に言及したことがある。正確な実装は非公開だが、社内 GitLab または GitHub Enterprise を回す韓国フィンテックの一般的パターンに従う。Toss テックブログには社内開発環境統合に関する文章が上がる。

Kakao は一部のチームが GitHub Enterprise を、一部が GitLab を使うと知られている。グループ全体で統一するよりチームの自律を認める文化がある。Kakao テックブログ(tech.kakao.com)に DevOps / プラットフォーム文章が定期的に上がる。

NAVER も社内 git ホスティングを運営する。NAVER D2 ブログ(d2.naver.com)に開発インフラ関連の文章が時々上がる。NAVER も多くの社内ツールを自社開発、あるいはオープンソースを自分の環境に合わせてパッチして使うパターン。

日本 — メルカリ、Pixiv

メルカリ(Mercari)は GitHub Enterprise をメインで使うと自社エンジニアリングブログで何度も言及している。メルカリエンジニアリングブログ(engineering.mercari.com)は日本の IT 会社の中で最も多くの英文コンテンツを生産する所の一つだ。

Pixiv は日本のイラストコミュニティ会社で、社内 git を GitLab CE で回すと言及がある。inside.pixiv.blog に開発文化関連の文章が定期的に上がる。

LINE(現 LY Corporation)は GitHub Enterprise をメインに、一部の自社ツールも一緒に使う。engineering.linecorp.com に DevOps / プラットフォーム文章がある。

一般的なパターン

韓国 / 日本の大企業は次の三つのうち一つを選ぶのが一般的:

  1. GitHub Enterprise(ネットワーク分離環境では GitHub Enterprise Server セルフホスト)
  2. GitLab CE/EE セルフホスト
  3. Bitbucket Server(2024 年 EOL 以降 GitHub / GitLab に移る傾向)

Gitea / Forgejo は韓国 / 日本の大企業のメイン事例が少ない。しかしスタートアップ / 中小企業の社内 git サーバーとしては徐々に増えている。Raspberry Pi に Gitea を入れてサークルのコードホスティングをする学生事例も一般的だ。

16. 比較表 — 12 のツールを一目で

各ツールの性格を 1 行で整理:

  • Gitea: 最人気のセルフホスト、MIT、軽い
  • Forgejo: Gitea コミュニティフォーク、GPLv3 以上、ガバナンス明確
  • GitLab CE: オープンコア、重いが機能豊富
  • GitLab EE: GitLab CE + エンタープライズ機能、高価だがセキュリティ / コンプライアンス含む
  • OneDev: Java ベース、CI 強い、単一メンテナー
  • RhodeCode: 2024 年に事実上終了、新規ユーザー非推奨
  • Bitbucket Data Center: Atlassian、高価で Jira / Confluence ロックイン
  • SourceHut: JS なし、メールベース、ミニマリスト
  • Gitness: Harness 発、CI コア、新参者
  • Cgit: 静的的な動的ビューア、kernel.org が使用
  • Stagit: 本当に静的、suckless.org が使用
  • Tea CLI: Gitea / Forgejo 親和 CLI、gh と同じ位置

軸別比較

ライセンス自由度順: SourceHut / Forgejo(GPL) > Gitea / Gitness(MIT / Apache) > OneDev(MIT) > GitLab CE(MIT に近い) > GitLab EE / Bitbucket DC(商用)

運用の重さ順(軽いほう): Cgit / Stagit > Gitea / Forgejo / Gitness > SourceHut > OneDev > GitLab CE > GitLab EE / Bitbucket DC

GitHub との UX 親しみやすさ順: Gitea / Forgejo / Gitness > OneDev > GitLab > Bitbucket > SourceHut > Cgit / Stagit

17. 誰が何を選ぶべきか — 4 タイプ

タイプ 1 — 個人 / ホビー / 小さなサークル

答え: Gitea または Forgejo。SQLite バックエンドに Docker 1 行で入り、100MB のメモリでよく回る。両ツールの機能はほぼ同一なので、ガバナンス哲学を気にするなら Forgejo、「最大のコミュニティ」が良いなら Gitea。Tea CLI も一緒に入れよう。Raspberry Pi 4 程度で十分だ。

タイプ 2 — 5 ~ 50 名のチーム、CI が重要

答え: OneDev または GitLab CE。OneDev は軽く CI がコア。GitLab CE は重いが検証済み機能と大きなコミュニティ。ユーザーが 20 名以上で 8GB 以上の RAM インスタンスを回す余力があれば GitLab CE が答え。それより小さければ OneDev。Gitea + 別途 Drone CI の組み合わせも可能な選択。

タイプ 3 — エンタープライズ(ネットワーク分離、コンプライアンス)

答え: GitLab EE または GitHub Enterprise Server または Bitbucket Data Center。セキュリティスキャン / 監査ログ / SAML / SCIM / CODEOWNERS 強制 / 地理的レプリケーションが必要ならこの三つのうち一つ。費用は似たレベル。Jira / Confluence ロックインが強い所は Bitbucket DC、そうでなければ GitHub Enterprise または GitLab EE。韓国金融業界は GitLab EE の事例が多い。

タイプ 4 — ミニマリスト / メールパッチ / 静的サイト

答え: SourceHut または Cgit / Stagit。メールベースのパッチワークフローが好きで JavaScript なしの UI を好むなら SourceHut。協業ツールは他の所にあり、コード表示だけ静的にしたければ Cgit(動的、CGI)または Stagit(本当に静的)。両方とも dotfiles と小さなライブラリによく合う。

タイプ 5(ボーナス) — GitOps 中心

答え: 上のどのツールでも + ArgoCD / Flux。フォージ選択より GitOps パターンの方が重要だ。ArgoCD / Flux は Git フォージを選ばないが、セルフホストフォージの可用性を確保する必要がある。Flux は Gitea / Forgejo をよくサポートするので小さな環境で GitOps ブートストラップが簡単だ。

エピローグ — GitHub の影の下、それでも自分の場所

GitHub は 2026 年も依然として事実上の標準だ。セルフホスト git が GitHub を代替する可能性は低い。しかしセルフホストが消える可能性もない。ネットワーク分離、データ主権、コンプライアンス、「1 つの会社に依存したくない」という意志 — このすべてがセルフホストの席を作ってくれる。

2026 年春、その席に最も堅固に立っているのは Gitea と Forgejo だ。両ツールの分岐自体が「1 つの会社が支配できないフォージが必要だ」という欲望の証拠だ。GitLab CE/EE は巨大なオープンコアで自分の場所を固め、OneDev / Gitness は小さなチームに新しい選択肢を与える。SourceHut / Cgit / Stagit は「フォージが GitHub のように見える必要はない」というもう一つの可能性を守る。ForgeFed はまだ実験だが本当のフェデレーションの可能性を開いておき、ArgoCD / Flux はフォージの意味を「コード保管所」から「システム状態の source of truth」へ拡張する。

自分のコードを自分のサーバーに置くことは些細な決定のように見えるが、結局「誰が私のコードの運命を決めるか」という大きな質問に答える行為だ。その答えを自分に置きたい人々に、2026 年のセルフホスト git エコシステムはいつにも増して豊富な選択肢を与える。

参考 / References

Discuss on Twitter • View on GitHub