October 2025 archive: reviewing custom-node provenance and updates
A custom node adds code and dependencies to the environment running your workflows. Review where it comes from, what permissions and dependencies it needs, and how you will test or reverse an update before adding it to a working installation.
Establish provenance before installation
Identify the maintainer repository linked by the extension's documentation. Record the repository URL and selected revision with the workflow. Similar names, search rankings or a copied installation command do not establish that two packages come from the same maintainer.
Read the installation requirements and supported ComfyUI versions. Check whether the workflow really needs that extension or whether a maintained built-in route meets the task. Do not install a broad collection of unrelated packages merely to suppress a missing-node message in an unfamiliar graph.
Review the operational boundary
Treat extension installation as a software change, not as importing an inert image. Review requested downloads, external services and filesystem access. Keep sensitive project material and production credentials out of an initial trial environment until the execution path has been understood and approved.
A public repository is useful provenance, but its existence is not a security audit. Neither popularity nor a successful test proves the absence of harmful behaviour. Record which checks you performed and escalate unresolved questions to someone qualified to review the relevant code and deployment boundary.
Test a change against a known workflow
Preserve the working environment description and an existing output before updating. Test the selected revision in a recoverable copy using permitted inputs. Change one dependency set at a time so a new failure can be associated with an identifiable change.
Verify node names, input types and output connections after the update. Read the maintainer's actual feature description; for example, a routing switch is not automatically a quality evaluator. Inspect the final saved output and capture errors rather than checking only whether the graph opens.
Keep a clear maintenance record
Write down the accepted version, source, test case and rollback route. Schedule review when an extension changes or a workflow starts failing. Retain the last known working graph and avoid silently mixing nodes from incompatible revisions across different operators' machines.
The original archive did not provide enough evidence to substantiate numerical claims about security incidents. This revision is therefore a maintenance checklist, not an assurance that any named extension is safe. Use primary maintainer information, a bounded test and an explicit permission decision; preserve uncertainty when a claim cannot be independently checked.
Sources and further reading
October 2025: dated evidence supplement
Added 2026-09-29. Keep the corrected custom-node provenance guide; distinguish a hosted Partner Node from locally executed model weights.
Comfy announced Sora 2 Partner Nodes on 8 October. This corrects the former January page's implication that their arrival was a January event. Comfy: Sora 2 Partner Nodes (2025-10-08; company announcement).
Editorial interpretation, not a measured result. A common graph interface can combine different execution and data boundaries. Integration does not establish local execution, vendor independence or permission to submit confidential inputs.
No additional financing announcement is established for this month by the reviewed sources. This is not proof that no financing occurred. See the dated funding register; past totals and valuations are not new monthly raises.