ComfyUI integration

Every model is a node

Runware's ComfyUI integration turns every model on the platform into its own node. Each node's widgets are the model's real parameters, so the catalog stays current as new models launch. Generation runs on Runware, so you compose graphs the usual way without a local GPU.

Runware LoRA

lora

modelcivitai:993...

weight0.80

Runware: FLUX.2 [dev]

loraIMAGE

positivePrompta neon koi in fog

width768

height512

seed834102

Preview Image

images

Every model is its own node, generated from its live schema. A feature builder wires into the model's matching typed socket, and the IMAGE output flows on like any native node.

ComfyUI gives you a node graph for building generation workflows. This integration adds Runware's full catalog to that graph as typed nodes for image, video, audio, 3D, and text, plus builder nodes for LoRAs, ControlNets, IP-Adapters, and more. You wire them together like any native node, queue the prompt, and the work happens on Runware.

Install

Install ComfyUI first, then add the Runware nodes.

cd ComfyUI/custom_nodes
git clone https://github.com/Runware/ComfyUI-Runware
pip install -r ComfyUI-Runware/requirements.txt

API key

Provide your key, which you create in the dashboard, in any of these ways:

• ComfyUI Settings. Open Settings and paste it into the Runware API key field. Easiest for local use, no terminal needed.
• RUNWARE_API_KEY in the environment ComfyUI runs in. It overrides the Settings field, so a server deployment can pin its own key.
• Runware CLI. Run runware auth login once and the nodes reuse the stored key.

Finding nodes

Search the node menu for Runware. You get one node per model, grouped by modality and creator as Runware/<Modality>/<creator>. A FLUX image model lives under Runware/Image/runware, a Kling video model under Runware/Video/klingai.

A node's widgets are the model's parameters with the right types, ranges, and defaults, and enums become dropdowns. When Runware ships a new model or changes a parameter, the next release of the pack picks it up, so the nodes never drift from the API. Update through ComfyUI Manager or git pull to bring new models and parameter changes in one step.

Your first image

Outputs match the modality

Each node returns the native ComfyUI type for its modality, so results flow straight into the nodes you already use.

Audio and video use ComfyUI's native types when the runtime supports them and fall back to a saved file path otherwise, so a node never breaks on an older ComfyUI build.

Inputs

Inputs map to ComfyUI's native types. Reference and seed images are IMAGE inputs, and inpainting masks are MASK inputs, so a mask editor wires straight into a maskImage socket. Audio, video, and document inputs take a URL, file path, or UUID, one per line for the list inputs. Two utility nodes help here: Runware Upload Image uploads once and returns a reusable UUID, and Runware Load Image (URL) pulls any URL, including a Runware result, into the graph as an IMAGE.

Parameters and defaults

A node's widgets are grouped into sections, so even a model with many parameters reads top to bottom: inputs, the core generation settings, model settings, and output options.

Some models tune parameters on their own. Where a model has no fixed default for a setting, the node leaves it to the model instead of guessing a value. A numeric setting like steps or CFGScale shows a set toggle that reveals its field only when you opt in, and a dropdown like scheduler carries a (default) option. A cohesive settings group reveals behind a single toggle as well: safety, toolChoice, and advancedFeatures each keep their fields hidden, and send nothing, until you enable the group. Leave these as they are to use the model's own default, or set them to take control. Dimensions and seed always show a value, since a generation needs a concrete canvas and a seed.

Builder nodes

Stackable features like LoRAs and ControlNets live in their own nodes instead of crowding every model node with fields you rarely touch. A model that supports a feature exposes a typed socket for it, such as lora or controlNet. Drop the matching builder from Runware/Params, wire its output into that socket, and the feature joins the request. Each socket has its own type, so a ControlNet only fits the ControlNet socket. To stack LoRAs, chain several Runware LoRA builders into the lora socket, where the chain order is the apply order.

This keeps model nodes compact. A node carries its own parameters as widgets, and a feature attaches only when you add its builder, so the graph shows exactly what each generation uses and nothing more.

Every builder is below. The Chainable ones stack: wire several of the same kind into one socket and they apply in order. The rest attach once.

The LoRA, Embeddings, and Refiner builders have an editable model field with a search catalog button beneath it: click it, type a name, and pick from the live catalog results to fill the AIR, so you never have to memorize identifiers.

The ControlNet and IP-Adapter builders instead scope themselves to the base model you wire them into, since both the compatible models and the supported parameters depend on the architecture. Connect the builder (chaining through any other ControlNet or IP-Adapter builders) to a model or architecture node, and its model field becomes a dropdown of exactly the models that node accepts, while parameters the model does not support (some architectures add advanced IP-Adapter controls, others do not) hide themselves. Until it reaches a node, or when the node doesn't restrict things, it stays a free AIR field with all parameters shown.

The Speech, reference, Accelerator Options, and Outpaint builders scope their fields the same way, since what each supports varies by model. Wired into a model, a builder shows only the fields that model accepts and hides the rest: the Speech builder's voice and language become that model's own lists (or a free text field when the model takes an open voice ID), the Accelerator Options builder shows only the caching strategies the model offers, and the Outpaint builder drops a field like blur on models that lack it. Unwired, a builder shows its full set.

Settings that belong to a single model show up as dotted fields right on the model node, like refiner.model or providerSettings.google.webSearch. Only the provider that matches the model appears, so a Google model shows providerSettings.google.* and nothing from the other providers. Anything not covered by a widget or a builder goes into the node's advanced_json input as raw JSON.

Custom models

The catalog covers the models Runware hosts, but you can also run your own community checkpoint, like an SDXL or FLUX fine-tune from a model site. Under Runware/Custom models there is one node per model architecture: Stable Diffusion XL, SD 1.5, FLUX.1 [dev], Pony Diffusion XL, and more.

Pick the node that matches your checkpoint's architecture, then set its model field to the checkpoint's AIR. Its search catalog button is scoped to the architecture, so you can browse compatible checkpoints and fill the AIR without leaving the graph. Everything else works like a model node: the widgets are that architecture's parameters, and LoRA, ControlNet, and the other builders attach the same way.

There is a node per architecture rather than one generic node because each family exposes different parameters. SDXL has a refiner, SD 1.5 has clip skip, and FLUX has its own guidance control, so the node you pick shows exactly the settings that apply to your checkpoint.

The generic node

Runware (custom) targets any model AIR and task type. Reach for it when a model shipped after your installed version of the pack, before the next release adds its typed node.

It makes no assumption about modality. You give it the request body as JSON in request_json, and it returns the raw response as result_json. That single pair works for an image model, a video model, a 3D model, or anything Runware adds later, because the node only moves JSON in and out.

To feed an image, video, or audio input, upload it once with Runware Upload Image for a reusable UUID and reference that UUID inside request_json, the same way you would in a direct API call.

To use a result, pass result_json to Runware Get, which pulls a field out by dot-path. Set the path to match the model's response, such as 0.imageURL, 0.videoURL, or 0.outputs.files.0.url, or leave it empty to grab the first URL it finds. The Get node outputs a string, so wire it to Runware Load Image (URL) to preview an image, or to a Save or Preview node for any other result.

Run info: cost and safety

After a run, every model, architecture, and custom node shows a short line along its title bar with the cost of that run and, when the model ran a content check, whether it flagged the result, like $0.00078 · NSFW: no. You can watch spend and safety as you iterate without leaving the graph. Each part appears only when the response carried it, so a model that returns no cost or runs no content check simply shows less.

Seeds

The seed widget behaves like the sampler's seed, with the fixed, increment, decrement, and randomize control, so re-queuing produces a new image instead of handing back the cached one.

Troubleshooting

Source

The integration is open source and maintained by Runware. Browse the nodes, file issues, or contribute on GitHub. Join the Discord community to share workflows and get help.