Runware LoRA

This node doesn't generate a single pixel, and that's its job. RunwareBuild_lora is a builder - one of the Runware/Params nodes whose entire purpose is to produce a RUNWARE_LORA value that you plug into the lora socket on any image or video node in the pack. It's the Runware equivalent of a LoRA loader, except instead of pointing at a local .safetensors file, it identifies a LoRA by its model identifier and lets the server fetch and apply it.

You need to understand the builder pattern before this node makes sense: model nodes in this pack expose typed sockets like lora, controlNet, ipAdapters, pulid, and you chain these together. The output of this node is lora, and you can stack several - wire one builder's output into the next builder's lora input and the pack concatenates them into a list. Two LoRAs, three LoRAs, all feeding one generation. That's how you get the "character LoRA + style LoRA" stacks that dominate modern realism workflows, just hosted.

Inputs

• model (required) - the LoRA model identifier. In Runware terms this is the AIR-style reference for the adapter (the same thing you'd type into the generic Runware (custom) node). This is how you point at a community LoRA on Runware's catalog.
• weight - strength, default 1, range −4 to 4. Zero means no influence; negatives steer away from the style. This is the knob you'll actually live in - 0.7 for a subtle style, 1.0–1.3 for a loud one, negative to counter something baked into a checkpoint.
• transformer - high, low, or both (default). This is a genuinely modern detail: some video models run separate high-noise and low-noise processing stages, and you can apply the LoRA to just one of them. If you're not on one of those video models, leave it on both.
• lora - the chain input. Connect another builder's output here to stack.

When the required model field is empty, the builder drops the incomplete feature instead of sending it - so an unwired or empty builder silently contributes nothing rather than erroring your whole request. That's a kindness, but it also means "why is my LoRA doing nothing" is usually "your model field is empty."

How it fits

In a real workflow it looks like: RunwareBuild_lora → Runware_<some image model>'s lora socket → output to Preview. The model node merges the LoRA into its request server-side; the adapter never touches your disk or VRAM. One caveat about the ecosystem: a LoRA trained for one architecture won't apply to another - a Z-Image LoRA does nothing useful on a FLUX model - so match the adapter's base to the model node you wire it into.

Install

Same pack, same two routes:

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

Restart, or install "Runware" via the Custom Nodes Manager. You still need the Runware API key (Settings → "Runware API key", RUNWARE_API_KEY, or runware auth login) because even a builder node ultimately feeds paid cloud inference.

The trap: people treat this like a loader and expect it to do something by itself. It won't - nothing runs until you wire its lora output into a generation node and queue. It's plumbing, not a generator. Get that straight and it's the difference between a one-model workflow and the stacked-LoRA workflows everyone else is posting.