ComfyUIをDockerで動かす方法｜GPU・Volume・モデル永続化を解説

ComfyUIには公式のDockerイメージがありません。公式の手動インストール手順をそのままDockerfileに写し、NVIDIA Container ToolkitでGPUを通し、models・output・custom_nodesをVolumeとして外に出す構成が基本です。Docker化で分離できるのはPythonとライブラリの依存であり、GPU Driver・VRAM・危険なCustom Nodeの問題はHost側に残ります。

情報確認日：2026年8月22日（日本時間）

結論：公式手順をDockerfileに写し、Volumeとversionを自分で管理する

Docker化で何が分離できるか

Docker化の効果は「Python環境の壊れにくさ」に集中しています。Custom Nodeが要求するライブラリの衝突、torchのversion違い、システムPythonの汚染はContainerの中に閉じ込められます。一方で、GPUを動かすDriverはHostのカーネルに属するため、Containerの中には持ち込めません。

公式ドキュメントのインストール案内（2026年8月時点）は、Desktopアプリ・Windows portable・comfy-cli・手動インストール・Cloudの5つで、Dockerは含まれていません。FAQには「公式Dockerイメージは提供していない。Containerで動かしたい場合はDocker Hubのコミュニティイメージを探す」と明記されています。この記事ではコミュニティイメージを使わず、公式の手動手順を自分でDockerfileに書く方法を取ります。中身を自分で把握できるからです。

GPUをContainerから確認するにはどうするか

ComfyUIを入れる前に、ContainerからGPUが見える状態を作ります。NVIDIA Container Toolkitの公式手順（Ubuntu/Debian）は次の順です。前提として、HostにNVIDIA Driverが入っていてnvidia-smiが動くことを確認しておきます。

# 1. リポジトリ追加（公式手順どおり）
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update

# 2. インストール
sudo apt-get install -y nvidia-container-toolkit

# 3. Docker に runtime を登録して再起動
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# 4. Container から GPU が見えるか
docker run --rm --gpus all ubuntu nvidia-smi

4でHostと同じGPU名とDriver versionが表示されれば、GPUの疎通は完了です。ここで失敗する場合、原因はComfyUIではなくDriverかToolkitにあります。公式のインストールガイドは更新されるため、コマンドの細部は実行前に公式ページで確認してください。

ComfyUIをどう起動するか

Dockerfileは公式の手動インストール手順（git clone、torchのインストール、requirements.txt、python main.py）を1行ずつ写したものです。Imageに入れるのはコードとライブラリだけで、modelや出力は入れません。

# Dockerfile
FROM python:3.12-slim

ARG COMFYUI_REF=master   # build 時に tag か commit hash を渡す

RUN apt-get update && apt-get install -y --no-install-recommends git \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
RUN git clone https://github.com/comfyanonymous/ComfyUI.git . \
    && git checkout "${COMFYUI_REF}" \
    && git rev-parse HEAD > /app/COMFYUI_COMMIT

# 公式手順の torch 行。index URL は公式の最新手順に合わせる
RUN pip install --no-cache-dir torch torchvision torchaudio \
      --extra-index-url https://download.pytorch.org/whl/cu130 \
    && pip install --no-cache-dir -r requirements.txt

EXPOSE 8188
CMD ["python", "main.py", "--listen", "0.0.0.0", "--port", "8188"]

--listen 0.0.0.0はContainerの外（Host）からアクセスするために必要です。ComfyUIの既定は127.0.0.1で、Containerの中だけで待ち受けてしまいます。ただしこの設定はContainer内の話で、Host側のポート公開は次のcomposeで127.0.0.1:8188:8188と書き、LANには出しません。

# compose.yaml
services:
  comfyui:
    build:
      context: .
      args:
        COMFYUI_REF: "TAG_OR_COMMIT"   # 実際に使う tag か commit hash に置き換える
    image: comfyui-local:TAG_OR_COMMIT
    ports:
      - "127.0.0.1:8188:8188"
    volumes:
      - ./models:/app/models
      - ./input:/app/input
      - ./output:/app/output
      - ./custom_nodes:/app/custom_nodes
      - ./user:/app/user
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

docker compose build
docker compose up -d
docker compose logs -f comfyui     # 起動ログ。custom_nodes の読み込み結果もここに出る

ブラウザでhttp://127.0.0.1:8188を開き、現行UI（2026年8月時点）が表示されれば起動は成功です。modelを置いていない段階ではcheckpointの一覧が空なので、次のVolume設計で置き場所を決めます。

Volumeはどう設計するか

Imageに焼き込んではいけないのは「大きいもの」「変わるもの」「失うと困るもの」の3種類です。ComfyUIではmodels・input・output・custom_nodes・userが該当します。公式ドキュメントが案内するフォルダ構成（ComfyUI/models/checkpointsなど）をそのままHost側に作り、同じパスにmountします。

既にHost側で手動インストール版を使っていて、modelフォルダを共有したい場合は、./modelsの代わりにそのフォルダをmountするか、extra_model_paths.yamlを用意して--extra-model-paths-configで渡します。yamlの書き方はextra_model_paths.yamlの設定方法を参照してください。

Versionをどう固定するか

latestやmasterのまま使うと、docker compose buildのたびに違うComfyUIが入ります。固定する対象は3つあり、すべて自分で記録します。

# 動いている Container の ComfyUI commit を確認
docker compose exec comfyui cat /app/COMFYUI_COMMIT

# torch の version と CUDA が有効か
docker compose exec comfyui python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

tagよりcommit hashの方が確実です。tagは打ち直されることがありますが、commit hashは同じ中身を一意に指します。更新するときはCOMFYUI_REFを変えて別tagのImageをbuildし、旧Imageを残しておけば、問題があればimage:を戻すだけで切り戻せます。

Dockerでも残る問題は何か

Docker化で解決したように見えて、実際には何も変わらない問題があります。期待と現実を分けておきます。

特にCustom Nodeについては、「Containerだから何を入れても安全」という理解は誤りです。mountしたmodels・outputは書き換えられますし、既定のネットワーク設定では外部へ通信できます。Custom Nodeの選び方と権限の考え方は、Docker化の前後で変わりません。

Host版とDocker版で同じworkflowを1回ずつ実行する

Docker化が正しくできたかは、同じworkflowをHost版（手動インストール）とDocker版で1回ずつ実行し、差を見れば分かります。seed・model・解像度を固定し、次の表を埋めます。

commitとtorchが同じで画像が大きく違うなら、Volumeのmodelが別物か、Custom Nodeの読み込み結果が違っています。生成秒数が大きく違うなら、GPUがContainerから使えていない（CPUで動いている）可能性を先に疑い、torch.cuda.is_available()を確認します。

よくある質問

まとめ

ComfyUIのDocker化は、公式Dockerイメージがない前提で、公式の手動インストール手順をDockerfileに写す形が基本です。GPUはNVIDIA Container Toolkitで通し、nvidia-smiがContainerから見えることを先に確かめます。

models・input・output・custom_nodes・userはVolumeに出し、ComfyUIはcommit hashで固定して記録します。分離できるのはPython依存までで、VRAM・Driver・Custom Nodeの危険性はHostと同じ問題として残ることを忘れないでください。