現在の定価では、GitHub Team、Vercel Pro、Sentry Team、Linear Basic、Notion Plus を使う3人チームは、1Password や従量課金、アドオンを除いて月額およそ158ドルから始まります。範囲を丁寧に絞ったセルフホスト型スタックならこの請求額を大きく減らせますが、公平な比較には4GBという実験用の下限より大きなVPSと、誰もが忘れる保守の時間が含まれます。
このガイドは、「SaaSの請求が煩わしい」「非公開のコードや開発ワークフローを第三者のインフラに置くのは落ち着かない」とすでに結論づけ、では具体的に何を動かせばよいのかを知りたい開発者や小規模チームに向けたものです。スタックはコード、ビルドとデプロイ、実行、ドキュメントの4層で構成されます。各層について推奨ツール1つ、代替案1つ、リソースコスト、そして失敗の形を示します。対象範囲は1台のVPS上での個人およびチーム利用です。メールホスティング、DNS、顧客向け認証、Kubernetesは範囲外とし、その理由はふさわしい箇所で述べます。
短いバージョン
箇条書きだけ読む場合:
- コード: 既定はForgejoです。git、CI/CD、レジストリ、イシューを1つの製品にまとめたい場合にのみGitLab CEを使ってください。GitLabの現在の単一ノードの基準は16GBのRAMで、8GBはメモリに制約のある環境向けに用意された値です。
- ビルドとデプロイ: Coolify on the current stable release (v4.3.0 at QC time), with the dashboard kept off the public internet. Dokku suits solo developers; pure Docker Compose suits teams that prefer visible moving parts.
- 実行します: 共有の認証情報にはVaultwarden、監視にはUptime Kuma、エラー追跡にはGlitchTip、コンテナ管理にはPortainerかDockgeを使います。GlitchTipは、公式の最小要件が16GBのRAMと16GBのスワップであるセルフホスト版Sentryに比べ、はるかに小さな構成です。
- ドキュメント: ドキュメントにはDocmost、イシュー管理にはOpenProject（またはPlane）。AFFiNEはキャンバス型のNotionモデルを好むチームに向きます。
- サイジング： 4GBは軽量なサービスをいくつか動かす実験用のサイズ、8GBはOpenProjectとPlane、ローカルビルドを外した縮小版パイロット、16GBは本ガイドのForgejoベースの完全なスタックの現実的な出発点と考えてください。GitLabの8 vCPU・16GBという基準はGitLab自体に対するものなので、GitLabベースの1台構成スタックには追加の容量か個別の負荷試験が必要です。
- 弱いところ: 外部のコントリビューターに支えられた公開のオープンソースプロジェクトです。GitHubのネットワーク効果は本物で、セルフホストは見つけてもらいやすさを犠牲にします。
前提条件
読み進める前に、本ガイドは次を前提としています:
- DockerとDocker Composeを導入したLinuxのVPS。Forgejoベースの完全なスタックにはおよそ16GBのRAMを見込んでください。重めのプロジェクト管理ツールとローカルビルドを外した縮小版パイロットなら8GBで足ります。
- 初回デプロイでは各層に30分から60分の手間。
- Composeファイルを読み、環境変数を調整できること。
- 定期的な更新の時間枠を守り、セキュリティ修正を速やかに適用し、バックアップを設定するだけでなく検証する意思。
このうちどれかが譲れない条件なら、SaaSのセットこそがあなたのチームにとって正しい答えです。それは筋の通った判断であり、敗北ではありません。
root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。
Linuxプランを見るレイヤー1 コード: Forgejo、Gitea、GitLab CE
実用に足る選択肢が3つ、リソースとガバナンスの曲線上で3つの異なる位置にあります。2026年にセルフホストを始める人への推奨は まずForgejo.
Forgejoは控えめなインフラ向けに設計されており、プルリクエスト、イシュー管理、プロジェクトボード、Wiki、パッケージレジストリ、Forgejo Actionsを備えます。ワークフローはGitHub Actions風の形式ですが互換性は完全ではないため、パイプラインが依存するサードパーティ製アクションはすべて検証してください。
Giteaを選ぶのは、すでにGitea固有の機能に依存している場合か、ツール類を特定のGiteaバージョンに固定している場合だけにしてください。コードベース自体に問題はありません。Forgejoの 公式の比較 によれば、このフォークは2022年10月にGiteaのドメインと商標がコミュニティの同意なく営利企業へ移管されたことを受けたものです。Forgejoの ライセンス告知 では、v9.0以降のバージョンについてGPL v3+が記録されています。
git、CI/CD、コンテナレジストリ、イシュー管理を1つの製品でまかないたく、その最低リソースを負担できるなら、GitLab CEを選んでください。 GitLabの現在の要件 は単一ノードの基準として16GBのRAMと8 vCPUを定めており、8GBはメモリに制約のある環境向けです。Giteaは小規模な非公開インスタンスならおよそ1〜2GBのRAMで動くほど軽く、Forgejoも同程度ですが、どちらも本番のサイジングはリポジトリ数、ランナー、同時利用者数に左右されます。
| ツール | 開始時のリソース | ガバナンス | ライセンス | 内蔵のCI/CD | 選ぶべき場面 |
|---|---|---|---|---|---|
| Forgejo | 1〜2 vCPU / 1〜2GB RAM（軽負荷での目安） | コミュニティ主導（Codeberg e.V.） | GPL v3+ (v9.0+) | Forgejo Actions、互換性は要検証 | 2026年にセルフホストを始める人の既定の選択 |
| Gitea | 1〜2 vCPU / 1〜2GB RAM（軽負荷での目安） | 営利企業（Gitea Ltd、2022年10月以降） | MIT | Gitea Actions、互換性は要検証 | 既存のGitea依存、または特定バージョンに固定されたツール |
| GitLab CE | 8 vCPU / 16 GB RAM baseline; 8 GB constrained | GitLab Inc | MIT（Community Edition） | ネイティブで多機能 | git、CI/CD、レジストリ、イシューを1つの基盤にまとめたく、RAMにも余裕がある場合 |
CIの話は指摘しておく価値があります。Gitea ActionsはGitHub Actionsとおおむね互換になるよう設計されている一方、Forgejo Actionsは完全な互換性ではなく親しみやすさを意図的に狙っています。多くのワークフローは小さな修正で済みますが、ランナーのイメージ、権限、コンテキスト、ラベル、サードパーティ製アクションは挙動が異なることがあります。移行前に、パイプラインが依存するワークフローとアクションをすべて検証してください。
3つの選択肢すべてに共通する留保が1つあります。本ガイドは、管理画面をVPNやIP許可リストの内側に置いた、非公開かつチームでの利用を前提にしています。公開のgitサービスは、小規模な非公開構成では起きないボットのトラフィック、悪用、見つけてもらいやすさとのトレードオフに直面します。公開のオープンソースなら、可視性のためにGitHubへミラーしつつ、そのガバナンスモデルが重要ならForgejoを正本として保ってください。
サーバーはプロバイダーのプラン名ではなく、ワークロードから見積もってください。軽い個人利用のForgejoやGitea単体のサービスなら、およそ1〜2 vCPUと1〜2GBのRAMから始められます。OpenProject、Plane、ローカルビルドを外した縮小スタックは、およそ4 vCPUと8GBのRAMから始められます。ここで説明したForgejoベースの完全なスタックは、およそ8 vCPUと16GBのRAMから始め、その後に実際のCIとアプリケーションの負荷で検証してください。GitLab公式の8 vCPU・16GBという基準はGitLab自体に対するものなので、GitLabに本スタックの残りを足した分に足りると考えないでください。SSDまたはNVMeのストレージを使い、リポジトリ、コンテナイメージ、ログ、データベース、バックアップの容量は別枠で見積もり、更新や負荷の急増に備えて容量の20〜30%を空けておいてください。
このセクションの要点： 2026年のコード層の既定の推奨はForgejoです。Giteaも堅実さを保っており、GitLab CEは16GBという基準を負担できる場合か、8GBの制約構成で動かすと承知している場合にのみ統合型の選択肢になります。
レイヤー2 ビルドとデプロイ: Coolify（留保付き）、Dokku、または素のDocker Compose
率直に言えば、最新の本番リリースを動かし、管理ダッシュボードを公開インターネットから遮断し、セキュリティ勧告を追っているなら、Coolifyがこのスタックで推奨できるPaaSです。QC時点で、GitHubは Coolify v4.3.0 Coolify v4.1.2 を最新版として表示しています。パッチ適用と管理プレーンの隔離は、任意の強化策ではなく運用上の要件と考えてください。
プロのヒント： CoolifyのダッシュボードとAPIを、ファイアウォール、VPN、または信頼できるアクセスプロキシで制限してください。デプロイ済みのアプリケーションは引き続き公開トラフィックを受け取れます。狙いは、管理用コントロールプレーンの露出を減らすことです。
一人で開発する人向けの代替はDokkuです。Heroku風のgit pushによるデプロイとbuildpackに対応した、こぢんまりとしたPaaSです。Coolifyより表面積が小さく、機能もその分少なめです。そのため、ダッシュボードを必要としない1〜2人の開発者にとっては、筋の通った「退屈な選択」になります。
経験を積んだ運用者が選ぶ第三の選択肢は PaaSを一切使わず、Docker Composeだけ。チームがすでにComposeファイルを書いていて、動く部品が見えているほうがよいなら、これはまったく理にかなった答えです。docker compose restart の代わりにクリック一つで再起動したくなったら、スタック管理のUI層としてDockgeやPortainerを足してください。トレードオフは運用面にあります。プレビュー環境はなく、TLSの自動化も組み込まれておらず、無停止デプロイも手間なしでは得られません。これらはスクリプトを書いて手に入れるものです。Coolifyなら最初から用意されていますが、付随するセキュリティの履歴も一緒についてきます。
Cloudzyによる最良のCI/CDツール案内 は、専用のランナーを必要とするチーム向けにビルドのパイプラインをより深く扱っています。Forgejo ActionsやGitLabのCI/CDが整えば、小規模チームの多くには専用ランナーは不要です。
このセクションの要点： Coolifyが推奨できるPaaSなのは、現在の安定リリースで、かつ管理プレーンを制限している場合に限られます。Dokkuは一人で進めるときの手堅い選択、素のDocker Composeは依然として筋の通る第三の選択肢です。
レイヤー3 実行: Vaultwarden、Uptime Kuma、GlitchTip、そしてコンテナ管理
このスタックで最も落差の大きいリソースの差は、ここにあります。 セルフホスト版Sentryの公式要件 は最小要件として、CPU4コア、16GBのRAM、16GBのスワップ、20GBの空きディスクを挙げ、32GBのRAMを推奨しています。 GlitchTipのインストール手引き は512MBのRAMを推奨し、PostgreSQLを必須とし、Valkeyは任意としています。1台のVPSで動かす小規模チームには、GlitchTipが現実的な既定の選択です。
| ツール | RAM（目安） | コンテナ数 | APIの互換性 |
|---|---|---|---|
| セルフホスト版Sentry | 16 GB RAM plus 16 GB swap minimum; 32 GB recommended | 多数のサービスからなる大規模構成 | ネイティブ |
| GlitchTip | 512 MB recommended; 256 MB minimum for the all-in-one setup | 中核サービス2つ、Valkeyは任意 | Sentry SDKのトラフィック、機能の同等性は要検証 |
この層に残る4つのツールは、どれも短い話で済みます。
Vaultwardenは、Bitwardenのモバイルアプリやブラウザー拡張、チーム共有に対応した、Bitwarden互換のパスワード管理ツールです。実際の使用量は、利用者数、添付ファイル、データベースの選択によって変わります。 Cloudzyによるセルフホスト型パスワード管理ツールの比較 は、より構造化された権限、監査のための制御、あるいは別のセキュリティモデルが必要になったときの、より深いトレードオフを扱っています。
Uptime Kumaは小ぶりな監視・通知ツールです。HTTP、TCP、ping、push、証明書の有効期限チェックに対応し、ステータスページも任意で用意できます。通知はチャット、メール、Webhook経由で送れます。リソース消費は監視項目の数と保持期間で変わり、2回続けて失敗したときに通知する設定は、短いばたつきを抑える現実的な方法です。
GlitchTipはエラー追跡ツールです。多くのSentry SDK連携はGlitchTipのDSNへ送信できますが、機能の同等性は完全ではありません。パフォーマンス監視、ソースマップ、アラート、そしてチームが重要視している連携は必ず検証してください。
コンテナのUIにはPortainerかDockgeを選びます。Portainerはコンテナ管理のより広い用途をカバーし、DockgeはDocker Composeに絞っています。Composeだけの小さなスタックなら、Dockgeのほうがすっきり収まります。より広い範囲が必要になったときだけPortainerへ移りましょう。
この層で効いてくるComposeの作法: ツールごとに専用のサブディレクトリと専用のcompose.ymlを持たせ、ツール間の通信が必要な箇所でのみDockerネットワークを共有し、前段にリバースプロキシを1つ置いてTLSを終端させます。
# /opt/stack/glitchtip/compose.yml (excerpt)
services:
web:
image: "glitchtip/glitchtip:${GLITCHTIP_VERSION:?Set GLITCHTIP_VERSION in .env}"
environment:
DATABASE_URL: "${DATABASE_URL:?Set DATABASE_URL in .env}"
SECRET_KEY: "${GLITCHTIP_SECRET_KEY:?Set GLITCHTIP_SECRET_KEY in .env}"
GLITCHTIP_DOMAIN: "https://errors.example.com"
DEFAULT_FROM_EMAIL: "[email protected]"
ports:
- "127.0.0.1:8000:8000"プロのヒント： バックアップは、サービスを復元してデータを検証できて初めて証明されます。月に一度、代表的なサービスを1つ隔離したテスト環境へ復元し、起動して、ログインし、レコードと添付ファイルを確認し、アプリケーションが正常に動くことを確かめてください。復元したファイルを一覧するだけでは、アーカイブが読めることしか証明できず、データベース、ボリューム、権限、アプリケーションの状態まで復旧できる証明にはなりません。
このセクションの要点： GlitchTipは、セルフホスト版Sentryよりはるかに小さな構成でエラー追跡の中核をこなします。ただし、チームが実際に使っているSentryの機能と連携は必ず検証してください。
レイヤー4 ドキュメント: Docmost、AFFiNE、そしてOpenProjectまたはPlaneによるイシュー管理
Notionのインターフェースは申し分ありません。ただし、Wikiが育つとナビゲーションと検索が重く感じられるようになります。小規模チームに勧める分担は、ドキュメントとWikiにDocmost、イシュー管理にOpenProjectです。チームがLinear風のビジュアルモデルを明確に求めていて、そのサポート対象のセルフホスト構成を運用できるなら、OpenProjectをPlaneに置き換えてください。
Docmostは、NotionのふりをせずにセルフホストでもっともNotionに近い代替になります。ブロックエディター、ページ階層、チームの権限は、ごく普通の社内Wikiに合います。この層のサイジングは、同時編集者数、添付ファイル、そしてPostgreSQLとRedisを同じホストに置くかどうかで決めてください。AFFiNEは、入れ子のページよりキャンバスとホワイトボードのモデルを好むチーム向けの代替です。どちらも筋が通っています。ひとつ選んでください。
OpenProjectは、Jira風のワークフローが性に合うチームのイシュー管理をまかないます。エピック、ワークパッケージ、スプリント、工数記録まで揃っています。PlaneはLinear型の代替で、イシュー中心のより軽快なインターフェースと、異なる運用上の負担を持ちます。
正直に認めましょう。Linearのキーボード優先の速さは本当に良く、Planeはすべての操作を再現しているわけではありません。チームのワークフローがLinearのコマンドメニューの身体感覚の上に成り立っているなら、移行時の摩擦は本物です。必ずしも致命的ではありませんが、確かなコストです。
このセクションの要点： Docmostが社内ドキュメントの役割を担い、イシュー管理はOpenProjectかPlaneが受け持ちます。Linearとのキーボード操作性の差が、この層で唯一妥協を求められる箇所です。
このスタックの費用と、動かす土台
Forgejoベースの完全なスタックを1台に収める場合、現実的な出発点はおよそ8 vCPUと16GBのRAMです。2 vCPUと4GBのRAMは軽量なサービスをいくつか動かす実験用のサイズ、4 vCPUと8GBのRAMはOpenProject、Plane、ローカルビルドを外した縮小版パイロットと考えてください。実際に必要な量は、同時利用者数、CIの稼働量、データベースの増加、添付ファイル、イメージの保管、ログ、保持期間によって変わるため、本物の負荷でスタックを検証し、容量の20〜30%を空けておいてください。16GBという開始段階は、負荷試験を前提に、負荷の軽い2〜3人の開発チーム向けとして次のサービスを収容できます:
- Forgejo
- Coolify
- Vaultwarden
- Uptime Kuma
- GlitchTip
- Docmost
- OpenProject
- Dockge
4GBのサーバーは軽量なサービスをいくつか動かす程度にしか向きません。8GBのサーバーは、OpenProject、Plane、ローカルビルドを外した縮小版パイロットと捉えるほうが妥当です。Forgejoベースの完全なスタックは16GBから始め、GitLab、同時ビルド、Plane、長い保持期間、より重いデータベース負荷が加わったら容量を足してください。同じチームのSaaSのセットには次が含まれます:
- GitHub Team
- Vercel Pro
- Sentry
- Linear
- Notion
- 1Password
各料金ページに掲載された基本料金に基づいています（該当する場合は年額請求の料金を含む）。有料の5製品を合計すると、3人で月におよそ158ドルです: GitHub Team は最初の12か月間ユーザーあたり4ドル、 Vercel Pro の開発者シート3席が各20ドル、 Sentry Team は26ドルから、 Linear Basic はユーザーあたり10ドル、そして Notion Plus はユーザーあたり10ドルです。従量課金、税金、アドオン、1Passwordは別途かかります。インフラのほうが目に見えて安く済むこともありますが、運用する人の時間を勘定に入れない比較には意味がありません。
増強を考えるとき: GitLabの単一ノードの基準は8 vCPUと16GBのRAMです。GitLabがなくても、ビルドを同時に複数走らせれば追加の容量が要ることがあります。セルフホスト版Sentryも16GBのRAMと16GBのスワップから始まり、32GBを推奨しています。本ガイドが1台構成のスタックにGlitchTipを勧めるのは、そのためです。
値札のつかないコストは運用の時間です。計画上の目安として、更新とバックアップ検証に月1〜2時間、加えて運用しているプロジェクトのセキュリティ勧告に毎週さっと目を通す時間を見込んでください。実際の数字は、変更の量、障害対応、どこまで自動化しているかで変わります。ゼロではありませんし、コストの見積もりに入れるべきものです。
デプロイの方法が変えるのは手軽さであって、運用上の要件ではありません。公式のComposeファイルを使うにせよ、マーケットプレイスのテンプレートを使うにせよ、イメージのバージョンを固定し、CPUとメモリの上限を設定し、サービスのデータは名前付きボリュームに置き、バックアップと復元の両方を検証してください。スタック全体を1台のホストにまとめると障害の影響範囲も共有されるため、停止や認証情報の流出の影響が大きい重要なサービスは切り離してください。
このスタックをデプロイしたいなら、当社の Cloud VPS のプランを、CPU、RAM、SSDまたはNVMeのストレージ、転送量、リージョンで比較し、上のサイジングの考え方を当てはめてください。手早く立ち上げたいなら、当社の ワンクリックアプリカタログ。ただし、それでもバージョンを固定し、リソースの上限を設定し、本番前にバックアップを検証してください。
このセクションの要点： 小さな実験には4GB、縮小版パイロットには8GB、Forgejoベースの完全なスタックの現実的な出発点にはおよそ8 vCPUと16GBのRAMを充ててください。GitLab、同時ビルド、重めのプロジェクト管理ツール、育っていくデータベースのために容量を足していきます。
このスタックのセルフホストが本当に破綻するところ
4つの失敗の形を、はっきり名指しします。本ガイドの他の部分は、このやり方を推す主張だったのですから。
失敗の形1: 公開オープンソースプロジェクトにおけるGitHubのネットワーク効果。 セルフホストのgitは、非公開のコードには正しい選択です。外部のコントリビューターに見つけてもらうことに価値のすべてがかかっているプロジェクトには、間違った選択です。開発者が最初に見にいく場所はGitHubです。プルリクエスト、フォーク、スター、github.com にあることが暗に伝える信頼のしるし、サードパーティ製ツールとの連携、そのすべてが。プロジェクトが公開のオープンソースなら、誠実なやり方は、可視性のためにGitHubへミラーし、正本はForgejoに置くことです。公開の仕事において、セルフホストのインスタンスがGitHubの見つけてもらいやすさの代わりになると期待してはいけません。代わりにはなりません。
失敗の形2: 公開Gitインスタンスに来るボットとスクレイパーのトラフィック。 一般公開されたForgejoやGiteaのサービスには、不正利用への対策、レート制限、監視、そして予測できないトラフィックをさばける容量が要ります。本ガイドは、管理画面をVPNやIP許可リストの内側に置いた、非公開かつチームでの利用を前提にしています。本当に公開されたフォージは、脅威モデルも容量の考え方も別物です。
失敗の形3: 保守の負担。 「あなたが情シスです」というのは使い古された言い回しですが、おおむね本当です。更新は何かを壊します。Composeファイルはじわじわずれていきます。証明書は失効します。バックアップは、もっとも情けないかたちで黙って失敗します。Coolifyの2026年の勧告は、パッチの頻度が大事だと思い出させてくれる好例です。始める前に保守の時間枠を約束できないなら、正直なところSaaSのセットが正しい答えです。
失敗の形4: 連携の喪失。 サードパーティ製のGitHub Actions、GitHubのプルリクエストに紐づくVercelのプレビューデプロイ、SentryのホスティングされたPagerDutyやLinearとのアラート連携、Notionの幅広い連携カタログ。多くにはセルフホストの相当物があります（Forgejo Actions、CoolifyのWebhookデプロイ、GlitchTipの通知、ワークフローをつなぐn8n）。ただし置き換えが常に1対1とは限りません。チームを移行に踏み切らせる前に、いちばん大事なワークフローを試作してみてください。当たり前だと思っている連携こそ、いちばん驚かせてくる相手です。
このセクションの要点： このスタックは、非公開のコード、小さなチーム、手を動かす気のある運用者には効きます。公開オープンソースの可視性、何も触りたくないチーム、保守ゼロという期待には効きません。
運用者のスタック
4つの層、4つの推奨を、率直に挙げます。コード: Forgejo。ビルドとデプロイ: 管理プレーンを制限したCoolify、あるいはDokku、あるいはCompose。実行: Vaultwarden、Uptime Kuma、GlitchTip、PortainerまたはDockge。ドキュメント: DocmostとOpenProject（またはPlane）。縮小版パイロットは8GB、Forgejoベースの完全なスタックは16GBから始めてください。GitLab、同時ビルド、重めのデータベース、継続的なアプリケーション負荷には容量を足していきます。
移行するなら、Uptime Kumaと重要度の低い社内サービスから始めてください。チームのワークフローや認証情報の保管庫を動かす前に、運用のリズム（更新、監視、バックアップ検証、証明書の更新）を低いリスクで身につけられます。Vaultwardenを最初の試験導入にしてはいけません。ホスト外の暗号化バックアップ、成功した復元テスト、制限された管理権限、多要素認証がそろってから移してください。そのリズムが確かになったら、Forgejo、次にCoolify、そして残りへと進みましょう。
とりわけGitLab CEを選ぶチームは、内蔵のCI/CDが専用ランナーの代わりになるのか、それともワークロード上まだ専用のビルド能力が必要なのかを見極めてください。
よくある質問
2026年、Giteaに代わる最良のセルフホスト型の選択肢は？
2026年にセルフホストを始める人への推奨はForgejoです。2022年10月、Giteaの商標とドメインがコミュニティの事前の同意なく営利企業へ移管されたことが、2022年末のForgejoのフォークを招きました。v9.0以降、ForgejoのリリースはGPL v3+を採用し、それ以前のv8.0とv7.0のパッチリリースはMITのままです。日々の機能面では、両者はほぼ肩を並べています。
2026年、Coolifyを本番環境で安全に運用できますか？
できます。ただし、能動的な保守と多層防御があってこそです。レビュー済みの最新安定リリースを動かし、新しい勧告を追い、チームの権限を絞り、ダッシュボードとAPIはファイアウォール、VPN、または信頼できるアクセス層の内側に置いてください。beta.451やbeta.474、その他いかなる過去のパッチ水準も、恒久的に安全な線だと考えてはいけません。
セルフホスト型の開発者スタックを丸ごと動かすには、実際どれだけのRAMが要るのか？
2〜3人の開発チームなら、4GBは軽量なサービスをいくつか動かす実験用のサイズ、8GBはOpenProjectとPlane、ローカルビルドを外した縮小版パイロットと考えてください。Forgejoベースの完全なスタックの現実的な出発点は、およそ8 vCPUと16GBのRAMです。GitLabの8 vCPU・16GBという基準はGitLab自体に対するもので、セルフホスト版Sentryは16GBのRAMと16GBのスワップを要求し、32GBを推奨します。最終的な構成は、実際のワークロード条件で検証してください。
なぜセルフホスト版SentryではなくGlitchTipなのか？
リソースと運用の落差です。セルフホスト版Sentryは最低でも16GBのRAMと16GBのスワップを要し、多数のサービスからなる大規模な構成になります。GlitchTipはオールインワンのサービスに512MBを推奨し、PostgreSQLを必須とし、Valkeyは任意としています。Sentry SDKのトラフィックは受け取れますが、機能の同等性は完全ではないため、依存している機能と連携は検証してください。
SaaSの相当品と比べて、このスタックは実際いくらかかるのか？
4GBは軽量なサービスをいくつか動かす実験用のサイズ、8GBはOpenProjectとPlane、ローカルビルドを外した縮小版パイロットと考えてください。Forgejoベースの完全なスタックの現実的な出発点は、およそ8 vCPUと16GBのRAMです。公開されている基本価格では、GitHub Team、Vercel Pro、Sentry Team、Linear Basic、Notion Plusを合わせて3人で月におよそ158ドルとなり、これには1Password、従量課金、税金、アドオンは含まれません。セルフホストのほうが目に見えて安く済むことはありますが、運用する人の時間とバックアップの基盤は、まぎれもない実費です。
