Stop Running Docker Desktop: Offload Your Builds to a VPS Instead

アクティビティモニタまたはタスクマネージャーを開き、小さなコンテナを起動しても、Docker Desktopは依然としてマシン上で最もうるさい存在になり得ます。 2026年2月のDocker Desktopのissueでは、あるユーザーが、 com.docker.backend.exe コンテナ起動後にCPUが100%まで上昇し、コンテナを停止した後も続いたと報告しました。

別の一手があります。デーモンをラップトップから完全に外すのです。ローカルにはDocker CLIだけを残し、Docker EngineをLinux VPS上で動かし、 docker context をSSH経由でそこへ向けます。あなたの docker build コマンドは変わりません。ビルドは単に別の場所で、VM層のないネイティブLinux上で実行され、VPSの帯域がカフェのWi-Fiの代わりにベースイメージを引き、追跡すべきDocker Desktopのライセンスもありません。

これがその道筋の完全なセットアップです。前提条件、正確な docker context コマンド、リモートのbuildxドライバーによるマルチアーキビルド、マシンのサイズの決め方、そしてリモートのアプローチが誤った選択となる場面です。

要約

• 問題： Docker DesktopはローカルのVMを引きずり、ファイルI/Oを仮想化層に通し、 有料サブスクリプションを必要とします より大きな組織での業務利用には。これにはDockerの無料枠の上限を超える企業も含まれます。
• 解決策： Docker Desktopを削除します。Docker EngineをLinux VPS上で動かし、SSH経由でそれを指す docker context を作成すれば、ローカルの docker build はVPS上で実行され、あなたのCLIはただ指揮するだけになります。
• コストの枠組み： 控えめなVPS1台が、席ごとのライセンスを置き換え、ネイティブLinuxのビルド速度を与えます。チーム全員が、開発者ごとに支払う代わりに、単一のビルドボックスを共有できます。
• 正直な注意点： VPSは到達可能でなければならず（飛行機の中ではビルドできません）、実行のたびに数ギガバイトのビルドコンテキストをアップロードしないための .dockerignore の規律が必要です。

前提条件：必要になるもの

最初のコマンドの前に、これらを揃えてください。すでにDockerを日常的に使っているなら、ここに目新しいものは何もありません。

• A Linux VPS root権限またはsudo付き。Ubuntu 22.04/24.04またはDebian 12/13はいずれも問題なく動きます。
• VPS上のDocker Engine。 docker context はSSH経由でリモートホスト上にDocker Engine 18.09以降を必要とします。Dockerの contextドキュメントに従って。.
• ローカルにDocker CLI 19.03以降。 それが、トップレベルの context コマンドを理解するクライアントです。
• An SSHの鍵ペア。 鍵ベースの認証のみ： パスワード認証はサポートされていません には、 docker context SSH接続。
• リモートの dockerグループ内のリモートユーザー docker グループ。これにより、呼び出しのたびにsudoなしでデーモンのソケットと会話できます。

Docker Desktopが実際にあなたに払わせているもの

コストは謎ではありません。3か所に着地し、探してここに辿り着いた人は、そのうち少なくとも1つを感じています。それらを正確に名指しすることが要点です。痛みはもうご存じです。

メモリとVMのオーバーヘッド。 Docker Desktopは依然としてローカルのLinux VMを意味します。 Dockerの設定ドキュメント は、Docker DesktopがDocker DesktopのVMの使うメモリ量を制限できると述べています。これが問題の静かな部分です。ループの中には依然としてVMがあるのです。正確なフットプリントはOSとプロジェクトによって変わりますが、故障モードは現実です。 Docker for Windowsのissue は、Docker Desktopがコンテナを1つも実行していない状態で何ギガバイトものRAMを消費すると報告し、 WSL2のissue は、コンテナ終了後にメモリを解放しないままにするDockerのビルドを記述しています。要点は、どのマシンも同じ数字でアイドリングするということではありません。要点は、Docker DesktopがローカルのVMのオーバーヘッドをあなたの開発ループの中に留めておくということです。

ビルドとファイルI/Oの速度。 VMの境界を越えるバインドマウントやファイル操作は、ネイティブなLinuxファイルシステムへのアクセスより遅いです。 Dockerの既知の問題のドキュメント は、仮想化ファイルシステムのコストを認めています。コミュニティのベンチマークは、VM層を通すバインドマウントについて、およそ3-10x遅いという程度のものを日常的に報告します。その2つ目の数字はコミュニティの経験であって、Dockerが公表したベンチマークではありませんが、その方向は、Mac上でビルドが這うのを見たことのある誰も異論を唱えません。

ライセンス。 2021年の変更以降、Docker Desktopは、従業員250人超または売上1,000万ドル超の企業に有料サブスクリプションを要求します。 Dockerの料金ページ の現在の階層は、Personal（$0）、Pro（$11/mo または年額$9）、Team（$16/mo または年額$15）、Business（$24/mo）です。Team階層は2024年12月に年額$9から$15へ上がりました。静かな費目を調達の会話に変える跳ね上がりで、30席に掛け合わせるときに本当に痛むのがこの部分です。

代替手段と、ローカル対リモートの分岐

見つかるほぼすべてのDocker Desktopの代替は、1つのローカルデーモンを別のローカルデーモンに交換します。それが気づくべき本当の軸です。ほとんどの人が思い悩む選択はローカルのツール同士ですが、より興味深い分岐はローカル対リモートです。VMをあなたのマシンから取り除くのは、リモートの道だけです。

これが、その状況を並べたものです。

このうちいくつかは、一文の正直さに値します。

• OrbStack は、単独の開発者にとってMacのリソース問題を本当に解決します。アイドル時~300 MBと最大10x速いコンテナ起動を主張していますが（OrbStackのサイト）、どちらもベンダーの数字で、独立したベンチマークではありません。リモートインフラを管理したくないMac専用の開発者なら、OrbStackの方が良い選択で、その商用階層$8/mo（OrbStackの料金）はDocker DesktopのTeam階層を下回ります。落とし穴：Mac専用であり、商用ライセンスは、あなたが逃れようとしていたまさにそのものを連れ戻します。
• Colima は無料でCLIファーストですが、その「直接の置き換えではない」という粗さはよく記録されており、一部のチームは移行が行き詰まった後にDocker Desktopへ戻ります。
• Podman Desktop と Rancher Desktop はどちらも無料でクロスプラットフォームです。どちらも静かな置き換えではなく、PodmanのCompose互換性はそのDocker互換ソケットを通ります。
• Docker Offload はDocker自身のマネージドなリモートのビルド/実行サービスですが、Docker Desktopからのきれいな出口ではありません。現在のDockerのドキュメントは、それをDocker Desktop 4.68以降、Docker Businessのサブスクリプション、そしてDocker Offloadのサブスクリプションを必要とするものとして挙げています。ワークロードをDocker管理のクラウドホスト上で実行しますが、各ユーザーが一度に得られるのは1つのOffloadセッションで、アイドルセッションは5分の猶予後に終了し、環境は一時的なので、セッションが終わるとコンテナ、イメージ、ボリュームは消えます。Docker Desktopの中でマネージドなリモートの容量が欲しいなら、それでかまいません。自前のキャッシュ、ディスク、rootアクセスを持ち、Desktopへの依存のない永続的なVPSビルダーと同じではありません。

留まることが依然として合理的なケースが1つあります。無料枠のしきい値を下回り、ビルド速度の痛みがない個人には、何も変える理由がありません。それ以外の全員には、下すべき分岐があります。

このセクションの要点：重要な判断は、どのローカルツールを選ぶかではありません。そもそもラップトップにデーモンを置いておくかどうかです。

docker contextがSSH経由でどう動くか

リモートサーバー上でSSH経由でDockerイメージをビルドするには、そのサーバーでDocker Engineを動かし、 docker context create name --docker "host=ssh://user@host"でそれを指すdocker contextを作成し、次に docker context use nameを実行します。その後、通常の docker build はリモートホスト上で実行され、ローカルのCLIは指示を送るだけで、デーモンが作業を行います。

コンテキストは、Docker CLIのための名前付きで切り替え可能なターゲットです。毎回環境変数 DOCKER_HOST をあれこれ扱ったり、手作業でSSHトンネルを組んだりする代わりに、リモートを一度定義し、ディレクトリを変えるようにそこへ切り替えます。ビルドは全面的にリモートホスト上で実行されます。ベースイメージのプルはVPSのアップリンクを使い、レイヤーはVPSのディスクにキャッシュされ、CPU作業はVPSのコア上で起きます。レイテンシに敏感な唯一のステップは、最初のSSHハンドシェイクとビルドコンテキストのアップロードです。その後はすべてリモートです。

VPSのビルドボックスをセットアップする

セットアップ全体は、4つの短いコマンドとSSHの設定ブロックです。各ステップが決まったことを確認するのに役立つところで、期待される出力を示します。

ステップ1：Docker EngineをLinux VPSに載せる。 マシンをプロビジョニングしてDocker Engineをインストールします（リモート側の18.09+がcontext SSHの下限、ローカルのCLIは19.03+が必要）。インストールを自分で走らせたくなければ、すでにそれを同梱するVPSをデプロイします（詳しくは下記）。リモートユーザーはdockerグループに入っている必要があります：

sudo usermod -aG docker $USER

# log out and back in for the group change to take effect

ステップ2：SSH鍵認証と設定エイリアスをセットアップする。 鍵ベースの認証は必須です。IPと鍵のパスを打ち直さずに済むよう、ホストに短いエイリアスを ~/.ssh/config の中で付けます：

# ~/.ssh/config
Host my-vps
  HostName 1.2.3.4
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

ステップ3：コンテキストを作成する。 それをSSH経由でリモートデーモンに向けます。展開した形式を使います：

docker context create my-vps --docker "host=ssh://[email protected]"

あるいは、ステップ2のSSH設定エイリアスを使って：

docker context create my-vps --docker "host=ssh://my-vps"

ステップ4：検証する。 コンテキストを一覧表示し、リモートのエンジンが応答するか確認します：

docker context ls

NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
my-vps                                                ssh://my-vps

docker --context=my-vps version

それがリモートデーモンのサーバーバージョンを表示すれば、あなたのCLIはVPSと会話しています。

ステップ5：切り替えてビルドする。 VPSをアクティブなターゲットにし、いつも通りビルドします：

docker context use my-vps

docker build -t myapp .

そのビルドはVPS上で実行されます。グローバルに切り替えたくない場合は、単一のコマンドを狙います：

docker --context=my-vps build -t myapp .

あるいはシェルセッション用に設定します：

export DOCKER_CONTEXT=my-vps

ラップトップのローカルデーモンを取り戻したいとき（1つ残していれば）、家に切り替えます：

docker context use default

プロのヒント：自分の .dockerignoreに気をつけてください。ビルドコンテキストは、ビルドが始まる前にリモートホストへアップロードされます。迷い込んだ node_modules or .git のディレクトリがあると、実行のたびにギガバイト単位を回線に流すことになり、リモートの道はまったく理由もなくローカルより遅く感じられます。引き締まった .dockerignore こそが、リモートの道が速く感じられるかどうかに最も影響する1つのものです。依存関係、ビルド成果物、VCSのメタデータを除外すれば、アップロードは丸め誤差になります。

リモートのbuildxドライバーによるマルチアーキビルド

リモートのDockerホスト上でコンテナの中でBuildKitを走らせるbuildxビルダーを作成し、それに対してビルドします：

docker buildx create --name remote-builder \
  --driver docker-container \
  --use \
  ssh://ubuntu@your-vps-ip

docker buildx inspect --bootstrap

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64 \
  -t myapp:latest \
  --load .

リモートの --load フラグは、単一プラットフォームのローカル消費にとって重要です。 docker-container ドライバーでは、 ビルドされたイメージはローカルのイメージ一覧に自動では現れません。本当のマルチプラットフォームイメージをビルドしているなら、代わりにレジストリへプッシュします：

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/myapp:latest \
  --push .

その区別は重要です。単一プラットフォームのリモートビルドは、ローカルのイメージストアへ読み戻せます。 マルチプラットフォームイメージはたいていレジストリへプッシュされます。ターゲットアーキテクチャごとに別々のバリアントを持つマニフェストリストだからです。このセクションは任意です。すべてのイメージが単一アーキテクチャなら、上記のコンテキストのセットアップがすべての作業です。

ビルドボックスのサイズ決めと保護

2つの問いが、このボックスがあなたによく仕えるかを決めます。どれだけ大きくするか、そしてデーモンをどう締め付けておくかです。DockerのビルドはCPUバウンドなので、サイズ決めの論理はほぼコアと、スワップを避けるのに十分なRAMについてです。セキュリティの論理はほぼ、デーモンをあなた以外の誰にもさらさないことについてです。

どのサイズに設定するか

汎用的なスペックを与えます。プロバイダが提供するものに、それらをマッピングできます。

• 下限（開発者1人、軽いビルド）： 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• 私なら実際にデプロイするもの（ほとんどのチーム向け）： 4 vCPU / 8-12 GB RAM / 240-300 GB NVMe. Four vCPUs stop your parallel build steps from serializing, 8-12 GB handles concurrent builds without touching swap, and the NVMe headroom keeps a healthy layer cache.
• チームまたは重いCI： 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

ビルドはCPUバウンドなので、高周波（CPU最適化）のコアは、スワップのしきい値を超えた先の追加のRAMより、速いイテレーションをあなたに買います。イメージのビルドはGPUに触れないので、GPUプランはここでは無関係です。そしてデータセンターの選択は、SSHの応答性とコンテキストのアップロード時間にだけ影響し、ビルド速度には影響しません。ビルドはあなたがどこに座っていようとVPS上で実行されるので、きびきびしたハンドシェイクのために自分に近いロケーションを選び、先へ進んでください。

リモートデーモンの保護

上記のセットアップは、すでに正しいデフォルトを強制しています。SSH鍵認証、ネットワークにさらされたデーモンのポートはなし。それを保ってください。BuildKitやデーモンをSSHの外へ（生のTCPエンドポイント、開いたBuildKitのポートへ）さらした瞬間、あなたは標的になります。 Hacker Newsのスレッド は、リモートVPSのアイデアを最初に持ち出した遅いビルドについてのもので、さらされたBuildKitエンドポイントへのクリプトマイニング攻撃についても警告していました。オープンなインターネット上の未認証のビルドデーモンは、無料の計算ビュッフェです。

プロのヒント：デーモンをさらさないでください。SSHだけで十分なら（ほとんどの単一ボックスのセットアップには十分です）、 デーモンのTCPポートを決して開かないでください 。本当にTCPアクセスが必要なら、有効な証明書を持つクライアントだけが接続できるよう、その前に相互TLS（mTLS）を置いてください。SSHのみかmTLS：インターネットから到達可能なビルドボックスに、受け入れ可能な第3の選択肢はありません。

ボックスが立ち上がれば、それは汎用のLinuxサーバーで、その上で動かす価値のあるものは他にもたくさんあります。私たちの インディーハッカー向けセルフホストスタックのガイド は、VPS上で他に何が場所に値するかについての、妥当な次の読み物です。

Docker Engineのインストールを飛ばして直接 docker context createへ行きたければ、私たちの Dockerマーケットプレイスアプリ が、Docker Engine、Compose V2、buildxをすでに設定済みのVPSをデプロイします。ワンクリックでボックスはSSH対応になるので、上記のウォークスルーはステップ1ではなくステップ2から始まります。

よくある質問

リモートサーバーでDockerのビルドを実行し、ローカルのCLIを使えますか？

はい。リモートホストでDocker Engineを動かし、SSH経由でそれを指す docker context を作成し、そのコンテキストに切り替えます。すると、あなたのローカルの docker build はリモートサーバー上で実行され、あなたのマシンのCLIは指揮するだけで、ローカルのデーモンは不要です。

docker contextとDOCKER_HOSTの違いは何ですか？

A docker context は、名前付きで切り替え可能な永続的なターゲットで、一度定義して次で選びます： docker context use. DOCKER_HOST は、シェルごとに手作業で設定・解除する単一の環境変数です。コンテキストは、古い「トンネル＋環境変数」の手法の現代的な置き換えです。

docker composeはリモートコンテキストで動きますか？

はい。Compose V2はアクティブなDockerコンテキストを尊重するので、 docker compose コマンドは、コンテキストが指すホストに対して実行されます。サービスとあらゆるイメージのビルドはリモートホスト上で実行され、これはプレーンな docker build.

Docker Offloadとは何で、無料ですか？

Docker Offloadは、Docker Desktopのワークフローを保ちつつ、コンテナ作業をDocker管理のクラウドホストへ移す、Docker自身のマネージドなリモートのビルド/実行サービスです。現在のDockerのドキュメントは、それを Docker Desktop 4.68以降を必要とするものとして挙げ、さらに Docker BusinessとDocker Offloadのサブスクリプションを挙げています。それはセッションベースでもあります。各ユーザーが得るのは 一度に1つのOffloadセッションで、アイドルセッションは5分の猶予後に終了し、リモートの環境は一時的です。

Docker Desktopがそんなにメモリを使うのをどう止めればいいですか？

Docker Desktopのリソース上限を調整しても、決してゼロには下がらないフットプリントを縮めるだけです。VMには常に床があるからです。メモリのコストを本当に取り除く道は、ローカルのデーモンを完全に取り除くことです。Docker EngineをVPS上で動かし、 docker context 経由でSSHでつなげば、あなたのマシンではCLI以外何も動きません。

代わりにPodmanでこれをできますか？

できます。PodmanはDocker互換のエンジンとして使え、 docker context はリモートのPodmanホストを指せますが、それにはPodmanがそのDocker互換ソケットをSSH経由で公開する必要があります。コマンドの流れは同じです。リモート側のセットアップは異なります。