# Depot vs Namespace: Dockerキャッシュ vs ビルドプラットフォーム

> 2026年のGitHub Actions向けDepot vs Namespace: Depotはリモートキャッシュによる高速なDockerビルドに特化し、Namespaceはrunnerとより広いビルドインフラを提供します。選び方。

Source: https://latchkey.dev/ja/learn/compare-runners/depot-vs-namespace  
Updated: 2026-07-02

DepotはDockerビルドの高速化を深く掘り下げ、Namespaceはビルドインフラを広くカバーします。あなたのDocker負荷とプラットフォームの野心が決め手です。

Depotは、リモートのBuildKitキャッシュと高速なビルダーでコンテナイメージのビルドを高速化することで知られています。Namespaceは高速runnerに加え、より広いリモートのビルドおよび開発インフラで知られています。これは深さと広さの比較であり、コストと自己修復についての率直な注記を伴います。各ベンダーのサイトで現在の価格と機能を確認してください。

## Comparison

|  | Depot | Namespace |
| --- | --- | --- |
| 知られている点 | 高速なDockerビルド + リモートキャッシュ | 高速runner + ビルドインフラ |
| 深さ vs 広さ | コンテナビルドに深い | 広いビルドプラットフォーム |
| 最適な場面 | DockerビルドがCIを支配する | 統合されたビルドプラットフォームが欲しい |
| 不安定なジョブの自己修復 | なし | なし |

## こんなときDepot

コンテナイメージのビルドがパイプラインを支配し、リモートのビルドキャッシュがボトルネックである場合です。Depotはこの分野の専業であり、Docker中心のCIには説得力があります。

## こんなときNamespace

単一目的のDockerアクセラレータではなく、高速runnerに加えプロジェクト横断で標準化できるキャッシュやインフラを備えた、より広いビルドプラットフォームが欲しい場合です。

## コストと信頼性が先行するなら

どちらも速度とビルドインフラに注力し、不安定な失敗からの回復には注力しません。本当の痛みが高い請求と赤いビルドの再実行なら、LatchkeyはGitHubホストよりおよそ70%低い料金のマネージドrunner上で自己修復を加えます。自分のDocker負荷とプラットフォーム計画に合う方と並べて検討してください。

## How to evaluate a managed runner honestly

Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.

- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.

> Switching between managed runners is a one-line `runs-on` change in both directions, so a two-week trial on your slowest job costs almost nothing and beats any amount of modelling.

## 結論

Dockerビルドが支配的なCI: Depot。より広いビルドプラットフォーム: Namespace。コストと不安定な再実行が最重要なら、Latchkeyの自己修復も評価してください。まずワークロードに合わせ、それから現在の価格を確認してください。

## FAQ

### Depot vs Namespace: Docker Caching vs Build Platform?

Depot is known for accelerating container image builds with a remote BuildKit cache and fast builders. Namespace is known for fast runners plus broader remote build and development infrastructure. This is a depth-versus-breadth comparison, with an honest note on cost and self-healing.

### Pick Depot if?

Container image builds dominate your pipeline and remote build caching is the bottleneck. Depot is a specialist here and is compelling for Docker-heavy CI.

### Pick Namespace if?

You want a broader build platform, with fast runners plus caching and infrastructure you can standardize across projects, rather than a single-purpose Docker accelerator.

### If cost and reliability lead?

Both focus on speed and build infrastructure, not on recovering from flaky failures. If your real pain is a high bill plus re-running red builds, Latchkey adds self-healing on managed runners priced at $0.0025/min for 2 vCPU against $0.006 GitHub-hosted. Consider it alongside whichever of these fits your Docker load and platform plans.

### Which should I choose?

Docker-build-dominated CI: Depot. Broader build platform: Namespace. If cost and flaky re-runs matter most, evaluate Latchkey self-healing as well. Match to your workload first, then verify current pricing.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt