【2026年】Forgejo セルフホストGit 完全ガイド｜Gitea フォークの決定版

Forgejo の概要と Gitea フォークとしての位置づけ

Forgejo は、開発者コミュニティの自律性を重視する現代において非常に重要な役割を果たすセルフホスト Git サーバーです。2026 年 4 月時点では、Forgejo はバージョン 10.x を最新安定リリースとして提供しており、その機能性は成熟期を迎えています。元々は Gitea プロジェクトの一部であった時期がありましたが、ライセンスやガバナンス方針の違いから独立し、完全なオープンソースコミュニティ主導で開発が進められています。特に、Gitea 1.23 や GitLab CE と比較した場合、Forgejo は軽量でありながら企業レベルの認証機能を標準でサポートする点に大きな強みがあります。

この Fork の背景には、大規模プラットフォームへの依存を減らしつつも、GitHub や GitLab に匹敵する機能性を維持したいという開発者のニーズがありました。2026 年現在、Forgejo は SQLite、PostgreSQL、MySQL をバックエンドとしてサポートしており、小規模な個人利用から大規模な組織運用まで柔軟にスケールできるアーキテクチャを確立しています。また、GitHub Actions に似た Forgejo Actions の実装により、CI/CD パイプラインの構築も自前で完結できるようになり、完全なデータ主権を確保することが可能となっています。

Forgejo を採用する最大のメリットは、ライセンスの自由度と機能の透明性にあります。 proprietary な機能にロックされないため、将来的な仕様変更や料金体系の変動リスクを回避できます。また、コミュニティによる活発なプラグイン開発により、Webhook 連携や LDAP 認証などの拡張機能も充実しています。本ガイドでは、Forgejo 10.x の最新機能を最大限に活用するための構築手順から、セキュリティ強化、運用ノウハウまでを網羅的に解説します。

システム要件とデータベース選定の詳細

Forgejo 10.x を安定して稼働させるためには、適切なシステムリソースの割り当てが不可欠です。最低限の動作環境として、4GB の RAM と 2 コア以上の CPU を推奨しますが、これは SQLite バックエンドを利用し、小規模なプロジェクト（ユーザー数 50 人未満）を想定した場合の数値です。大規模な運用や、Forgejo Actions を多用する環境では、メモリは 16GB 以上、CPU は 8 コア以上を用意することが望ましいでしょう。特に、CI/CD ジョブが並列実行される際、Runner プロセスが大量のメモリを消費するため、十分なバッファを持たせることがパフォーマンス維持の鍵となります。

データベース選定は、システムの信頼性に直結する重要な決定事項です。SQLite は設定の手間がかからず、単一ファイルで完結するため、テスト環境や個人利用には最適です。しかし、2026 年時点の標準的な運用では、トランザクション処理に強い PostgreSQL の使用が強く推奨されます。PostgreSQL を採用することで、並列書き込み時のデッドロックリスクを大幅に低減でき、バックアップとリストアの効率も向上します。また、MySQL も利用可能ですが、Forgejo 10.x では PostgreSQL との親和性がより高く、拡張性においてやや優位な立場にあります。

データベースの設定には、接続文字列やチューニングパラメータの詳細な指定が必要です。PostgreSQL を使用する場合、shared_buffers や work_mem の設定をサーバーのメモリ量に合わせて最適化することが重要です。例えば、8GB のメモリを持つサーバーでは、shared_buffers を 2GB に、work_mem を 64MB に設定することで、クエリ実行速度が劇的に改善されます。また、データベースユーザーには最小権限の原則を適用し、Forgejo アプリケーション用の専用ロールを作成して権限制限を行うことで、セキュリティホールを事前に塞ぐことができます。

Docker Compose を用いた簡易導入手順

最も手軽に Forgejo 10.x を導入する方法は、Docker Compose を利用することです。まず、サーバー上に Docker Engine と Docker Compose プラグインがインストールされていることを確認します。その後、プロジェクトのディレクトリを作成し、docker-compose.yml ファイルを配置します。このファイルには、Forgejo のコンテナ定義、PostgreSQL データベースの定義、そして永続化するためのボリューム設定が含まれます。2026 年時点では、セキュリティのため、外部ネットワークに直接アクセスさせず、内部ネットワークを通じて通信させる構成が標準となっています。

