ComfyUI Workflow Reuse Guide: A Troubleshooting Checklist from Import to Reproduction

After importing someone else’s ComfyUI workflow, you may see a canvas full of red nodes and an empty model list. The first time I hit this, it took me half an hour to realize the problem fell into three buckets: missing nodes, wrong model paths, and missing Python dependencies. This guide is not about installing ComfyUI from scratch. It focuses on one narrow problem: after you receive a workflow JSON or PNG, how do you fill the gaps, debug it step by step, and reproduce something close to the sample image? The core is a reusable troubleshooting checklist that moves from import to archive.

Why someone else’s workflow will not run

A ComfyUI workflow is essentially a node graph. JSON or PNG metadata records node types, parameter values, and connections, but it does not include model files, custom node plugins, or Python dependencies. When you import a shared workflow, whatever is missing from your local environment becomes visible immediately.

A red node means ComfyUI cannot find the corresponding node type. Some nodes are built-in core nodes and should not be missing; others are third-party custom nodes that you have not installed locally. After the nodes are fixed, the dropdown in Load Checkpoint or Load LoRA may still be empty because the model file is not in the default directory or the path configuration is wrong. Even after that, some custom nodes may report missing Python packages such as insightface or onnxruntime.

These three problem types often stack on top of each other. One workflow may require three custom nodes, two checkpoint models, and one Python package at the same time. Without a systematic order, it is easy to get stuck on one step and install a pile of unrelated packages. The checklist below separates these problems and handles them by priority.

Two workflow sources: JSON vs PNG Metadata

People usually share workflows in two forms: a standalone JSON file, or a PNG image that still contains metadata. JSON is the native export format from ComfyUI and keeps the node information. PNG metadata is an embedded form; some generated images contain workflow data inside the image file, but only if the creator preserved it.

Dragging in a JSON file

When you receive a JSON file, drag it directly into the ComfyUI interface. The interface loads the node graph and shows all connections. This is the most reliable approach because JSON is not affected by image compression and keeps the node information intact.

If the JSON was exported from ComfyUI, the imported layout should match the author’s layout. If it looks scrambled, the export may come from a different ComfyUI version, or the JSON may have been edited manually.

Requirements for loading PNG metadata

Some AI-generated PNG images embed workflow metadata. You can load them by dragging the image into ComfyUI, or by using “Load” in the menu and selecting the PNG file.

The requirement is simple: the image must still contain the metadata. Many social platforms and image hosts compress images or strip metadata during upload, which removes the workflow data. If the image came from a social post, there is a good chance the metadata is already gone and dragging it into ComfyUI will only create an empty canvas.

Prefer JSON files. PNG metadata is useful when the author is saving their own generation history, but it is not a reliable cross-platform sharing format.

JSON vs PNG Metadata comparison

Before importing a workflow, check the source. A matching node list, model list, or README is safer than relying on JSON or PNG alone.

Red nodes: distinguish Core Node from Custom Node

After importing a workflow, red nodes may appear with titles such as “Missing” or “Unknown node type”. Do not install packages immediately. First identify the node type, then decide where to search.

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

Core Node and Custom Node

Core nodes are built into ComfyUI and ship with the main program. Common examples include Load Checkpoint, KSampler, VAE Decode, and Save Image. If these nodes turn red, the ComfyUI installation is probably incomplete and you should reinstall or check the version.

Custom nodes are third-party extension nodes that must be installed separately. Common examples include IP-Adapter Apply, ControlNet Apply, and FaceDetailer. Most red nodes in shared workflows are missing custom nodes.

To judge quickly, look at the node name. If it includes a known extension prefix such as IPAdapter, ControlNet, or Impact, it is probably a custom node. If you are not sure, right-click in ComfyUI, open “Add Node”, and search for the node name. Core nodes appear in the default list; missing custom nodes do not.

How to find Custom Nodes

After you confirm that a node is custom, use three search paths.

ComfyUI Registry: this is the official registry system for nodes. Visit registry.comfy.org and search for the node name or extension package name. The Registry shows the source, installation method, and dependency requirements. Some nodes can be installed through the Manager and Registry ecosystem when your ComfyUI version supports it.

ComfyUI Manager: this is a third-party extension management tool. If Manager is installed locally, use the ComfyUI menu, then “Manager” and “Install Custom Nodes”, and search for the node name. Manager lists matching extension packages and their installation status. It is not a core ComfyUI feature; its stability depends on community maintenance.

GitHub search: if Registry and Manager do not find it, search GitHub for the node name. Many custom node authors list node names in their README. After you find the repository, follow its README and clone it into the custom_nodes directory.

Python dependency issues

Some custom nodes need extra Python packages. For example, IP-Adapter may require insightface, and some ControlNet extensions may require onnxruntime.

To install them, enter the custom node repository and read its README or requirements.txt. From the ComfyUI root directory, run:

pip install -r custom_nodes/node-directory/requirements.txt

Some README files directly provide a pip install package-name command. Follow the package instructions instead of guessing.

Confirm which nodes are actually missing

A workflow may reference more than a dozen custom nodes, but you only need the ones that the imported workflow actually uses. After import, the red node list is your real missing list. Do not install every popular node package blindly; each package can increase startup time and introduce potential conflicts.

Model not found: check folders and external model libraries

After the nodes are fixed, nodes such as Load Checkpoint, Load LoRA, or Load VAE may still show empty dropdowns. Model files are not shared with the JSON. You need to place them manually in the ComfyUI models directory.

ComfyUI models directory structure

When ComfyUI starts, it scans subfolders under models and loads model files by type. Common folders include:

If a Load Checkpoint node in the workflow points to sdxl_base.safetensors, put that model at models/checkpoints/sdxl_base.safetensors. The node dropdown will show the models in that folder.

What extra_model_paths.yaml is for

If your model library lives elsewhere, such as a shared NAS or a centralized model folder, you do not need to copy every file into models. Use extra_model_paths.yaml to point ComfyUI at external paths.

The configuration file is in the ComfyUI root directory and uses YAML. Example:

my_custom_config:
  base_path: /path/to/external
  checkpoints: models/checkpoints
  loras: models/loras
  vae: models/vae
  controlnet: models/controlnet

When ComfyUI starts, it scans the configured paths and merges them with the default models directory. The exact format can change with versions, so use the official documentation or startup hints as the final reference.

Confirm the model version

Model names can be misleading. Two models with the same file name may come from different versions, and two files with different names may be the same model renamed by someone else. When reproducing a workflow, confirm these details:

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

• checkpoint name and version
• LoRA name, version, and weight
• VAE file
• ControlNet or IP-Adapter model
• whether the author used a quantized, pruned, or merged model

Model version is one of the biggest factors behind different outputs. If you cannot find the exact file, use a model from the same architecture as a temporary replacement, but record that the result will not match exactly.

Why the same workflow still does not produce the same image

Even after you install the nodes and models, the result may still differ from the sample image. That is normal. A workflow is only part of the reproduction environment.

Parameter impact table

Model version is the biggest variable

If the sample image used an SDXL model but you replace it with an SD1.5 model, the result will be completely different. Even within the same architecture, different checkpoint versions can shift style, faces, lighting, and texture.

Before adjusting prompts, confirm that the base model is right. If the author did not provide the model version, treat the reproduction target as approximate.

Aim for similar style and composition, not perfect identity

For most shared workflows, the realistic target is a similar style and composition, not an identical image. Exact reproduction requires the same model, same parameters, same custom node versions, same reference images, and sometimes the same runtime backend. If one condition changes, the output can drift.

A practical method is to run the main path at a smaller size first. Disable nonessential post-processing nodes, fix the seed, and check whether the basic composition is close. Then restore upscaling, face repair, or color-processing nodes one by one.

Workflow reuse checklist you can copy

Use this list each time you receive a workflow.

Step 1: Confirm the source

• Save the original JSON or PNG file first.
• Record where it came from: author, platform, post, or repository.
• Check whether it has a README, model list, or node list.
• If it only comes as a PNG, confirm whether metadata is preserved.
• Do not overwrite your default workflow before confirming the source.

If the source is unclear and the workflow asks you to install many unknown custom nodes, be cautious. A workflow is executable configuration, not just a picture.

Step 2: Install the nodes

• Import the workflow and record all red node names.
• Separate core nodes from custom nodes.
• Search custom nodes in Registry or Manager first.
• If you cannot find them, search GitHub and read the README.
• Install one batch, restart ComfyUI, and check again.
• If it is still red, check requirements.txt in the custom node folder before changing model paths.

Do not install random node packs just because a tutorial mentions them. Install only what this workflow actually needs.

Step 3: Map the models

• Check the model names referenced by Load Checkpoint, Load LoRA, Load VAE, ControlNet, and IP-Adapter nodes.
• Put checkpoints in models/checkpoints.
• Put LoRA files in models/loras.
• Put VAE files in models/vae.
• Put ControlNet and IP-Adapter files into their matching folders.
• If you use an external model library, configure extra_model_paths.yaml.
• Restart ComfyUI and check whether the model appears in the dropdown.

Model version mismatches have the strongest impact on reproduction, so confirm them first.

Step 4: Lock the parameters

After the models are in place, check the workflow parameters.

• Check whether the seed is fixed. If it is not fixed, you cannot reproduce the same image; you can only tune the style.
• Check the sampler, steps, CFG Scale, and image size.
• Check whether a VAE is loaded and whether LoRA weights are set.
• Compare the sample image with the parameters and look for obvious differences.
• If the author notes parameter changes, apply those notes.

The author may have tuned parameters after exporting the JSON. When the sample image and JSON do not match, align them manually.

Step 5: Run a minimal test

After confirming parameters, do a simple test first.

• Run once with a simple prompt such as “a cat sitting on a chair”.
• Check whether the output is normal: no error, no blank image, no obvious collapse.
• If it errors, read the terminal log and identify the node or model that failed.
• If output is normal, adjust the prompt and parameters step by step toward the sample effect.
• Do not start with a complex prompt; complex prompts can hide node or model problems.

Step 6: Archive the name

After reproduction works, save and organize the workflow.

• Save the workflow as a new JSON file.
• Suggested naming: [topic]-[model-name]-[date]-v1.json. Example: portrait-sdxl-base-20260623-v1.json.
• Record model version information with a matching README.txt, not by relying on JSON comments.
• Record the checkpoint name and version, LoRA name and weight, VAE, sampler parameters, and key settings.
• If you plan to share it later, include a node list, model list, sample image, and parameter notes. Do not share the model files themselves.

You can copy this checklist locally and tick it off each time you reuse a workflow.

Workflow management: naming and sharing advice

After reproduction succeeds, organization prevents you from repeating the same debugging work next time. When you share a workflow, complete context also reduces the recipient’s troubleshooting time.

Naming convention

Messy file names make workflows hard to find, especially after you collect dozens of them.

🔥 Stop wasting months on unwanted products! Validate your SaaS selling points with Adsterra on a tiny budget →

Test MVP Now →Ad

Suggested format: [topic]-[model-name]-[date]-v1.json

Examples:

• portrait-sdxl-base-20260623-v1.json: portrait workflow, SDXL Base model, June 23, 2026, version 1
• landscape-sd15-controlnet-20260620-v1.json: landscape workflow with SD1.5 and ControlNet

The topic can be the use case: portrait, landscape, anime, product, or concept-art. Use a short name for the main checkpoint. Use the YYYYMMDD date format. Use v1 and v2 to distinguish iterations.

How to record model versions

The workflow JSON itself usually records the model file name, not the full model version. If a model library has multiple versions with the same name, you may not know which one you used next time.

Use a matching README.txt

Create a README-[file-name].txt next to the workflow and record checkpoint source, LoRA weight, VAE source, sampler, steps, CFG, image size, and any other setting that visibly changes the result.

Use README.txt as the main source for model version records. It is more compatible and easier to package together with JSON and sample images.

Advice for sharing a Workflow

When you share a workflow, complete information helps the recipient get started faster.

Include:

• the complete workflow file, highest priority.
• all custom node names and sources, such as Registry links or GitHub repositories.
• checkpoint, LoRA, VAE, ControlNet, and other model names plus source notes, without direct download links.
• one generated result so the recipient knows the reproduction target.
• if the JSON parameters differ from the sample image, document the actual parameters.

Do not include:

• licensing is complicated, so do not share the files directly.
• a model library page is acceptable, but direct download links are risky.
• if a custom node has special dependencies, list the package names and ask the recipient to read the README for the exact command.

Add a short README with these details. The recipient can then work through the checklist instead of guessing.

Next reading

If you have not installed ComfyUI yet, start with the complete ComfyUI beginner guide to understand installation, model folders, and your first image. For prompt tuning, read Prompt Engineering for Business. For cross-media AI-assisted creation, see Cross-media creative workflows. For running large language models locally, read Ollama introduction.