ComfyUI custom nodes: the new Manager, Nodes 2.0, and what breaks in production (2026)
ComfyUI custom nodes power every good workflow, and they are also the first thing to break in production. Here is the new Manager, Nodes 2.0, and how to ship a node graph that survives real traffic.
Three custom nodes. One missing pip dependency. A workflow that ran fine on Friday and threw a red error box on Monday because an author pushed a breaking update over the weekend.
That is the part of ComfyUI nobody puts in the thumbnail.
Custom nodes are why ComfyUI won. They are also why a workflow that worked on your machine refuses to load on anyone else's. We have shipped enough ComfyUI graphs into a live product to know the pattern: the fun part is wiring the nodes, and the expensive part is everything that happens after, when versions drift and dependencies fight each other.
This post walks through the new ComfyUI Manager and the Nodes 2.0 beta, both of which change how you install and pin custom nodes in 2026. Then it gets to the harder question: what happens to all those custom nodes the day your workflow stops being a hobby and starts taking real traffic.
Credit for the walkthrough of the new Manager and Nodes 2.0 goes to Code Crafters Corner. Watch the source video for the click-by-click install. The production framing below is ours.
What changed: the Manager moved out of the top bar
The ComfyUI Manager is becoming a separate extension component instead of a button bolted onto the top bar, which makes node management faster and a little safer.
If your ComfyUI still shows the Manager button up top, you are on the old setup. The 2026 update pulls extension management into its own integrated system, reached through the menu under "manage extensions" rather than a fixed top-bar button.
The install itself is still a manual step the first time. On a Portable build you point the embedded Python at manager_requirements.txt and run a pip install, then start ComfyUI with the --enable-manager flag. Desktop builds with automatic updates pull it for you.
One honest caveat from the source video: the new Manager is not a one-to-one replacement for the original. Some features from the old "OG" Manager are not replicated yet. So if a workflow you depend on relies on a Manager feature that has not moved over, do not delete the old one on day one.
The UI is the visible win. The old list view became a card-based layout: each custom node pack shows its category, a description, the nodes it ships, and sometimes a preview thumbnail. You can read what a pack does before you install it, instead of installing it to find out.
Version pinning is the feature that matters most
The single most useful thing in the new Manager for anyone past the hobby stage is the per-node version selector, because pinning a custom node version is what stops a workflow from breaking when an author ships an update.
In the new Manager you click the version label on a node pack and choose a specific release. That sounds small. It is the difference between a graph that runs the same way in March and in November, and a graph that silently changes behavior because an upstream author refactored a node.
Here is the failure we have watched happen more than once. A workflow uses a popular custom node. The author improves it, renames an input, bumps the major version. Anyone who installed "latest" now has a graph that will not load because the node's inputs no longer match the saved JSON. Anyone who pinned the version is fine.
(We learned this the expensive way, with a 2am page, before we pinned everything.)
The Manager makes the rest of the lifecycle easier too. The "missing" section flags custom nodes a workflow needs but you do not have, so a shared JSON tells you exactly what to install. "Update available" lists what is out of date, and "update all" exists for when you actually want to move forward on purpose. The install itself is now non-blocking: you can queue several node packs, keep working, and apply changes without losing the edits you made while it restarted.
Nodes 2.0 is a real upgrade, and it is still beta
Nodes 2.0 gives ComfyUI a cleaner, clearer node design, but it is in beta for a reason, and a few common patterns are broken today.
The good parts are genuinely good. The new node header has clear labeling instead of a mystery circle you had to hover to understand. Dropdowns are unified under the node and resize with it. Inputs and outputs are distinct and sit on the edge of the node. A bypassed or disabled node shows its state at the top, so you are not reading node colors like tea leaves.
Then the beta bites.
Enable Nodes 2.0 on an existing workflow and the nodes are slightly larger than before. Move them, change your mind, switch back, and they overlap into a pile because the old layout still assumes the previous sizes. The source video's advice is the right advice: try Nodes 2.0 on a blank canvas first, not on a workflow you care about.
Some custom nodes do not work with 2.0 yet. The example that stings: a seed primitive you fan out to two places. Switch to 2.0 and you lose the randomize-or-fix control on that seed. The drag-right-to-increment gesture, the fast way to nudge a number, is gone too. You click, type, or use plus and minus.
None of this is a reason to avoid 2.0. It is a reason to keep it off your production graph until the custom nodes you depend on declare support. Which is exactly the theme of this post.
What custom nodes do to you in production
Every custom node you add is a dependency you now own, and in production that dependency is a thing that can break a paying user's request at 3am.
On your own machine, a broken custom node is an annoyance. You restart, you roll back, you move on. Behind real users, the same break is a failed job, a refund email, and a support ticket.
The custom-node ecosystem is ComfyUI's superpower and its sharpest edge. Three things go wrong at scale that never bother you locally:
- Author updates you did not ask for. An "update all" on the wrong day, or an auto-update on a fresh deploy, pulls a breaking node version. Your saved workflow JSON no longer validates.
- Dependency conflicts. Two custom node packs want different versions of the same Python library. Locally you got lucky with install order. On a clean machine, one of them loses.
- Nodes that vanish. A pack gets renamed, abandoned, or pulled. Now "missing" is not a yellow warning, it is a workflow that will not load on the box serving your traffic.
The fix is not "stop using custom nodes." Custom nodes are the workflow. The fix is treating the node graph the way you treat any other code dependency: pin every version, freeze the environment, and stop letting the install run "latest" on a machine that users depend on. The Manager's version selector and missing-node detection are the tools for the first half. The second half is where you run it.
The honest part: a pinned local graph is still a single machine
Pinning your custom nodes makes a workflow reproducible, but reproducible on one desktop is not the same as available to thousands of users, and that gap is the real production problem.
Say you did everything right. Every node pinned, environment frozen, Nodes 2.0 left off until it stabilizes. You now have a workflow that runs identically every time. On your machine. While your machine is awake.
A product needs more than that. It needs the same graph to answer at 3am, to handle a hundred concurrent requests without a queue you hand-built, and to survive the GPU you rented going down without taking the whole feature with it. ComfyUI runs one graph at a time on one card. It was designed to design workflows, not to be the live backend for a SaaS. (We have run that math on a single box, it does not end well past a few users a minute.)
This is where the work splits cleanly. ComfyUI is the right place to build and pin the workflow. It is the wrong place to host it for real traffic. The honest move is to design and version the graph in ComfyUI, then ship that exact JSON through infrastructure that handles concurrency, retries, and failover for you.
ComfyUI Deploy takes the workflow JSON you exported, custom nodes and all, and runs it as a hosted endpoint on a real GPU. You keep the graph you tuned, including the pinned node versions. You drop the part where you babysit a GPU, manage cold starts, and pray no custom node auto-updated overnight. For a fuller look at the deploy options, including self-host and serverless tradeoffs, see self-host vs serverless vs managed.
Calling your workflow as an API
Once the workflow is hosted, you call it over HTTP like any other API: post your inputs, get a run ID, and poll until it finishes.
The shape is the same whether you are running a single model or a full custom-node graph. Post to the run endpoint, then poll the run ID:
# Kick off a run
curl -X POST https://api.runflow.io/v1/models/{owner}/{slug}/runs \
-H "Authorization: Bearer rf_live_your_key" \
-H "Content-Type: application/json" \
-d '{
"input": {
"prompt": "a silver knight in a forest, cinematic lighting, sharp focus",
"width": 1024,
"height": 1024
}
}'You get back a run ID. Poll it until the status is done:
# Poll until finished
curl https://api.runflow.io/v1/runs/RUN_ID \
-H "Authorization: Bearer rf_live_your_key"The same two calls work in any language. Your app sends inputs, the cloud runs your exact graph with its pinned custom nodes, and you get the output back. No ComfyUI process running on your laptop, no Manager to babysit, no "update all" that can break a live request. For the full surface, including async webhooks and the workflow-as-endpoint path, read the ComfyUI API developer guide. For ready-made graphs to start from, the production-ready workflows roundup is a good shortlist, and the model catalog shows what runs hosted out of the box.
The pricing model that makes this work is simple fixed per-call, so cost is predictable per user instead of per GPU hour. For a team, that usually lands well under what an in-house GPU fleet plus the DevOps to keep it warm would cost, often around 70% cheaper than running it in-house, and with no AI team required to keep the lights on.
Frequently asked questions
What are custom nodes in ComfyUI?
Custom nodes are community-built extensions that add new operations to ComfyUI: upscalers, detailers, controlnets, samplers, and more. They are what let a node graph do things the core install cannot. They are also third-party code, so each one is a dependency you take on.
What is the new ComfyUI Manager?
The 2026 update moves extension management out of the top bar into a separate, integrated component reached under "manage extensions." It uses a card-based UI, supports per-node version selection, flags missing nodes, and installs without blocking your work. It is not a one-to-one replacement for the old Manager yet, so some legacy features have not moved over.
How do I install custom nodes with the new Manager?
Open the Manager, browse or search the card list, read the pack's description and node list, click install, then apply changes to restart. The first-time setup of the new Manager itself still needs a manual pip install against manager_requirements.txt and the --enable-manager flag, unless you are on a desktop build with auto-updates.
What is Nodes 2.0 in ComfyUI?
Nodes 2.0 is a redesigned node UI: clearer headers, unified resizable dropdowns, distinct edge-mounted inputs and outputs, and visible bypass state. It is in beta. Enabling it on an existing workflow can cause node overlap, and some custom nodes lose features like the seed randomize-or-fix control. Try it on a blank canvas first.
Should I use Nodes 2.0 in production?
Not yet. It is genuinely nicer to work with, but it is beta and breaks a few common patterns and custom nodes. Keep it off any graph that serves real traffic until the custom nodes you depend on declare support.
How do I stop custom nodes from breaking my workflow?
Pin every custom node to a specific version using the Manager's version selector, freeze your environment, and never run "update all" or auto-update on a machine that serves users. Most breakage comes from an upstream author shipping a change you did not ask for.
Why does a workflow that works on my machine fail on another?
Usually a custom node mismatch: a missing pack, a different node version, or a dependency conflict that your local install order happened to avoid. The Manager's "missing" section tells you which nodes a shared workflow JSON needs.
Can I run a full custom-node workflow as an API?
Yes. Export the workflow JSON from ComfyUI and run it on a hosted endpoint like ComfyUI Deploy. Your app posts inputs, the cloud runs the exact graph with its custom nodes, and you poll a run ID for the result. No local ComfyUI process required.
Do hosted ComfyUI services keep my pinned node versions?
A good one runs your exact exported graph, including the custom node versions you pinned. That is the point: you tune and freeze the workflow in ComfyUI, then ship that frozen version so it behaves identically under load.
What does it cost to run ComfyUI workflows by API?
Calling a hosted workflow is priced per call, which makes cost predictable per user rather than per GPU hour. For most teams that is well below the cost of an in-house GPU fleet plus the DevOps to maintain it, and it needs no dedicated AI team.
Where to go next
You now have both halves: how to manage and pin custom nodes in the new ComfyUI, and how to stop those nodes from breaking once real users show up. Here is the order that works.
- Update to the new ComfyUI Manager and switch your install workflow to the card-based UI.
- Pin every custom node to a specific version. Do this before you share or deploy anything.
- Test Nodes 2.0 on a blank canvas, and keep it off your production graph until your nodes support it.
- Use the "missing" section to verify a shared workflow JSON has every node it needs.
- When the workflow is solid, export the JSON and host it with ComfyUI Deploy.
- Wire your app to the run-and-poll API, and add a fallback so one bad GPU minute does not fail a job.
- Read the ComfyUI API developer guide for the failure modes to expect at scale.
Start free at runflow.io.
Want custom benchmarks for your workload?
We'll run our evaluation pipeline against your production data, for free.
Talk to Founders