docker-compose.yml の作成においては、環境変数の管理を適切に行う必要があります。例えば、データベースの接続情報や、Forgejo アプリの設定キー（SECRET_KEY）はハードコードせず、.env ファイルで管理することを推奨します。これにより、機密情報がバージョン管理システムに誤ってコミットされるリスクを防げます。また、Forgejo のコンテナには network_mode: bridge を指定し、リバースプロキシ側からのアクセスを受け取るためのポートマッピングを適切に行います。通常、HTTPS 経由でアクセスする場合、8080 ポートは内部接続用として開放し、外部からは 443 ポートをリバースプロキシが処理する構成が一般的です。

導入後、初期設定画面へのアクセス方法にも注意が必要です。Docker コンテナ起動直後は、データベースのマイグレーションが行われるため、数分待ってからログインページにアクセスする必要があります。また、admin パスワードは Docker コンテナ標準出力に表示されるか、または初期設定画面で指定した後の環境変数として保持されます。セキュリティ強化のため、初期設定完了後にはパスワードを必ず変更し、SSH 認証のみの使用や、強力なパスワードポリシーの適用を行います。さらに、バックアップ用スクリプトも導入時に併せてセットアップしておくことで、障害発生時の復旧時間を最小限に抑える準備を整えておきます。

Podman と Kubernetes への拡張戦略

Docker Compose は簡易的な導入には優れていますが、本番環境における高可用性やスケーラビリティを求められる場合、Podman や Kubernetes への移行を検討すべきです。特に、Kubernetes クラスター上で Forgejo を運用する場合、StatefulSet を利用してデータベースとアプリケーションを分離し、永続ボリューム（PV）を動的に割り当てることで、ノード障害時のデータ保持を保証できます。2026 年の Kubernetes 標準では、Helm チャートによる管理が主流となっており、Forgejo の公式チャートやコミュニティ製チャートを適用することで、複雑な設定ファイルを直接記述する手間を省くことができます。

Podman は Docker と互換性のある OCI コンテナランタイムであり、rootless モードでの実行が可能です。これはセキュリティ観点から非常に重要で、コンテナ内で特権モードを実行しないことで、仮にコンテナが破損してもホストシステムへの影響を最小限に抑えられます。Forgejo 10.x は Podman との親和性も高いため、podman-compose を利用して同様の設定ファイルを運用可能です。特に、クラウドネイティブな環境や、セキュリティ要件が厳しいオンプレミス環境では、Podman の採用が進んでいます。Rootless モードの設定には、ユーザーネームスペースの適切な割り当てと、SELinux や AppArmor ポリシーの調整が必要です。

Kubernetes 環境での拡張においては、Ingress Controller の設定も重要です。Traefik や Nginx Ingress Controller を使用して、TLS 証明書の自動更新（Let's Encrypt など）を自動化できます。また、Forgejo Actions の Runner を Kubernetes Job または Deployment として動的にスケーリングする構成も可能です。これにより、CI/CD ジョブの負荷が集中している際にのみ計算リソースを確保し、通常時は不要なリソース消費を防ぐことができます。ただし、Runner 側のネットワーク接続や、Secret の管理には高度な知識が必要となるため、まずは小規模なクラスタで検証を行うことをお勧めします。

Forgejo Actions CI/CD の完全セットアップ

Forgejo Actions は、GitHub Actions と互換性があるワークフローエンジンであり、セルフホスト環境における自動化の核となります。2026 年時点では、YAML ベースのワークローファイル（.forgejo/workflows または .github/workflows）を記述することで、ビルド、テスト、デプロイパイプラインを定義できます。導入にはまず、Forgejo Actions サーバーと、Runner をセットアップする必要があります。サーバー側では、app.ini の設定で actions.enabled = true を有効にし、JWT トークンや Runner 登録トークンを発行します。

Runner は、実際の CI/CD ジョブを実行するエージェントです。単一のサーバーに配置することも可能ですが、セキュリティと性能の観点から、Runner は隔離された環境（Docker コンテナまたは VM）で実行するのがベストプラクティスです。Runner を登録するには、Forgejo ダッシュボードから生成した Token を Runner の設定ファイル（config.json）に記述し、サービスとして起動します。2026 年の標準的な運用では、Runner もまた Containerd や Podman で管理され、ジョブ完了後にコンテナを破棄するエフェメラルな構成が採用されています。

Workflow の設計においては、セキュリティリスクへの対策が不可欠です。例えば、PR の外部リポジトリからワークフローを実行する場合、トークンの漏洩や悪意あるコード実行を防ぐために、permissions セクションで最小限の権限しか与えないように設定します。また、Secret 管理には Forgejo 標準の Secret 機能を利用し、環境変数として暗号化して渡す方式を採用します。これにより、ソースコード内に機密情報が含まれるリスクを排除できます。さらに、Codeberg の事例でも実証されている通り、Forgejo Actions は特定のイベント（push, pull_request など）にトリガーを設定することで、効率的なデプロイサイクルを実現しています。

LDAP / OAuth / SAML 認証連携の実装

企業環境での運用において、IDP との統合は必須要件となります。Forgejo 10.x では、LDAP、OAuth2（OIDC）、SAML などの標準認証プロトコルをネイティブでサポートしています。まず LDAP 接続を設定する場合、app.ini の AUTH_LDAP セクションにサーバー情報とバインド DN を指定します。2026 年時点では、LDAPS（暗号化された LDAP）の使用が推奨されており、証明書の検証設定も必須です。ユーザーマッピングやグループ同期を自動実行することで、管理者の手間を大幅に削減できます。

OAuth2 と OIDC の連携は、Google や Microsoft などのプロバイダーとの連携でよく利用されます。Forgejo を Service Provider とし、外部の IdP を Identity Provider として設定します。設定には、クライアント ID、シークレットキー、およびコールバック URL の登録が必要です。特に SAML 認証を利用する場合は、IdP のメタデータ XML ファイルを Forgejo にインポートし、エンティティ ID や Assertion Consumer Service (ACS) エンドポイントを正確に指定します。これにより、シングルサインオン（SSO）を実現し、ユーザーパスワードを管理する必要がなくなります。

認証設定を行う際、フォールバック処理の設計も重要です。LDAP 接続が切断された場合でも、ローカルアカウントでログインできる設定や、エラーメッセージを適切に表示する設定を行います。セキュリティ強化のため、多要素認証（MFA）との連携も可能です。また、認証ログの監視と監査機能を活用し、不正アクセスを試みた IP アドレスの自動ブロックなどを設定します。2025 年以降、ゼロトラストアーキテクチャが標準となりつつあるため、Forgejo の認証機能は、外部プロキシや WAF と連携して多層的なセキュリティを構築することが求められています。

セキュリティ強化とリバースプロキシ構成

Web サーバーとして直接 Forgejo にアクセスさせるのはリスクが高いため、必ずリバースプロキシ（Caddy, Traefik, Nginx）を介して運用します。Caddy は自動 SSL 証明書の取得に優れており、設定ファイルが簡潔で初心者にも扱いやすいです。一方、Traefik や Nginx はより細かい制御が可能で、企業環境での標準的な構成に適しています。リバースプロキシでは、WebSocket の処理（Forgejo のリアルタイム機能用）を適切に転送することが重要です。Nginx の場合、Upgrade to WebSocket ヘッダーのセットと proxy_read_timeout の設定が必須となります。

セキュリティ強化のためには、HTTP 応答ヘッダーの設定も徹底する必要があります。例えば、X-Frame-Options: DENY でクリックジャッキングを防ぎ、Content-Security-Policy で外部リソースの読み込みを制限します。また、TLS 1.3 のみを許可し、古いプロトコル（TLS 1.2 以下）や脆弱な暗号化スイートを無効化する設定を行います。Let's Encrypt や DigiCert などの CA から証明書を取得する際、自動更新スクリプト（certbot など）を Cron に登録し、期限切れによるサービス停止を防ぎます。

