> ## Documentation Index
> Fetch the complete documentation index at: https://support.myapps.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom nodes & models

> What your workflow can rely on in the ComfyUI environment

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.

<Info>
  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.
</Info>

## Check before you build

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

<Steps>
  <Step title="Open your workflow in ComfyUI">
    Browse the node list. If a custom node isn't there, your graph can't use it.
  </Step>

  <Step title="Check the model loaders">
    Open the checkpoint, LoRA, or VAE dropdowns in your graph. What's listed is what's installed.
  </Step>

  <Step title="Run it manually once">
    A manual run surfaces a missing dependency immediately, and far more clearly than a failed API run will.
  </Step>
</Steps>

## 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](/integrations/overview) 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.

<Warning>
  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.
</Warning>

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:

| Check                           | What it tells you                                           |
| ------------------------------- | ----------------------------------------------------------- |
| Run the same graph **manually** | Fails there too → dependency or graph problem, not the API  |
| The run's `workflow_version_id` | Confirms which revision actually executed                   |
| The run's `machine_id`          | Two machines behaving differently points at the environment |
| Remove the suspect node         | If it then runs, you've found it                            |

More in [Troubleshooting](/comfyui/troubleshooting).

## Related

* [Workflows & deployments](/comfyui/workflows-and-deployments) — why deploying, not saving, is what changes behavior
* [Running a workflow](/comfyui/running-a-workflow) — statuses and polling
* [Overview](/comfyui/overview) — how Pixio ComfyUI differs from the catalog API