Skip to main content

Overview

The ComfyUI V3 schema introduces a more organized way of defining nodes, and future extensions to node features will only be added to V3 schema. You can use this guide to help you migrate your existing V1 nodes to the new V3 schema.

Core Concepts

The V3 schema is kept on the new versioned Comfy API, meaning future revisions to the schema will be backwards compatible. comfy_api.latest will point to the latest numbered API that is still under development; the version before latest is what can be considered ‘stable’. Version v0_0_2 is the current (and first) API version so more changes will be made to it without warning. Once it is considered stable, a new version v0_0_3 will be created for latest to point at.

V1 vs V3 Architecture

The biggest changes in V3 schema are:
  • Inputs and Outputs defined by objects instead of a dictionary.
  • The execution method is fixed to the name ‘execute’ and is a class method.
  • def comfy_entrypoint() function that returns a ComfyExtension object defines exposed nodes instead of NODE_CLASS_MAPPINGS/NODE_DISPLAY_NAME_MAPPINGS
  • Node objects do not expose ‘state’ - def __init__(self) will have no effect on what is exposed in the node’s functions, as all of them are class methods. The node class is sanitized before execution as well.

V1 (Legacy)

V3 (Modern)

Migration Steps

Going from V1 to V3 should be simple in most cases and is simply a syntax change.

Step 1: Change Base Class

All V3 Schema nodes should inherit from ComfyNode. Multiple layers of inheritance are okay as long as at the top of the chain there is a ComfyNode parent. V1:
V3:

Step 2: Convert INPUT_TYPES to define_schema

Node properties like node id, display name, category, etc. that were assigned in different places in code such as dictionaries and class properties are now kept together via the Schema class. The define_schema(cls) function is expected to return a Schema object in much the same way INPUT_TYPES(s) worked in V1. Supported core Input/Output types are stored and documented in comfy_api/{version} in _io.py, which is namespaced as io by default. Since Inputs/Outputs are defined by classes now instead of dictionaries or strings, custom types are supported by either defining your own class or using the helper function Custom in io. Custom types are elaborated on in a section further below. A type class has the following properties:
  • class Input for Inputs (i.e. Model.Input(...))
  • class Output for Outputs (i.e. Model.Output(...)). Note that all types may not support being an output.
  • Type for getting a typehint of the type (i.e. Model.Type). Note that some typehints are just any, which may be updated in the future. These typehints are not enforced and just act as useful documentation.
V1:
V3:

Step 3: Update Execute Method

All execution functions in v3 are named execute and are class methods. V1:
V3:

Step 4: Convert Node Properties

Here are some examples of property names; see the source code in comfy_api.latest._io for more details.

Step 5: Handle Special Methods

The same special methods are supported as in v1, but either lowercased or renamed entirely to be more clear. Their usage remains the same.

Validation (V1 → V3)

The input validation function was renamed to validate_inputs. V1:
V3:

Lazy Evaluation (V1 → V3)

The check_lazy_status function is class method, remains the same otherwise. V1:
V3:

Cache Control (V1 → V3)

The functionality of cache control remains the same as in V1, but the original name was very misleading as to how it operated. V1’s IS_CHANGED function signals execution not to trigger rerunning the node if the return value is the SAME as the last time the node was ran. Thus, the function IS_CHANGED was renamed to fingerprint_inputs. One of the most common mistakes by developers was thinking if you return True, the node would always re-run. Because True would always be returned, it would have the opposite effect of only making the node run once and reuse cached values. An example of using this function is the LoadImage node. It returns the hash of the selected file, so that if the file changes, the node will be forced to rerun. V1:
V3:

Step 6: Create Extension and Entry Point

Instead of defining dictionaries to link node id to node class/display name, there is now a ComfyExtension class and an expected comfy_entrypoint function to be defined. In the future, more functions may be added to ComfyExtension to register more than just nodes via get_node_list. comfy_entrypoint can be either async or not, but get_node_list must be defined as async. V1:
V3:

Input Type Reference

Already explained in step 2, but here are some type reference comparisons in V1 vs V3. See comfy_api.latest._io for the full type declarations.

Basic Types

control_after_generate

Int and Combo inputs support a control_after_generate parameter that adds a control widget for automatically changing the value after each generation. In V1 this was a plain bool; in V3 you can use the io.ControlAfterGenerate enum for explicit control. Passing True is equivalent to io.ControlAfterGenerate.randomize.

