LogoWonderful Launcher
  • Home
  • Pricing
  • Docs
  • Download

Workflow Environment Setup

Needs verification

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:

  1. Pick the install type first: official GitHub Windows portable package, ComfyUI Desktop, manual Git + venv, or a managed launcher.
  2. For the official portable package, treat the extracted folder containing run_*.bat, python_embeded, and ComfyUI as the package root.
  3. For a manual Git install, activate the intended venv before running commands.
  4. 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:

  1. Recursively scan your workflow directory, not just top-level files.
  2. Extract all backend node types from workflow JSON files.
  3. Exclude frontend-only nodes that do not need backend registration:
    • Note, Reroute, MarkdownNote
    • Fast 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:

  1. Check the workflow JSON for cnr_id or registry metadata.
  2. Check Node name for S&R or saved search/replace metadata.
  3. Check whether any repo in your existing custom_nodes/ already covers it.
  4. Check ComfyUI-Manager's installed package info.
  5. Check the Manager's extension-node-map.json and nodename_pattern rules.
  6. 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:

  1. Start with plugins that cover the most missing backend nodes.
  2. Install one plugin or one related plugin family at a time.
  3. Restart ComfyUI after each batch.
  4. Check startup logs for IMPORT FAILED.
  5. 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=1 when 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:

  1. Check ComfyUI startup logs for IMPORT FAILED.
  2. Check Manager's failure info: /v2/customnode/import_fail_info_bulk.
  3. Run pip check in the same Python environment that starts ComfyUI.
  4. Fix with the narrowest package change possible.

For the full dependency conflict resolution guide, see Dependency Conflicts.

Install-type rules:

Install typeCommand pattern
Official GitHub Windows portable packageFrom the portable package root: .\python_embeded\python.exe -s -m pip ...
Manual Git + venv installActivate the venv, then run python -m pip ...
ComfyUI Desktop or managed launcherUse the app's environment/terminal tools. Do not assume portable paths.

Critical rules:

  • Protect your core runtime. Never let a plugin's requirements.txt silently replace torch, torchvision, torchaudio, numpy, pillow, or OpenCV without a reason.
  • Use uv only 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:

  • nunchaku needs an install path or wheel matching Python, PyTorch, CUDA, GPU architecture, and ComfyUI-nunchaku version.
  • triton and sageattention on Windows should be treated as a linked acceleration cluster; use the Windows-specific guidance instead of normal Linux package advice.
  • onnxruntime-gpu must match the CUDA/cuDNN family of the runtime stack; CPU onnxruntime is enough for many workflows.
  • OpenCV packages share the cv2 namespace. 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_pytorch a 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 / CommandWhat it proves
/system_statsComfyUI core is running and reports the active Python, PyTorch, and GPU state
/object_infoBackend nodes are actually registered
/v2/customnode/installedManager recognizes installed plugins
/v2/customnode/import_fail_info_bulkStartup import failures are visible
pip checkBroken package relationships are known
Workflow validation scriptEach 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

  1. Do not pile plugins onto an old integration pack without a rollback plan.
  2. Do not guess node sources by plugin name; use workflow evidence and runtime evidence.
  3. "Folder exists" does not mean "plugin imported".
  4. "Plugin imported" does not mean "every runtime backend works".
  5. "Missing model" is different from "missing plugin".
  6. Do not sacrifice environment stability for an optional dependency your workflows do not use.
  7. 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

  • ComfyUI troubleshooting overview
  • ComfyUI custom node troubleshooting guide
  • ComfyUI model troubleshooting guide
  • ComfyUI Manager installation guide

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 Launcher

Did this fix your issue?

Your answer helps prioritize verified ComfyUI repairs.

Table of Contents

The Core Principle
The 7 Stages
Stage 1: Build the Base
Stage 2: Audit Workflows and Missing Nodes
Stage 3: Map Missing Nodes to Plugins
Stage 4: Install Plugins in Batches
Stage 5: Fix Dependency Conflicts
Stage 6: Minimal Compatibility Patches
Stage 7: Runtime Validation
Key Principles
Related Guides
Need Expert Help?
Source References