Workflow Environment Setup
A battle-tested SOP for getting ComfyUI workflows running on Windows, from a clean base to "only missing models".
This guide is a real-world SOP (Standard Operating Procedure) for setting up ComfyUI to run a batch of workflows. The goal is clear: reach a state where plugins and dependencies are resolved, and the only remaining issues are missing model files.
This is the methodology for setting up a clean, reproducible environment.
The Core Principle
Start the core first, then audit gaps. Fix missing backend nodes before dependency drift. Validate runtime evidence before chasing model files.
Before changing an environment, export the workflow JSON files you care about. See Save Workflow in ComfyUI for the difference between workflow JSON, API format, PNG metadata, and auto-save state.
If you reverse this order, you will waste hours:
- Installing dependencies before ComfyUI even runs, making the environment dirtier
- Confusing frontend-only graph helpers with backend nodes
- Confusing missing nodes with missing models
- Seeing a plugin folder exists and assuming it imported successfully
- Treating a runtime CUDA/model error as a plugin install problem
The 7 Stages
The entire process follows a fixed sequence. Do not skip or reorder stages unless you have evidence that a later stage is the first failing layer.
Stage 1: Build the Base
Goal: Get a clean ComfyUI instance to start up and confirm Python, PyTorch, and CUDA are working.
Actions:
- Pick the install type first: official GitHub Windows portable package, ComfyUI Desktop, manual Git + venv, or a managed launcher.
- For the official portable package, treat the extracted folder containing
run_*.bat,python_embeded, andComfyUIas the package root. - For a manual Git install, activate the intended venv before running commands.
- Do a minimal startup test before adding custom nodes.
How to verify:
- Visit
http://127.0.0.1:8188/system_stats. It should return system info including Python version, PyTorch version, and GPU details. - Confirm the Python executable shown in the startup log. Use that exact Python for later package commands.
- If this does not work, stop here. Fix the base before moving on.
Why this order: If the base cannot start, everything else is noise. See System Requirements and install guides for setting up the base.
Stage 2: Audit Workflows and Missing Nodes
Goal: Build a concrete list of what is missing, not guesses.
Actions:
- Recursively scan your workflow directory, not just top-level files.
- Extract all backend node types from workflow JSON files.
- Exclude frontend-only nodes that do not need backend registration:
Note,Reroute,MarkdownNoteFast Groups Muter (rgthree),Fast Groups Bypasser (rgthree)PrimitiveNode,GetNode,SetNode- Anything starting with
workflow>when it is a workflow-local wrapper
How to verify: You can list exactly which backend nodes are missing for each workflow.
Why this order: You cannot know which plugins to install if you have not listed what the workflow actually asks for.
Stage 3: Map Missing Nodes to Plugins
Goal: Turn "missing node X" into "install or repair plugin repo Y".
Priority order for identifying which plugin provides a node:
- Check the workflow JSON for
cnr_idor registry metadata. - Check
Node name for S&Ror saved search/replace metadata. - Check whether any repo in your existing
custom_nodes/already covers it. - Check ComfyUI-Manager's installed package info.
- Check the Manager's
extension-node-map.jsonandnodename_patternrules. - Last resort: search GitHub, mirrors, or old integration packs.
For a deep dive on node mapping, see Plugin Management.
Common pitfalls:
- Same node name, different repo.
- Repo migration: the old URL may be dead.
- Cloud-platform nodes, such as service-specific API nodes, may not have a local plugin equivalent.
- A plugin folder can exist but still fail to import, so the node never registers.
Stage 4: Install Plugins in Batches
Goal: Get nodes registered without breaking what already works.
Actions:
- Start with plugins that cover the most missing backend nodes.
- Install one plugin or one related plugin family at a time.
- Restart ComfyUI after each batch.
- Check startup logs for
IMPORT FAILED. - If imports fail, stop installing more and diagnose first.
Key rules:
- Prefer the plugin's documented install path when it exists.
- Use shallow clones to save time:
git clone --depth 1 --filter=blob:none --single-branch. - Add
GIT_LFS_SKIP_SMUDGE=1when cloning repos that may contain large model files. - After cloning, verify the repo is healthy. Some repos use Git LFS for source files, which means you can get pointer text instead of real code. See Plugin Management: The Git LFS Trap.
Stage 5: Fix Dependency Conflicts
Goal: Upgrade from "plugin folder exists" to "plugin can import and register nodes".
Actions:
- Check ComfyUI startup logs for
IMPORT FAILED. - Check Manager's failure info:
/v2/customnode/import_fail_info_bulk. - Run
pip checkin the same Python environment that starts ComfyUI. - Fix with the narrowest package change possible.
For the full dependency conflict resolution guide, see Dependency Conflicts.
Install-type rules:
| Install type | Command pattern |
|---|---|
| Official GitHub Windows portable package | From the portable package root: .\python_embeded\python.exe -s -m pip ... |
| Manual Git + venv install | Activate the venv, then run python -m pip ... |
| ComfyUI Desktop or managed launcher | Use the app's environment/terminal tools. Do not assume portable paths. |
Critical rules:
- Protect your core runtime. Never let a plugin's
requirements.txtsilently replacetorch,torchvision,torchaudio,numpy,pillow, or OpenCV without a reason. - Use
uvonly when it is installed for the same environment and you are sure it targets ComfyUI's Python. Speed is useful; the correct Python is more important. - Watch for auto-updaters. Some plugins update dependencies on startup and can silently change shared packages.
- Treat typos in declarations as plugin metadata problems. Do not make broad environment changes to satisfy a misspelled package name.
Common dependency traps:
nunchakuneeds an install path or wheel matching Python, PyTorch, CUDA, GPU architecture, and ComfyUI-nunchaku version.tritonandsageattentionon Windows should be treated as a linked acceleration cluster; use the Windows-specific guidance instead of normal Linux package advice.onnxruntime-gpumust match the CUDA/cuDNN family of the runtime stack; CPUonnxruntimeis enough for many workflows.- OpenCV packages share the
cv2namespace. Keep one OpenCV flavor installed. - The Hugging Face stack (
diffusers,transformers,huggingface-hub,accelerate) should be moved as a compatible set, not random one-package upgrades.
Stage 6: Minimal Compatibility Patches
Goal: Handle cases where plugin code itself is incompatible with your ComfyUI version.
Principles:
- Only make the smallest possible change.
- Goal is to restore node registration, not rewrite the plugin.
- If a dependency is optional and not used by your workflows, a lazy import is usually safer than making it a hard startup requirement.
- Keep notes about any local patch so you do not lose it on the next plugin update.
Real-world examples:
- Making
facenet_pytorcha lazy check so it does not crash the entire plugin on import. - Adding node name aliases so old workflows can find renamed nodes.
- Setting ComfyUI-Manager to offline mode when network requests hang startup.
Stage 7: Runtime Validation
Goal: Verify with actual running evidence, not just "the folder exists".
| Endpoint / Command | What it proves |
|---|---|
/system_stats | ComfyUI core is running and reports the active Python, PyTorch, and GPU state |
/object_info | Backend nodes are actually registered |
/v2/customnode/installed | Manager recognizes installed plugins |
/v2/customnode/import_fail_info_bulk | Startup import failures are visible |
pip check | Broken package relationships are known |
| Workflow validation script | Each workflow's required nodes exist |
The three-check rule: only when runtime endpoints, workflow validation, and dependency checks all pass together is the environment truly ready. For systematic error diagnosis at any stage, use the Troubleshooting Decision Tree.
After this stage: If errors still occur, they should point to missing model files, workflow input problems, VRAM limits, or runtime execution bugs, not missing plugins or basic dependencies.
Key Principles
- Do not pile plugins onto an old integration pack without a rollback plan.
- Do not guess node sources by plugin name; use workflow evidence and runtime evidence.
- "Folder exists" does not mean "plugin imported".
- "Plugin imported" does not mean "every runtime backend works".
- "Missing model" is different from "missing plugin".
- Do not sacrifice environment stability for an optional dependency your workflows do not use.
- All conclusions should be backed by logs, runtime APIs, or a workflow test.
Related Guides
- How to Group in ComfyUI
- Save Workflow in ComfyUI
- ComfyUI Dependency Conflicts
- ComfyUI Plugin Import Failed
- ComfyUI Triton Missing or Unavailable
- ComfyUI Nunchaku Missing
Need Expert Help?
Setting up complex workflow environments is exactly where Wonderful Launcher helps. If you are stuck at any stage, try it first to recover the environment automatically before another round of trial-and-error installs.
Source References
Start with Wonderful Launcher if this issue touches your real ComfyUI environment. Use the docs to understand the fix, and use the app to inspect the machine you already have.
Download Wonderful LauncherDid this fix your issue?
Your answer helps prioritize verified ComfyUI repairs.