ComfyUI: read this before you install it

ComfyUI is not difficult because the UI is strange; it is difficult because models, custom nodes, Python environments, GPU memory, and workflow JSON all meet in one place. I would verify the base install before adding any custom nodes or borrowed workflows.

Do not install custom nodes first

I would not start ComfyUI by importing a beautiful workflow from the internet. I start with the base install, one known model, and the simplest generation graph. If that does not work, custom nodes will only add noise.

The first check is GPU and Python environment. Many ComfyUI failures are not really ComfyUI failures: wrong CUDA/PyTorch build, missing model file, low VRAM, or custom node dependencies installed into the wrong Python.

I also make a folder map before changing anything: where models live, where custom nodes live, where the Python executable is, and where outputs go. Without that map, every tutorial becomes slightly dangerous.

When node graphs are worth the complexity

ComfyUI fits when you want to understand and control image-generation workflows. It is good for repeatable pipelines, node-level experimentation, and cases where a one-button UI hides too much.

I would not use it if I only need casual image generation. The power is real, but the maintenance cost is also real. Custom nodes, model versions, and workflow compatibility change the experience over time.

My fit check is whether I need workflow control more than convenience. If yes, ComfyUI is worth learning. If not, a simpler UI may be healthier.

Models, nodes, workflow JSON, and GPU limits

I read ComfyUI as model files plus nodes plus workflow JSON plus runtime environment. The graph is the visible part. The invisible part is whether the model files and node packages match what the graph expects.

Custom nodes are where I slow down. They are code. They may require dependencies, specific versions, or model folders. I never install five custom node packs at once and then try to debug the broken graph.

GPU memory is part of the architecture too. A workflow can be logically correct and still fail because the model, resolution, batch size, or sampler settings exceed available VRAM.

Base generation before borrowed workflows

My setup path is: base install, run once, place one model in the expected folder, start the UI, load the simplest workflow, generate one image, then restart and repeat. Only after that do I add Manager or custom nodes.

When installing custom node dependencies, I make sure pip belongs to the same Python that runs ComfyUI. On portable Windows builds, that usually means the embedded Python, not the system Python.

I keep a small known-good workflow JSON. When a new workflow fails, I switch back to that known-good graph. If the known-good graph still works, the new workflow or nodes are the problem.

My ComfyUI command path

Use the prep panel before cloning custom nodes or downloading models. It checks Python, GPU visibility, the model folder, and whether the right Python will receive packages.

Use the verify panel after the base install and after every custom node addition. One known-good generation is the checkpoint. If it fails, do not add another node pack.

Use the debug panel when the UI opens but a workflow fails validation, cannot find a model, or crashes during generation. The symptom tells you whether to check model paths, node dependencies, or VRAM.

When the graph loads but generation fails

If a workflow says a model is missing, I check the exact model folder and filename first. Renaming files casually creates a lot of fake problems.

If a node is missing, I check whether the custom node repo is actually inside `custom_nodes` and whether its dependencies were installed into the correct Python.

If generation starts and then dies, I check VRAM and reduce resolution/batch before blaming the workflow. Heavy workflows can fail even when the installation is correct.

The first workflow I would save

The first workflow I would save is a basic text-to-image graph with one checkpoint and no custom nodes. It becomes the smoke test for the whole install.

Then I add one custom node pack and run the same base workflow again before using the new node. This tells me whether the extension broke the environment.

Only after that would I import someone else’s complex workflow. ComfyUI is powerful when you build trust layer by layer.

How I would use the command panel

Field commands I would keep beside this note

# ComfyUI prep

python --version
git --version
python -c "import torch; print(torch.__version__, torch.cuda.is_available())" || true

# know your paths
ls models || true
ls custom_nodes || true

# ComfyUI verify

# base install style
python main.py
# open shown local URL

# after adding one model
# run one basic text-to-image workflow

# after every custom node addition
python main.py

# ComfyUI debug

missing model -> check models/checkpoints or expected model folder
missing node -> check custom_nodes and dependency install
portable Windows -> use python_embeded/python.exe for pip
CUDA/VRAM error -> lower resolution/batch, check torch build
workflow import error -> return to known-good workflow JSON