ComfyUI Types

Combo (Dropdowns/Selection Lists)

Combo types in V3 require explicit class definition. V1:
V3:

Schema Reference

The Schema dataclass defines all properties of a V3 node. Here is a complete reference of all available fields:

Common Input Parameters

All input types share these base parameters: Widget inputs (Int, Float, String, Boolean, Combo) additionally support:

Advanced Features

Hidden Inputs

Hidden inputs provide access to execution context like the prompt metadata, node ID, and other internal values. They are not visible in the UI. In V1, hidden inputs were declared as a "hidden" key in INPUT_TYPES. In V3, they are declared via the hidden parameter on the Schema, and their values are accessed via cls.hidden. V1:
V3:
Available hidden values:
Some hidden values are automatically added based on Schema flags. Output nodes (is_output_node=True) automatically receive prompt and extra_pnginfo. API nodes (is_api_node=True) automatically receive auth tokens.

UI Helpers

V3 provides built-in UI helpers in the ui module to handle common patterns like previewing and saving files. Pass them to io.NodeOutput via the ui parameter.

Preview Helpers

Preview helpers save temporary files and return UI data for in-node display.

Save Helpers

Save helpers provide methods for saving files to the output directory with proper metadata embedding. They are typically used in output nodes.
Passing cls=cls to save/preview helpers allows them to automatically embed workflow metadata (prompt, extra_pnginfo) in the saved files. Make sure to include io.Hidden.prompt and io.Hidden.extra_pnginfo in your schema’s hidden list, or set is_output_node=True which adds them automatically.

Returning Raw UI Dicts

If you need to return UI data that doesn’t have a helper, you can pass a dict directly:

Output Nodes

For nodes that produce side effects (like saving files). Same as in V1, marking a node as output will display a run play button in the node’s context window, allowing for partial execution of the graph.

Custom Types

Create custom input/output types either via class definition or the Custom helper function.

MultiType Inputs

MultiType allows an input to accept more than one type. This is useful when a node can operate on different data types through the same input slot. If the first argument (id) is an instance of an Input class instead of a string, that input will be used to create a widget with its overridden values. Otherwise, the input is socket-only.

MatchType (Generic Type Matching)

MatchType creates type-linked inputs and outputs. When a user connects a specific type to a MatchType input, all other inputs and outputs sharing the same template automatically constrain to that type. This is how nodes like Switch and Create List work with any type.
You can also restrict which types are allowed:

Dynamic Inputs

V3 introduces dynamic input types that change the available inputs based on user interaction. There is no V1 equivalent for these features.

Autogrow

Autogrow creates a variable number of inputs that automatically grow as the user connects more. There are two template types: TemplatePrefix generates inputs with a numbered prefix (e.g. image0, image1, image2…):
TemplateNames generates inputs with specific names:
Autogrow can be combined with MatchType to create lists of type-matched inputs:

DynamicCombo

DynamicCombo creates a dropdown that shows/hides different inputs depending on the selected option. This is useful for nodes where different modes require different parameters.
DynamicCombo options can also be nested:

Async Execute

V3 supports async execute methods. This is useful for nodes that perform I/O operations, API calls, or other async work. Simply declare execute as async:

ComfyAPI

The ComfyAPI class provides access to ComfyUI runtime services like progress reporting and node replacement registration. Import it and create an instance:

Progress Reporting

Report execution progress from within a node’s execute method. The progress bar is displayed in the ComfyUI interface. This replaces the V1 pattern of using comfy.utils.PROGRESS_BAR_HOOK.
set_progress can accept a PIL Image, an ImageInput tensor, or None for the preview_image parameter. When called from within execute, the node_id is automatically determined from the executing context.

Node Replacement

Node replacement allows mapping old/deprecated nodes to new ones, so existing workflows automatically upgrade. Register replacements using the ComfyAPI in your extension’s on_load method.
The old_widget_ids parameter is important: workflow JSON stores widget values by position index, not by name. This list maps those positional indexes to input IDs so the replacement system can correctly identify widget values during migration. For nodes using dynamic inputs (like Autogrow), use dotted paths in the mapping:

Extension Lifecycle

The ComfyExtension class supports lifecycle hooks beyond just get_node_list:

NodeOutput

The NodeOutput class is the standardized return value from execute. It supports several patterns:

Complete Example

Here is a complete example of a V3 extension file with multiple nodes: