Skip to main content
A workflow only runs if everything it references exists on the machine executing it — every custom node, checkpoint, LoRA, and VAE. This is the most common reason a graph that works on your desktop fails as a deployment.
Node and model availability is a property of the environment, not of your workflow. Deploying a version captures your graph — it does not bundle the nodes or weights the graph depends on.

​
Check before you build

The reliable source of truth is the environment itself, not documentation:
1

Open your workflow in ComfyUI

Browse the node list. If a custom node isn’t there, your graph can’t use it.
2

Check the model loaders

Open the checkpoint, LoRA, or VAE dropdowns in your graph. What’s listed is what’s installed.
3

Run it manually once

A manual run surfaces a missing dependency immediately, and far more clearly than a failed API run will.

​
When something you need is missing

Ask before redesigning. Getting a node or checkpoint added is often easier than rebuilding a graph to avoid it — and a rebuild that works around a missing dependency usually costs quality. If you can’t get it added, the fallbacks in order of preference:
  1. Substitute a node that’s already installed for the same operation
  2. Move that step out of ComfyUI — do it with a catalog model through the Pixio API and pass the result in
  3. Split the workflow so the unavailable step is handled elsewhere in your pipeline

​
Version your dependencies deliberately

Because dependencies live in the environment rather than your graph, they can change underneath a deployment that you haven’t touched.
A deployment that has worked for months can start failing without you changing anything, if a node or checkpoint it depends on changes in the environment. When an untouched deployment breaks, compare the run’s machine_id against a previously successful run before assuming your graph is at fault.
Practical habits:
  • Note what each deployment depends on — the custom nodes and weights it needs. Future-you debugging a failure will want that list.
  • Keep graphs as lean as possible. Every extra custom node is another thing that can go missing.
  • Test after any environment change rather than finding out through a production failure.
  • Prefer widely-used nodes over obscure ones. They’re likelier to stay installed.

​
Diagnosing a dependency failure

A missing node or model shows up as a failed run, not as a clear “not installed” message. To confirm that’s the cause: More in Troubleshooting.