Remote Workflow

Remote Workflow (class KargaRemoteWorkflow) is one node that sends a workflow to a second ComfyUI instance over HTTP, queues it, waits, and drags the finished image back into your local graph as a normal IMAGE tensor. No API key, no cloud credits, no vendor. Just your other machine doing the heavy lifting and you keeping the canvas you like.

Before you get the wrong idea: this is not an API-wrapper node in the cloud-API sense. Those call Nano Banana or fal with a key and your data leaves the machine (external-api-nodes.md covers that whole family and its security baggage). This node is the opposite move - it talks to another ComfyUI instance you run, over plain HTTP, using ComfyUI's own /prompt, /history, and /view endpoints. The README's framing is "part of the Karga ecosystem," though as of now this is a single, young repo (created April 2026, MIT, zero stars) and there's no other public Karga pack to lean on.

Why you'd reach for it

The classic setup: a weak laptop on your desk, a beefy GPU box in the next room, and you want the generation over there while you iterate locally. Drop this node in, point it at the server, and the result comes back as a socket you can wire into a Preview Image, a Save Image, or an img2img loop - a generator that happens to run elsewhere. That's the whole pitch: remote rendering, local iteration.

Honest take: it's a thin wrapper around ComfyUI's own HTTP API, and if your only goal is to fire a job and download a PNG, a five-line script does the same. The edge is being inside the graph so the output feeds local nodes. For a 0-star, brand-new pack it's also refreshingly skimmable - one ~700-line nodes.py, MIT-licensed, no hidden dependencies. Read it once before you point it at anything you care about.

How it works

You export your remote workflow with Save (API Format), drop the JSON into the pack's workflows/ folder, and it appears in the workflow dropdown. The clever part is how it knows what to inject: it scans every node's _meta.title for a [ui] tag and maps known class types automatically. CLIPTextEncode [ui] becomes the prompt field, RandomNoise [ui] or KSampler [ui] becomes the seed, Load Image [ui] becomes the image input, LoadImageMask [ui] the mask. For anything else you use the prefix form [ui] steps:steps or [ui] cfg:cfg, and any of those extra tags show up as dynamic input widgets right on the node.

At runtime it uploads your connected image/mask to /upload/image, POSTs the workflow with a fresh client_id to /prompt, polls /history/{prompt_id} every poll_interval seconds until done or the timeout hits, then fetches frames via /view and returns them as a tensor. It even handles video: a remote mp4 (VHS-style gifs output) comes back as a decoded batch of frames.

The inputs that matter

You set four things as a beginner: workflow (the dropdown), remote_address (defaults to 192.168.1.50:8188 - your remote box running with --listen), prompt (multiline, injected into the [ui] prompt node), and seed (injected into the [ui] seed node). image and mask are optional sockets for img2img and inpainting. poll_interval (default 1s), timeout (default 180s), and image_index (which output image to return when the workflow makes several) are the knobs you'll touch when something hangs or produces a batch. Output is a single image (IMAGE).

Install

Via ComfyUI Manager (search "Karga Remote Workflow"), or the plain way:

cd ComfyUI/custom_nodes
git clone https://github.com/kapakahi/comfyui-Karga_RemoteWorkflow

Restart ComfyUI; the node appears under Karga. There are no model files and no pip requirements - it runs on the numpy/PIL/torch that ComfyUI already ships. The one dependency that's not guaranteed: decoding mp4 video needs imageio + imageio-ffmpeg (or opencv-python), so pip install imageio imageio-ffmpeg if you plan to pull video back.

Where people get burned

• The dropdown is stale. The workflow list (and the dynamic [ui] fields) are computed when the node is created, so after dropping a new JSON into workflows/ you'll need to recreate the node or restart for it to show.
• Dynamic fields come from the first workflow only. The source scans workflows[0] for extra tagged fields - if your folder has several JSONs, the extra widgets may not match the one you select.
• It blocks your queue. While this node polls the remote, your local graph waits. That's fine for one-off renders, annoying if you expected to keep working.
• Unreachable or slow. If the remote isn't on --listen, or the job takes longer than timeout (default 180s), you get a connection or timeout error in the console. Raise timeout before blaming the node.
• It's plain HTTP. Prompts and images cross the network unencrypted and the address is just a string - keep it pointed at a machine you trust and off the public internet. And since this is an output node it always runs, so a workflow with no remote up fails loudly every time.