RunningHub Image to Video

Image-to-video is the least settled corner of local generation, which is exactly why people keep paying a cloud to do it. RunningHub Image to Video is that cloud, exposed as a ComfyUI node: feed it an image, optionally tell it what should move, and their servers animate it while your GPU sits idle. The catch, and you should know it before you build a workflow around this: the node's output is a URL string, not frames. No VHS node, no video preview, no automatic download. You get a link, and the job of fetching the file is yours.

It's one of five nodes in marduk191/comfyui_qwen_runninghub, a port of the freeqwenimage webapp, and like the rest of the pack it ships with the author's own disclaimer front and center: "This is untested as I have no access to runninghub. It might work, It might not." Img2vid is also the most fragile job in the pack because it runs the longest - so treat your first run as a test, not a milestone.

How it works

Mechanically it's the same pipeline as the other image-eating nodes in this pack: the first frame of your IMAGE tensor is saved to a temp PNG, uploaded to RunningHub's /task/openapi/upload endpoint, and a job is submitted with the file ID plus an optional motion prompt. The node then polls /task/openapi/status every three seconds until the video is done, and returns the first result URL. On their side that's async generation; on yours it's a blocking wait that can run the full 600-second default - which is why the timeout input goes up to 1800.

The inputs that matter

• image - the still you want to animate. LoadImage, a prior generation, or RunningHubLoadImage for a URL.
• webapp_id / api_key - your RunningHub credentials.
• prompt - optional, but use it. "The flag waves in the wind," "the camera slowly pushes in." An empty prompt asks the model to invent motion, and you'll like the results a lot more when you've told it what to do.
• timeout - default 600 seconds, and for video this is the one to actually raise.

The output is a string

video_url is a STRING, and it's the only output. You can't preview it as a video in the graph, so capture it with a ShowText or SaveText node, then grab the file yourself:

curl -o output.mp4 "<the url>"

Do it promptly after the job finishes - the result lives on RunningHub's CDN, and you don't want your render expiring in a browser tab while you wonder where it went.

Install

Nothing heavy lands locally, which is the whole appeal. From your ComfyUI root:

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

Restart and the nodes appear under "RunningHub". Dependencies are just requests, Pillow, numpy and torch. No models, no FFmpeg requirement in the node itself (you'll want a tool to inspect the video, but that's on you). Manager usually finds the pack by title, but it isn't in the official Comfy Registry, so the clone is the reliable path if Manager doesn't.

Credentials and troubleshooting

Same story as the rest of the pack: a WEBAPP_ID and API_KEY from the RunningHub dashboard, set as env vars before ComfyUI starts or typed into the widgets:

export RUNNINGHUB_WEBAPP_ID="your_webapp_id"
export RUNNINGHUB_API_KEY="your_api_key"

"RunningHub credentials are required" = blank fields. Timeouts are the normal failure mode here because video takes longer than images - raise timeout toward 1200–1800 and retry. Task failed prints the API's reason to the console; check credits, credentials, and the uploaded image. And remember the author's caveat: this conversion was never run end to end by its own author. If it fails in a way the docs don't cover, the hardcoded node IDs for RunningHub's operations are the first thing to suspect.

Where it fits

Use it as a finishing stage: generate or edit an image locally, hand it to RunningHub for the animation, then pull the mp4 and do your frame work in the video tooling you already trust. It's the "open browser, click button, get video" experience from the cloud-services debate, except it lives inside your graph - which is a genuinely nice middle ground.