ComfyUI-Docker: the NVIDIA quick start ends in the middle of a volume argument

The quick start command stops in the middle of a mount path

The NVIDIA quick start is one shell block that creates directories and then launches a container:

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

# Add sudo if needed
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-l

The last visible line ends partway through a path, inside the storage-nodes group and before the custom node, model and user mounts are written out. Everything above that line is complete: eleven directories to create, an interactive container removed on exit, a fixed name, a forced pull, the NVIDIA runtime with all GPUs, and port 8188 published on the host. The mount arguments after the two cache directories are not on the page, so the command has to be finished from the directory list above it.

Eleven bind mounts make the working directory the entire application state

The mkdir block is the real documentation here, because it names what the container treats as persistent. Two cache directories map to /root/.cache and /root/.config. Two node directories cover the ComfyUI local tree and custom_nodes, which is where third-party nodes live. Three model directories cover the model folder plus separate huggingface hub and torch hub caches, so downloaded weights survive even a container rebuild. Four user directories cover input, output, a user profile and user scripts. Every mount in the visible part uses $(pwd), so state lands beside the checkout rather than in a named volume. That is a deliberate trade: easy to inspect, copy and delete from the host, and easy to lose if you delete the working directory. The cost of that choice is that nothing appears in a volume list, so backup means copying directories and reset means deleting them, and the eleven names have to be spelled identically on the host and in the container for the mapping to mean anything.

The CUDA table draws its line between Turing and Volta

The compatibility table covers eight NVIDIA architectures, from Blackwell and Hopper through Ada Lovelace and Ampere to Turing, Volta, Pascal and Maxwell. cu132 and cu130 are marked for the first five and unmarked for the last three, while cu126 is unmarked for Blackwell and Hopper and marked from Ada Lovelace all the way down to Maxwell. So the split is not new hardware versus old hardware but new hardware versus the last two generations, and CUDA 13.0 is the recommended line. The page attributes those limits to the PyTorch toolchain rather than the NVIDIA CUDA Toolkit, links the PyTorch 2.8.0 release and a 2.12.0 build script, and notes that ComfyUI's own performance library is developed against CUDA 13.0. The example row pairs those columns with parts from an RTX 5090 and an H100 down through an RTX 4090, an RTX 3090 and a GTX 1080 to a GTX 980, and for anyone who cannot place their own card the page links out to a third-party article on matching architectures and gencode. AMD, Intel and CPU users get no table at all.

Two families, four documented tags, and only one names a PyTorch version

The slim images start with ComfyUI and ComfyUI-Manager only, while still carrying the dependencies that make installing custom nodes later easier, and they are recommended for beginners. The megapak images are all-in-one bundles with development kits and dozens of custom nodes. Each family has a cu130 variant and a cu126 variant, and the cu130 pair is the one marked as recommended: cu130-slim-v2 is CUDA 13.0 with Python 3.13 with the GIL and no xFormers, while cu130-megapak-pt211 adds GCC 14 and PyTorch 2.11.0. The cu126 pair is CUDA 12.6 with Python 3.12, and only its megapak names a PyTorch version at all, 2.9.1, with GCC 13. Whether the cu126 slim ships xFormers is not stated. A nightly tag adds the development build of PyTorch for testing new features.

The tree carries base stages the tag list never explains

The top-level directory listing holds more than the four documented CUDA tags and includes a layer of build stages that no tag section describes: base-cu130-devel/, base-cu130-pt211-cache/, base-cu130-pt211/, base-cu130-pt212/, base-cu130-slim-s1/ and base-cu130-slim-s2/. Two slim base variants exist while only one slim tag is documented, and a pt212 base sits next to a tag named pt211. There is also base-rocm72-pt213/, implying a ROCm 7.2 stage on PyTorch 2.13, and xpu-cn/ alongside the documented xpu/ tag, which suggests a second Intel target that the XPU section does not mention. archived/ holds the Dockerfiles of retired tags. Anyone auditing what a published image contains has to read those directories as well as the tag list.

Two ROCm 7 images trade speed against completeness

The AMD side offers three tags and the interesting detail is that two of them target the same ROCm 7. The rocm tag is based on PyTorch's builds and described as the faster release, while rocm7 is based on AMD's builds and described as the wider set of functionality. So an AMD user choosing between them is choosing whose build of the same major version they trust, not choosing a version. The third tag, rocm6, covers ROCm 6 and is labelled the stable version, which makes it the conservative pick for hardware the newer builds have not caught up with. What none of the three carries is an example run command, a compatibility table or a minimum GPU model, and that absence is the practical gap on the AMD side, since the NVIDIA quick start supplies all three.

Port 8188 is published on the host with no authentication in the command

The run line publishes 8188 to 8188 and nothing in it restricts the bind address, sets a password or places a proxy in front. ComfyUI's web interface is the entire user interface of this container, so that mapping is the security boundary, and the only instruction attached to the command is a comment about adding sudo when the Docker socket needs it. Two smaller consequences come from the same block. `--pull=always` means a locally built image carrying the same tag is replaced on every start, so a custom layer built under that name will not survive the next run. `--name comfyui-cu130` is fixed, so a second run fails while the first container is still alive rather than starting a second copy on the same port.

Two readmes ship as files, and the license metadata disagrees with the page

Documentation comes in two tracked files rather than one page plus a translation service: README.adoc holds the English text and README.zh.adoc the Chinese, with a language line at the top of each. The opening line of the page points at the image registry rather than at a documentation site, and the project describes itself as Docker images that run ComfyUI, so the registry listing is effectively the front page. Licensing is where two sources disagree. The license metadata field for this repository carries no license name at all, while the License section of the page links the root LICENSE to the Mulan Public License, Version 2, and the tree does contain that file. Those two statements can both be filed without either being resolved here. On releases, the newest tag is v6.0 dated 2025-10-15, before v5.0 in 2024 and v4.0 in 2024, while the last recorded push to main is dated 2026-09-21, so the image tags have moved without a matching release.

Editorial conclusion

This is a sensible way to run ComfyUI if you want your models, custom nodes and caches to survive a container rebuild rather than disappear with it, and the NVIDIA path is the one with real documentation. Two things decide whether it fits. If you cannot identify your own GPU architecture, the compatibility table is the only thing standing between you and an image that will not start, so check that first; AMD, Intel and CPU users get tag lists with no compatibility table at all. Second, choose between slim and megapak deliberately, because the difference is dozens of custom nodes and development kits, not performance. Expect to assemble the run command yourself, since the printed one is incomplete, and treat 8188 as an unauthenticated service on your host. Nothing here should be exposed beyond localhost without a proxy in front of it.

Frequently asked questions

Official sources

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