ComfyUI-Docker: Running ComfyUI in a Container on NVIDIA, AMD and Intel GPUs

The problem ComfyUI-Docker solves, and for whom

ComfyUI is a Python application with a large dependency surface: PyTorch, a CUDA or ROCm toolchain, and a stream of custom nodes that each bring their own requirements. Installing it directly on a workstation means the ComfyUI environment shares a Python interpreter with everything else on the machine, and a custom node that pins a different PyTorch build can break the whole install. The repository frames its images as a way to run ComfyUI without that coupling: the application, its Python version and its PyTorch build live inside the image, while models, output, input and custom nodes live on host directories that are bind-mounted into the container.

The audience is therefore people who already accept containers: someone with an NVIDIA card who wants a reproducible ComfyUI install, someone on an AMD card who wants ROCm without fighting the host driver stack, and anyone running ComfyUI on a headless Linux box. The project also publishes a CPU-only image, which points at a second audience: users without a supported GPU who want to try workflows before buying hardware. It is not aimed at people who want a desktop application with a graphical installer, and the README gives no indication that one exists.

How the images are built and tagged

The repository is a Dockerfile collection, not a single image. Top-level directories map to image families: cu130-slim-v2, cu126-slim, cu130-megapak-pt211, cu126-megapak, nightly, rocm, rocm6, rocm7, xpu, xpu-cn and cpu, with base-cu130-devel, base-cu130-pt211, base-cu130-pt211-cache, base-cu130-pt212, base-cu130-slim-s1, base-cu130-slim-s2 and base-rocm72-pt213 holding the intermediate build stages. An archived/ directory keeps Dockerfiles for retired tags, which is a useful signal: tags do disappear, and the build recipe for an old tag stays readable after the image itself is no longer the recommended one.

Two naming axes matter. The first is the CUDA or ROCm generation in the tag prefix. The second is slim versus megapak. Slim images ship ComfyUI and ComfyUI-Manager plus, in the project's words, "many dependencies to make future Custom Node installation easier", and the README calls them recommended for beginners. Megapak images are described as all-in-one bundles that add development kits and dozens of custom nodes. The trade-off is size and surface area against convenience: megapak saves you the first round of node installation but you inherit whatever those nodes pin.

Installing ComfyUI-Docker and running a first container

The README's quick start is a two-step procedure. First create the host directories that will be mounted into the container. The command below creates eleven of them, covering caches, custom nodes, models, Hugging Face and Torch hubs, input, output, the user profile and user scripts.

mkdir -p \
  storage-cache/dot-cache \
  storage-cache/dot-config \
  storage-nodes/dot-local \
  storage-nodes/custom_nodes \
  storage-models/models \
  storage-models/hf-hub \
  storage-models/torch-hub \
  storage-user/input \
  storage-user/output \
  storage-user/user-profile \
  storage-user/user-scripts

Then start the container. The README's example uses the cu130-slim-v2 tag, requests the NVIDIA runtime with all GPUs, publishes port 8188, mounts each host directory at its container path, and passes CLI_ARGS as an environment variable that is empty by default.

docker run -it --rm \
  --name comfyui-cu130 \
  --pull=always \
  --runtime=nvidia \
  --gpus all \
  -p 8188:8188 \
  -v "$(pwd)"/storage-cache/dot-cache:/root/.cache \
  -v "$(pwd)"/storage-cache/dot-config:/root/.config \
  -v "$(pwd)"/storage-nodes/dot-local:/root/.local \
  -v "$(pwd)"/storage-nodes/custom_nodes:/root/ComfyUI/custom_nodes \
  -v "$(pwd)"/storage-models/models:/root/ComfyUI/models \
  -v "$(pwd)"/storage-models/hf-hub:/root/.cache/huggingface/hub \
  -v "$(pwd)"/storage-models/torch-hub:/root/.cache/torch/hub \
  -v "$(pwd)"/storage-user/input:/root/ComfyUI/input \
  -v "$(pwd)"/storage-user/output:/root/ComfyUI/output \
  -v "$(pwd)"/storage-user/user-profile:/root/ComfyUI/user \
  -v "$(pwd)"/storage-user/user-scripts:/root/user-scripts \
  -e CLI_ARGS="" \
  yanwk/comfyui-boot:cu130-slim-v2

The README notes that sudo may be needed. What you should see is the container starting and ComfyUI listening on port 8188, reachable at http://localhost:8188 from the host. The --rm flag means the container is discarded on exit, so anything you want to keep must live under one of the mounted directories. That is the design: the container is disposable, the volumes are not.

Picking a tag: the CUDA table is the real constraint

The compatibility table is the most consequential part of the README. cu132 and cu130 both support Blackwell, Hopper, Ada Lovelace, Ampere and Turing, and both mark Volta, Pascal and Maxwell as unsupported. cu126 supports Ada Lovelace, Ampere, Turing, Volta, Pascal and Maxwell but not Blackwell or Hopper. In other words, the recommended CUDA 13.0 image and the older-GPU image are disjoint at both ends of the range: an RTX 5090 needs cu130 or cu132, a GTX 1080 needs cu126.

The README attributes the limits to the PyTorch toolchain rather than the CUDA Toolkit itself and links to the PyTorch build script as evidence. It also states that ComfyUI's performance library is currently developed against CUDA 13.0, which is why cu130 carries the recommendation. The practical consequence is that if you are on Pascal or Volta, you are choosing between the recommended image and your GPU, and the older cu126 line is the one that runs. The table lists RTX 2080, GTX 1660 and TITAN V as examples, so the boundary is not always where the marketing tier suggests. Check the architecture of your specific card before pulling anything.

Where the project stops short: no compose file, and a heavy first run

The README shows only docker run. There is no docker-compose.yml in the top-level entries and no compose example in the quick start, so if you want Compose you write it yourself from the flags above. That is a real gap for anyone deploying this on a server, because the run command is long and easy to mistype, and a compose file is the natural place to keep it under version control. The repository does have a docs/ directory, but the README does not point at a compose recipe.

The second limitation is the mount list itself. Eleven bind mounts mean eleven chances for a path to be wrong, and a missing host directory is a silent failure mode rather than an error in most setups: Docker creates the directory as root and the container writes into it, which can leave you with root-owned files under your working tree. The quick start's mkdir command exists precisely to avoid that, and skipping it is the most common way to get a confusing permissions problem later.

A third boundary is the CPU image. The README lists it as "a smaller image for CPU only" and says nothing about expected speed. Anyone choosing it should treat it as a way to validate a workflow, not to run one at interactive speed. The project does not make a performance claim and neither should you assume one.

The AMD and Intel paths look different from the NVIDIA one

For AMD, the repository splits into three tags. rocm and rocm7 are both described as for AMD GPUs with ROCm 7, but rocm is based on PyTorch's own builds, which the README calls the faster release path, while rocm7 is based on AMD's builds and is described as having comprehensive functionality. rocm6 is for ROCm 6 and is labelled the stable version. That is an unusual three-way split: two tags target the same ROCm generation with different upstreams, so the choice is about which build you trust rather than which version you need. The README does not say which one to prefer, and it does not provide a compatibility table for AMD the way it does for NVIDIA.

For Intel, xpu and xpu-cn are listed for Intel GPUs with XPU, and the README gives no further detail on the difference between them. The NVIDIA quick start does not apply here: --runtime=nvidia and --gpus all are NVIDIA-specific, and the README offers no ROCm or XPU equivalent of the run command. Anyone on AMD or Intel is working from the per-tag README.adoc files rather than the top-level one. That is a documentation asymmetry worth knowing before you start, not a defect in the images.

How this compares to running ComfyUI directly or via ComfyUI-Manager

The obvious alternative is a native install: clone ComfyUI, create a virtual environment, install PyTorch for your CUDA version, then install ComfyUI-Manager and let it pull custom nodes. That path gives you faster iteration on the application itself and no image pull, and it is the right choice if you are developing custom nodes or patching ComfyUI source, because editing files inside a running container is a worse workflow than editing a checkout. The difference in approach is where the dependency boundary sits. Native installs share the host toolchain; ComfyUI-Docker freezes it in the image and mounts only data.

A second alternative is the megapak tag in this same repository rather than a different project. It is the middle ground: you still get the container boundary, but the dozens of preinstalled custom nodes mean you skip the initial node hunt. The cost is that you cannot easily tell which node pulled which dependency, and the README does not enumerate the bundled nodes in the top-level file. If your goal is a known-good starting set, megapak is the shorter path; if your goal is a minimal environment you fully understand, slim is.

The third comparison is between this repository and building your own Dockerfile. The repository already publishes base-* directories for the intermediate stages, so the heavy lifting is done, but you are still pinned to the maintainer's choice of Python version and PyTorch build for each tag. If you need a different combination, the base directories are the starting point, not the published tags.

Maintenance cadence, upgrades and the licence

The last push to the default branch was on 2026-09-10, and the most recent release is v6.0 from 2025-10-15, preceded by v5.0 in 2024-09-11 and v4.0 in 2024-04-16. The gap between v5.0 and v6.0 is roughly thirteen months, so releases are not frequent, but the repository is not archived and commits continue between releases. Treat the image tags, not the release numbers, as the upgrade unit: the tags carry CUDA, Python and PyTorch versions in their names, and the README's --pull=always flag in the quick start means a restart can move you to a newer image without a version change in your command.

That flag deserves attention. It is convenient and it is also the mechanism by which an upgrade happens without you asking for one. If you need a fixed environment, pin the tag and drop --pull=always. The repository keeps archived/ Dockerfiles for retired tags, which helps you reconstruct what an old tag contained, but an archived Dockerfile is not a published image.

The licence is listed as NOASSERTION in the repository metadata, and the README points at a LICENSE file naming the Mulan Public License, Version 2, described there as written and valid in both Chinese and English. Because the metadata does not classify it, tools that filter by SPDX identifier may not recognise it, and you should read the LICENSE file itself if licence terms matter to your use. This is not legal advice; the point is only that the automated classification and the README disagree, and the file is the authority.

Editorial conclusion

Adopt it if you want ComfyUI isolated from your host Python and your models kept on mounted volumes, and if your GPU is Turing or newer for the CUDA 13.0 tags. Do not adopt it if you run a Pascal or Volta card and want the recommended cu130 image, or if you expect a compose file in the README, because there is none. Before committing, verify that your GPU architecture maps to a tag in the CUDA compatibility table, check that the eleven host directories in the quick start exist and are writable, and confirm which image tag you actually pulled rather than assuming latest.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. YanWenKun/ComfyUI-Docker on GitHub