さらに、ファイアウォールと fail2ban の活用も欠かせません。SSH アクセスは SSH キー認証のみ許可し、パスワード認証を無効化します。また、Forgejo への Brute Force 攻撃を検知するために fail2ban を設定し、一定回数ログイン失敗があった IP を自動的にブロックするようにします。2026 年時点では、これらのセキュリティ対策が自動化されており、初期設定時に推奨テンプレートとして適用可能な構成も提供されています。定期的な脆弱性スキャンとパッチ適用プロセスを確立することで、長期的に安全な運用環境を維持できます。

LFS および Webhook 活用術

Git Large File Storage（LFS）は、バイナリファイルや大容量データを Git リポジトリに保存する際の標準的な解決策です。Forgejo 10.x は LFS サーバー機能を標準で備えており、設定を行うことで Git LFS クライアントとシームレスに連携できます。設定には、app.ini で LFS_ENABLED = true を指定し、ストレージパスを定義します。これにより、画像や動画ファイル、コンテナイメージなどが適切に管理され、リポジトリの肥大化を防ぎます。

Webhook 機能を活用することで、Forgejo のイベントを外部システムと連携させることが可能になります。例えば、コードがプッシュされた際に JIRA や Slack に通知を送ったり、CI/CD ツールのトリガーとしたりできます。Webhook を設定する際は、シークレットキーを設定してリクエストの正当性を検証することが重要です。2026 年時点では、Webhook の送信先 URL が HTTPS で保護されていることが必須要件となっています。また、Webhook ヘッダーに署名を含めることで、改ざん防止を図ります。

さらに、Forgejo Actions と Webhook を連携させることで、より高度な自動化が可能です。特定のブランチへのプッシュをトリガーに、自動でドキュメント生成やデプロイを行うワークフローを設定できます。また、Codeberg の事例でも確認されていますが、サードパーティ製プラグインを利用することで、Webhook 処理のロジックを Forgejo 外部のスクリプトに任せることで、サーバー負荷を分散させる手法も有効です。ただし、Webhook の頻度が多すぎるとサーバーへの負荷になるため、適切なレート制限やキューイング設定を行うことが重要です。

Gitea / GitLab との機能比較と移行

Forgejo を選択する際、既存の Gitea や GitLab CE との比較は避けられません。下表に Forgejo 10.x、Gitea 1.23、GitLab CE の主要機能を比較します。Forgejo は Gitea から派生したフォークですが、ライセンスやガバナンス方針が異なります。Gitea 1.23 は引き続き開発が続いていますが、Forgejo は完全に独立したコミュニティで運営されており、特定の企業への依存がありません。GitLab CE は機能は豊富ですがリソース消費が大きく、複雑な設定が必要となります。

移行手順については、既存の Gitea や GitLab から Forgejo へのデータ移動を想定しています。まず、ソースサーバーからデータベースとリポジトリデータをエクスポートします。Forgejo の初期設定で同じデータベーススキーマを作成し、データをインポートします。Git リポジトリは git clone --bare を用いて転送することも可能です。ただし、パスワードやシークレット情報は平文では保存されないため、暗号化されたバックアップから復元する必要があります。移行中はサービス停止時間を最小限に抑えるよう、DNS の切り替えタイミングを慎重に計画します。

また、移行後の検証プロセスも重要です。Webhook の設定変更や、CI/CD ワークフローの調整が必要です。Forgejo Actions は GitHub Actions に近い構文を使用するため、ワークフローファイルの修正は比較的容易です。ただし、Runner 側の環境依存部分は再構築が必要な場合があります。最終的には、ユーザーアカウントのマッピング確認と、アクセス権限の継承を確認してから、本番環境への切り替えを行います。

よくある質問（FAQ）

Q1: Forgejo 10.x の最新バージョンをインストールする手順は？ A: A: Docker Hub または GitHub Releases から最新の forgejo/forgejo イメージをプルし、Docker Compose でコンテナを起動します。設定ファイルのマイグレーションが自動で行われるため、旧バージョンからのアップグレードもサポートされています。

Q2: SQLite バックエンドでも本番環境で問題ない？ A: A: 小規模利用であれば問題ありませんが、併行書き込みが多い場合は PostgreSQL を推奨します。SQLite はロック競合が発生しやすく、大量の CI/CD ジョブ実行時にパフォーマンス低下を招く可能性があります。

Q3: Forgejo Actions の Runner はどこに設置すべき？ A: A: セキュリティのため、Runner は主サーバーとは異なる VM またはコンテナで運用するのがベストです。また、Runner へのアクセス権限も最小限に制限し、不要なパッケージのインストールを防止します。

Q4: LDAP とローカルアカウントの併用は可能？ A: A: はい、可能です。app.ini で AUTHENTICATION_TYPE を設定することで、LDAP が失敗した際にローカルアカウントでのログインをフォールバックさせることができます。

Q5: SSL 証明書を自己署名にするのは安全か？ A: A: 開発環境では問題ありませんが、本番環境では Let's Encrypt など信頼された CA の証明書を推奨します。自己署名はブラウザ警告が発生し、ユーザー体験を損なうためです。

Q6: LFS を有効にした場合のストレージ管理は？ A: A: LFS オブジェクトは別パスに保存されます。バックアップスクリプトでもこのディレクトリを含める必要があります。また、ディスク容量が不足しないようモニタリング設定を推奨します。

Q7: GitLab から Forgejo への移行で注意点は？ A: A: GitLab CI のワークフロー記述は Forgejo Actions と構文が異なる部分があるため、再検証が必要です。また、GitLab の Issue や Wiki のデータ形式も互換性がない場合があり、手動転送が必要な場合があります。

Q8: 外部からの攻撃対策として何をするべき？ A: A: fail2ban の導入、SSH キー認証の必須化、定期的なパッチ適用に加え、WAF（Web アプリケーションファイアウォール）をリバースプロキシに追加して侵入を防ぐことが有効です。

Q9: バックアップはどのように取得すべきか？ A: A: データベースとリポジトリディレクトリの両方を定期的に圧縮バックアップします。また、app.ini や docker-compose.yml などの設定ファイルもバージョン管理下に置いておくべきです。

Q10: Forgejo のコミュニティサポートは充実しているか？ A: A: はい、GitHub Issues や Discord サーバーなどで活発な議論が行われています。日本語のドキュメントも徐々に増えつつあり、2026 年時点では主要言語に対応しています。

まとめ

本ガイドを通じて、Forgejo セルフホスト Git サーバーの構築と運用について詳しく解説いたしました。Forgejo 10.x は、Gitea のフォークとして生まれ変わり、完全なオープンソースコミュニティ主導で進化を続けています。2026 年現在では、軽量かつ堅牢な設計により、個人のプロジェクトから大規模組織の基盤まで幅広く活用されるに至っています。

記事全体の要点を以下にまとめます。

• システム要件: SQLite は小規模向け、本番環境には [PostgreSQL を推奨し、リソースは CI/CD 負荷に合わせて拡張する必要がある。
• 導入方法: [Docker Compose が手軽だが、高可用性には Kubernetes や Podman の利用が有効である。
• CI/CD: Forgejo Actions は GitHub Actions と類似しており、Runner の適切な隔離と権限管理が必須となる。
• 認証連携: LDAP, OAuth2, SAML をサポートし、企業環境での SSO 導入も容易に行える。
• セキュリティ: リバースプロキシの活用、TLS1.3 強制、fail2ban の設定など多層防御が求められる。
• 比較・移行: GitLab や Gitea と比較して軽量かつ自由度が高いため、移行には注意深い計画が必要である。

Forgejo を導入することで、開発データの完全な主権を確保し、長期的なコスト削減とセキュリティ強化を実現できます。ぜひ本ガイドを参考に、自社やチームに最適な環境を構築してください。