--- canonical: https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/ language: ja generated: 2026-10-21T13:32:56.744Z --- [ホーム](https://koalavps.com/ja/) / [探索](https://koalavps.com/ja/resources/) / KoalaVPSのフィールドノート KoalaVPSのフィールドノート # 自分で再構築できる小さなフォージ。 Gitサービスを利用すれば、リポジトリとコラボレーションを自らの管理下に置けます。コード、データベース、ビルドシステムはそれぞれ別に保護してください。 [VPSを見つける](https://koalavps.com/ja/vps/) ## このドキュメント内 [コラボレーション層を選択する](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-1)[ビルドをフォージから分離する](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-2)[アクセスと登録を保護する](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-3)[サービス全体をバックアップする](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-4)[フォージ復旧チェックリスト](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-5)[デプロイ権限を最小限に保つ](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-6)[目的に合う最小限のコラボレーションサービスを使用する](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-7)[Web、SSH、データベースのパスを分離する](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-8)[クローン、プッシュ、拒否される操作を確認する](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-9)[リポジトリだけでなくディスカッションも復元する](https://koalavps.com/ja/guides-self-host-git-server-on-a-vps/#section-10)[ナレッジベース](https://koalavps.com/ja/resources/) ## コラボレーション層を選択する ForgejoとGiteaは軽量なフォージソフトウェアの例です。小規模なワークフローであれば、プレーンなSSH Gitで十分な場合があります。イシュー、レビュー、パッケージストレージ、アイデンティティ要件をプロジェクトに合わせてください。現在サポートされているバージョンとライセンスを確認してください。 ## ビルドをフォージから分離する CI ランナーはプロジェクトが管理するコードを実行するため、無制限の forge 認証情報やホスト認証情報を保持すべきではありません。ランナーを分離し、トークンのスコープを限定し、リポジトリサービスと同じ特権アカウントで信頼できないジョブを実行しないようにしてください。 ## アクセスと登録を保護する サービスが非公開の場合は、公開サインアップを無効にしてください。個別のアカウント、強力な認証、慎重に範囲を限定したデプロイキーを使用してください。SSH ポートとホストキーを文書化し、ホストキーの警告を無視する習慣をユーザーに暗黙のうちに身につけさせないでください。 ## サービス全体をバックアップする リポジトリだけでは、イシュー、アカウント、添付ファイル、設定が含まれない場合があります。フォージの一貫したバックアップ手順に従い、ファイル権限とアプリケーションシークレットを維持したまま復元をテストしてください。 ## フォージ復旧チェックリスト データベースを一貫した方法でエクスポートし、リポジトリのストレージ、添付ファイル、有効な場合は大容量ファイルストレージ、設定、暗号化シークレットを保持してください。復元後、意図した SSH または HTTPS 経由でクローンを検証してください。ビルドがサービス自身の設定を書き換えられないよう、フォージと CI ワーカーを分離してください。 ## デプロイ権限を最小限に保つ コードを取得するだけのサーバーであれば、読み取り専用のデプロイキーで十分な場合があります。リリース自動化には、小さな追加スコープが必要になることがあります。マシンごとに独立したキーを使用し、その目的を記録し、マシンの廃止時に削除することをお勧めします。 ## 目的に合う最小限のコラボレーションサービスを使用する 少数のプライベートリポジトリの場合、制限された SSH 上のベア Git で十分な場合があります。Forgejo や Gitea は、データベース、アプリケーションの更新、より多くの永続状態を犠牲にして、アカウント、プルリクエスト、イシュー、オプションのパッケージを追加します。チームが実際に使用する機能を記録してください。リポジトリの成長、大容量ファイルオブジェクト、添付ファイル、ビルド成果物を別々に予算化してください。CI の計算リソースはフォージ自体を超える可能性があります。 - 正規の HTTPS 名を選択し、その DNS アカウントを保護してください。 - 登録をクローズ制、招待制、承認制のいずれにするかを決定してください。 - フォージサービスに非特権のIDと永続的なプライベートストレージを付与してください。 公式ドキュメント: [Forgejoコンテナのインストール](https://forgejo.org/docs/latest/admin/installation/docker/) ## Web、SSH、データベースのパスを分離する 選択したリリースの上流設定を使用し、意図したイメージバージョンを固定してください。TLSリバースプロキシは内部のWebリスナーに到達できる必要があり、データベースにはforgeからのみ到達できるようにしてください。Git SSHがコンテナポートを使用する場合、公開ホストと外部ポートをマッピングと一致させてください。forgeを変更する際に、ホスト管理者のSSHリスナーを置き換えたり誤って公開したりしないでください。初期オーナーの作成後は、インストール・セットアップ用のアクセスを閉じてください。 - アプリケーションを起動する前に、永続ボリュームの所有権を確認してください。 - forge データベースに限定されたデータベースユーザーを使用してください。 - 特に信頼できないリポジトリでは、CI ランナーを別の信頼境界に置いてください。 公式ドキュメント: [ForgejoのDockerネットワーキングと永続化](https://forgejo.org/docs/latest/admin/installation/docker/) ## クローン、プッシュ、拒否される操作を確認する 使い捨てのプライベートリポジトリを作成し、通常の開発者アカウントからHTTPSまたはSSHのクローンURLをテストしてください。無害なファイルをコミットしてプッシュし、別の承認された読み取り者がそれを取得できることを確認してください。招待されていないアカウントはプライベートリポジトリの読み取りに失敗する必要があります。有効になっている場合は、大容量ファイルの処理と通知メールを確認してください。デプロイ専用のマシンでは、読み取り専用キーが取得できてプッシュできないことをテストしてください。認証の成功だけでは、意図した権限境界を証明できません。 ``` # Use the disposable repository URL advertised by your forge: git clone ssh://git@git.example.com:2222/team/check.git # In a clone, inspect which remote is configured: git remote -v ``` ## リポジトリだけでなくディスカッションも復元する アプリケーション/データベース、リポジトリのストレージ、添付ファイル、LFSデータ、設定、必要な暗号化シークレットを一貫してバックアップしてください。インストール済みのforgeバージョンのバックアップ手順に従ってください。GiteaのバックアップコマンドがすべてのForgejoリリースと自動的に互換性があるわけではありません。分離環境で再構築し、イシュー、添付ファイル、ログイン、クローンを検証してください。移行後にプッシュが失敗する場合は、リポジトリの権限を全体で変更する前に、SSH のホスト/ポート、キーマッピング、ストレージ権限、公開されているクローン用 URL を確認してください。 公式ドキュメント: [Giteaのバックアップと復元](https://docs.gitea.com/administration/backup-and-restore/) さらに探す ## 続きを読む。 [ユースケース ### メンテナンス計画付きのセルフホスティング。 サーバーはツールをポータブルでカスタマイズ可能にします。その利点は、更新、バックアップ、復旧が設計に組み込まれている場合に持続します。…](https://koalavps.com/ja/self-hosting/)[ガイド ### バックアップは復元できてこそ意味があります。 再現できないデータと、サービスが失って許容できる時間を基準にバックアップを設計してください。アップロードの成功は始まりにすぎません。…](https://koalavps.com/ja/backups/)[ガイド ### マシンを自分のものに保ちましょう。 セキュリティは継続的なルーティンです。露出する範囲を減らし、権限を制限し、計画的にパッチを適用し、復旧を可能にしてください。…](https://koalavps.com/ja/server-security/) インフラストラクチャを構成する ## 主導権を握る。 自分の条件でデプロイ。 身元書類は不要。完全な管理者アクセス。暗号資産ネイティブの請求。 [構成を選択してください](https://koalavps.com/ja/vps/)