Install models and custom nodes in ComfyUI on a cloud GPU

The ComfyUI template starts with ComfyUI and ComfyUI-Manager installed and nothing else, so the first job of every session is getting models and custom nodes into the container. Manager covers custom nodes and the models it lists. Everything else goes in over SSH, into a folder you check first, and all of it sits on the instance disk, which Stop deletes. This guide follows the ComfyUI template page and covers where the files go, the commands that pull them in and what it costs to get the same setup back next time.

Check the models folder before you download anything

The template runs one Docker container named deploygpu-workload. ComfyUI lives at /workspace/runpod-slim/ComfyUI inside it, according to the README of RunPod's ComfyUI base image, which the template is built from (checked 1 October 2026). Models go in one subfolder per type under models. The image only changes when DeployGPU rebuilds it, so confirm the path on your own deployment before you download anything:

sudo docker exec deploygpu-workload ls /workspace/runpod-slim/ComfyUI/models

If that fails, sudo docker exec deploygpu-workload find / -maxdepth 4 -type d -name ComfyUI shows where ComfyUI really is. The folders that matter, from ComfyUI's own folder_paths.py:

ComfyUI also searches clip for text encoders and unet for diffusion models. If your listing shows only those, use the folder it shows.

You do not install ComfyUI on this template

ComfyUI is already in the image, so there is no install step. If you want your own copy on a plain GPU VM instead, the manual install is git clone https://github.com/Comfy-Org/ComfyUI.git, then pip install -r requirements.txt and python main.py from inside the ComfyUI folder. Manager is then yours to switch on, and the Manager install docs describe the --enable-manager flag.

Add custom nodes with ComfyUI-Manager

Click Manager in the top menu, then Install Custom Nodes. If you loaded a workflow that reports missing nodes, choose Install Missing Custom Nodes instead, which lists the extensions that contain the nodes your workflow lacks, according to the Manager README. Click Install, or Try Install for an entry whose installation information cannot be confirmed. Manager finishes the dependency install and prompts for a restart. After the restart, look for import failed messages, as the Manager docs advise. The same check works from the VM:

sudo docker logs deploygpu-workload 2>&1 | grep -i "import failed"

No output means every node pack loaded. ComfyUI marks each pack that did not with IMPORT FAILED in its startup summary. Node packs land in /workspace/runpod-slim/ComfyUI/custom_nodes. Menu labels follow the Manager version inside the image, so if one differs from this page, the Manager docs have the current wording. If the page does not come back after the restart, sudo docker restart deploygpu-workload restarts the existing container, not a new one, so what you installed stays.

Pick a numbered version over nightly. The docs describe numbered versions as published releases and nightly as the latest GitHub code, usually not security scanned. ComfyUI's default security settings refuse nightly installs, and a git URL install that the settings do not allow fails with This action is not allowed with this security level configuration. I leave those settings alone. A node pack is code that runs inside your container and can read what is in it, including any token you pasted in.

Add models from Manager or over SSH

Install Models in the same menu lists the models Manager knows. Anything else is a manual download, because Manager's README counts downloads of non-safetensors files outside its default model list as high risk and blocks them at its normal and strong security levels. Open a shell in the container, move to the models folder and download straight into the right subfolder. This file is ungated:

sudo docker exec -it deploygpu-workload bash
cd /workspace/runpod-slim/ComfyUI/models
curl -L --fail -o checkpoints/flux1-dev-fp8.safetensors \
  https://huggingface.co/Comfy-Org/flux1-dev/resolve/main/flux1-dev-fp8.safetensors

The -L flag follows the redirect Hugging Face sends to its storage servers. The --fail flag makes curl stop on an HTTP error instead of saving the error text as your model. After a dropped connection, run the same command with -C - added and curl resumes, per the curl manual. RunPod's current Dockerfile installs curl, wget, git and rsync, but the template image may predate it, so run command -v curl first. Without it, download on the VM and copy the file in with sudo docker cp.

The original FLUX.1-dev files in the Black Forest Labs repository are gated. Hugging Face says access can only be requested from a browser, and a script needs a token, which the Hugging Face CLI reads from HF_TOKEN. The download guide covers installing the CLI:

export HF_TOKEN=paste-your-token-here
hf download black-forest-labs/FLUX.1-dev flux1-dev.safetensors \
  --local-dir /workspace/runpod-slim/ComfyUI/models/diffusion_models

Check each file after it lands. ls -l shows the size in bytes, and the Hugging Face file page lists a SHA256 that sha256sum should match. Then press R in ComfyUI to refresh node definitions so the loader nodes list the new files.

Where the Flux and Wan 2.2 files go

ComfyUI's tutorials for FLUX.1 and Wan2.2 name these files and folders. The sizes come from the Hugging Face file listings, and both were checked on 1 October 2026.

Added up (calculated), the split FLUX.1-dev set is about 34.2 GB and the Wan2.2 5B set about 18.2 GB. The Wan2.2 A14B text-to-video set is about 35.6 GB: two 14.29 GB fp8 diffusion files, the 6.74 GB text encoder and the 0.25 GB wan_2.1_vae.safetensors. Check the disk size on the deploy page before you plan a download list, because it is fixed on most providers.

Licenses differ. Hugging Face lists both FLUX.1-dev repositories under the FLUX.1-dev non-commercial license, so read it before commercial use. Wan2.2 is Apache-2.0 on its model cards. For how much GPU memory each model needs, see the FLUX page and the Wan 2.2 page.

What Stop deletes and what coming back costs

Plan on downloading again. At an assumed 1 Gbit/s, which is 125 MB/s, the 34.2 GB FLUX.1-dev set is about 4.6 minutes of pure transfer and the 35.6 GB Wan2.2 A14B set about 4.7 minutes (calculated, and the real speed depends on the provider and on Hugging Face). The GPU bills the whole time. My habit is to keep a plain list of the files a project uses in its own repository, one line per file with the folder and the URL, so the next session starts with a loop instead of a search. Copy the list in with sudo docker cp models.txt deploygpu-workload:/tmp/models.txt, then run this inside the container:

cd /workspace/runpod-slim/ComfyUI/models
while read -r dest url; do
  mkdir -p "$dest"
  [ -f "$dest/$(basename "$url")" ] || curl -L --fail -o "$dest/$(basename "$url")" "$url"
done < /tmp/models.txt

A volume on Verda or Hyperstack survives Stop, but the template's container mounts nothing from the VM, so a volume would only be a place to copy models from with sudo docker cp. Copy outputs off before you stop with sudo docker cp deploygpu-workload:/workspace/runpod-slim/ComfyUI/output ./comfy-output, then pull the folder down with rsync or scp, and save the workflow JSON from the app. The stop guide and the data transfer guide have the commands.

When something goes wrong

To see which ComfyUI and PyTorch versions the image carries, run curl -s http://127.0.0.1:8188/system_stats on the VM. The reply lists comfyui_version and pytorch_version, per the ComfyUI routes documentation.