LASSIC Media らしくメディア
GitLab/Gitea セルフホストGit基盤の外注構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- GitLabとGiteaはいずれもセルフホストできるGit基盤ですが、必要なサーバーリソースや運用の手間には違いがあります。
- GitLab SaaS（GitLab.com）とセルフホスト（Self-Managed）では、管理できる範囲とバックアップの責任範囲が異なります。
- 構築から移行・バックアップ運用まで外部委託すると、専門人材を新たに確保する負担を抑えられます。
目次
GitLab/Giteaのセルフホスト外注構築とは
GitLab/Giteaを使ったセルフホストのGit基盤外注構築とは、GitLabまたはGiteaを自社サーバーやクラウド環境に導入し、構築・移行から運用・バックアップまでを外部の専門パートナーへ委託する取り組みです。
GitLab Self-Managedの推奨環境は8vCPU・メモリ16GBが目安とされており*1、社内だけで構築から保守体制まで整えるには相応の負荷がかかります。
なぜ今セルフホストのGit基盤が見直されているか
クラウド型のGitホスティングは手軽に使い始められる一方、ユーザー数が増えるほど利用料が積み上がります。GitLab.com（SaaS）の有償プランは、Premiumが1ユーザーあたり月額29ドル（年間契約）、Ultimateはカスタム見積もりとなっており*2、開発者数の多い企業ほど固定費として重くのしかかります。
そのため、社内の利用人数やリポジトリ数が一定規模を超えた企業では、ユーザー課金型のSaaSから自社インフラのコストへ切り替える動きが出ています。ソースコードや設計情報を社外のクラウドに置かず、自社の管理下に置きたいというデータガバナンスの要請も、セルフホストを検討する理由の一つといえます。
コスト最適化の観点では、Git基盤の維持費だけでなく、構築・移行・運用にかかる人件費まで含めて比較する必要があります。この人件費の見積もりを誤ると、セルフホスト化がかえって割高になるケースもあるため、外部パートナーへの相談段階から工数の見立てを共有しておくことが望ましいでしょう。
GitLab SaaSとセルフホスト（Self-Managed）の違い
GitLabには、クラウド上でGitLab Inc.が運用するSaaS版「GitLab.com」と、自社のサーバーやクラウド環境にインストールして運用する「GitLab Self-Managed」の2つの提供形態があります。Self-Managedの導入方法には、Linuxパッケージ・Helmチャート・Docker・Operator・ソースからのビルドなどが用意されています*3。
同じGitLab製品でありながら、管理できる範囲は大きく異なります。管理者向けの「Admin area」機能は、Self-ManagedまたはGitLab Dedicatedの管理者のみが利用でき、GitLab.comでは提供されていません*4。ユーザーへのなりすまし確認や、システムログの直接参照といった運用管理は、Self-Managedの管理者権限があって初めて行えます。
バックアップの扱いにも明確な線引きがあります。GitLabの公式ドキュメントは「GitLab.comではデータ保護の体制が確保されているが、この方法でGitLab.comからデータをエクスポート・バックアップすることはできない」と明記しており*5、Self-Managedではその裏返しとして、バックアップとリストアの計画・実行を利用者側が担う設計になっています。
| 比較項目 | GitLab SaaS（GitLab.com） | GitLab Self-Managed |
|---|---|---|
| 運用主体 | GitLab Inc.が運用 | 自社または委託先が構築・運用 |
| Admin area | 利用不可*4 | 利用可能*4 |
| バックアップ | エクスポート・バックアップは不可*5 | 計画・実行を利用者側が担う*5 |
| 初期構築 | 登録すればすぐ利用可能 | サーバー要件確認・構築が必要*1 |
| 料金体系 | ユーザー課金（Free/Premium/Ultimate）*2 | ライセンス費用＋インフラ費用 |
GitLabとGiteaの比較
Giteaは、Go言語で書かれたオープンソースのセルフホスト型Gitサービスです。公式ドキュメントでは、GitHub・Bitbucket・GitLabと比べて「最も簡単で速く、手間の少ないセルフホストGitサービスの構築方法」と位置づけられています*6。
必要なリソースの小ささも特徴の一つです。公式ドキュメントは「Raspberry Pi 3でも小規模ワークロードには十分な性能」「小規模チームであれば2CPUコア・メモリ1GBで足りることが多い」としており*6、GitLab Self-Managedの推奨環境（8vCPU・メモリ16GB*1）と比べると、必要な計算資源には大きな開きがあります。
対応データベースにも違いがあります。GitLabが公式にサポートするデータベースはPostgreSQLのみですが*1、GiteaはPostgreSQL・MySQL・MariaDB・SQLite・MSSQLなど複数のデータベースドライバに対応しています*6。既存のデータベース運用資産を活かしたい企業にとっては、選べる幅の広さがメリットになるでしょう。
| 比較項目 | GitLab（Self-Managed） | Gitea |
|---|---|---|
| 想定リソース | 1,000ユーザー規模で8vCPU・メモリ16GBが目安*1 | 小規模チームなら2CPUコア・メモリ1GB程度で稼働する例あり*6 |
| 対応データベース | PostgreSQLのみ*1 | PostgreSQL・MySQL・MariaDB・SQLite・MSSQL*6 |
| 対応OS/アーキテクチャ | 主要Linuxディストリビューション向けパッケージ提供*3 | Go対応の全プラットフォーム（Linux/macOS/Windows、x86/amd64/ARM/PowerPC）*6 |
| 向いている規模 | 数百〜数千人規模の全社的なDevSecOps基盤 | 小〜中規模チームの軽量なGitホスティング |
セルフホスト構築に必要な要件
サーバー・データベースの要件
GitLabをSelf-Managedで構築する場合、公式要件では秒間20リクエストの負荷・1,000ユーザー規模を想定して8vCPU・メモリ16GBがベースラインとされ、アプリケーションノードだけで40GB以上のストレージを見込む必要があります*1。データベースはPostgreSQL専用で、amcheckやpg_trgmといった指定の拡張機能を有効にする設計です*1。
Giteaであれば必要リソースは小さく抑えられますが*6、バックアップ・監視・アップデートといった運用設計を自前で組む必要がある点はGitLabと変わりません。サーバー要件の見積もりを誤ると、後から増設やデータベース移行のやり直しが発生し、余計な工数がかかります。
ネットワーク・認証・移行の設計
社内外からのアクセス制御、SSO（シングルサインオン、複数システムに1回のログインでまとめてアクセスできる仕組み）連携、既存リポジトリからのデータ移行など、構築時に決めるべき項目は多岐にわたります。これらを内製で担うには、Linuxサーバー運用・PostgreSQL運用・Git内部構造・認証基盤連携の知識を持つ人材の確保が必要です。
必要な知識をひとりですべて満たす人材は少なく、構築・移行・運用でそれぞれ担当が分かれるケースも珍しくありません。設計を誤ると、移行後にリポジトリ履歴の一部が欠落する、CI/CDが正常に動かないといった手戻りにつながります。
構築後の運用・バックアップ体制という壁
セルフホストの構築を終えても、運用フェーズには別の負荷が待っています。GitLabの公式ドキュメントは、バックアップの目的として「ハードウェア故障・ソフトウェアの不具合・誤削除からのデータ保護」「災害復旧」「規制対応」などを挙げており*5、Self-Managedではこれらを利用者側が計画・実行する前提です。
バックアップやリストアの手順を誤ると、リポジトリやIssue・マージリクエストの履歴が失われ、開発チーム全体の作業が止まりかねません。特に複数のPostgreSQLサーバーにまたがる構成では、バックアップ対象の切り分け自体が難しくなります*5。
専門パートナーへ構築・運用を委託した場合との違いは明確です。委託先は複数の顧客環境で構築・バックアップ運用の実績を積んでいるため、リストア手順の検証やアップデート時の互換性確認といった作業をあらかじめ型化しています。内製の場合は、こうした知見を一から積み上げる時間とリスクを自社で負うことになります。
外注構築の進め方
GitLab/Giteaのセルフホスト外注構築は、要件定義・ツール選定・構築移行・運用引き継ぎの4ステップで進めます。
ステップ1：要件定義（用途・想定ユーザー数の整理）
まず、利用する開発者数・リポジトリ数・CI/CD利用の有無など、必要な規模感を整理します。ここで見積もった規模が、後工程のサーバースペックやツール選定を判断する材料になります。
ステップ2：ツール選定（GitLabとGiteaの比較検討）
全社的なDevSecOps基盤としてセキュリティスキャンや高度な権限管理まで求めるならGitLab、まずは軽量にGitホスティングを立てたいならGiteaというように、想定規模と必要機能から選び分けます。
ステップ3：構築・移行（環境構築とデータ移行）
選定したツールをサーバーやクラウド環境に構築し、既存のリポジトリ・Issue・権限設定を移行します。移行時はデータの整合性確認が欠かせません。
ステップ4：運用引き継ぎ（バックアップ・監視体制の構築）
最後に、バックアップの取得スケジュール・監視・アップデート方針を整え、運用担当への引き継ぎドキュメントを整備します。ここまで委託することで、構築後も継続的な運用体制を保てます。
まとめ：セルフホスト外注構築で判断すべき3つの軸
本稿では、GitLab/GiteaによるセルフホストGit基盤の外注構築について、GitLab SaaSとの違い・GitLabとGiteaの比較・構築後の運用課題を整理しました。判断軸は3つに集約できます。第一に、SaaSとSelf-Managedのどちらが自社の管理体制・コスト構造に合うかという点です。第二に、想定するユーザー数や必要機能からGitLabとGiteaのどちらが適切かを見極める必要があります。第三に、構築だけでなくバックアップ・運用まで見据えた体制をどう確保するかが問われます。
よくある質問
GitLabとGiteaはどちらもセルフホストできますか？
はい、いずれもセルフホスト型の導入が可能です。GitLabは企業向けの高度な権限管理・セキュリティ機能を備えた大規模構成に向き、Giteaは小規模チームでも軽量に運用できる構成に向くという違いがあります*1*6。
GitLab SaaS（GitLab.com）からセルフホストへ移行できますか？
GitLabはSelf-Managedへの移行を想定した構成になっており、Linuxパッケージ・Docker・Helmチャートなど複数のインストール方法が用意されています*3。移行時はリポジトリやIssueのデータ整合性確認が必須です。
セルフホストに必要なサーバースペックはどれくらいですか？
GitLabは1,000ユーザー規模で8vCPU・メモリ16GBが目安です*1。Giteaは小規模チームであれば2CPUコア・メモリ1GB程度で稼働する例もあり*6、必要な規模はツールによって大きく異なります。
バックアップは誰が行う必要がありますか？
セルフホストでは利用者側が計画・実行する前提です。GitLabの公式ドキュメントも、GitLab.comとは異なりSelf-Managedではバックアップの管理が利用者の責任範囲であることを明記しています*5。
構築だけでなく運用まで外注できますか？
はい。要件定義・ツール選定・構築移行に加え、バックアップ・監視体制の設計まで含めて委託することで、構築後も継続的な運用体制を保ちやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：GitLab「Installation requirements」（GitLab Docs、docs.gitlab.com/install/requirements/）
- *2 出典：GitLab「Pricing」（about.gitlab.com/pricing/）
- *3 出典：GitLab「Install GitLab」（GitLab Docs、docs.gitlab.com/install/）
- *4 出典：GitLab「Admin area」（GitLab Docs、docs.gitlab.com/administration/admin_area/）
- *5 出典：GitLab「Back up and restore overview」（GitLab Docs、docs.gitlab.com/administration/backup_restore/）
- *6 出典：Gitea「What is Gitea?」（Gitea Documentation、docs.gitea.com）
