Cloud Create Video

Cloud Create Video is the cloud-side encoding step for a video workflow. It takes a CLOUD_IMAGE batch and an fps value, appends a CreateVideo node to the workflow JSON, and hands you a CLOUD_VIDEO handle. The actual muxing - frames into a playable file - happens on Comfy Cloud, so the heavy lifting never touches your machine.

You have two roads to a finished video with this pack, and this node is the fork. Road one: decode to frames with Cloud VAE Decode, fetch them as an IMAGE batch, and mux locally with something like VHS_VideoCombine - that's the "N frames come back, you do the encoding" route, which the README explicitly calls out. Road two: keep the encoding cloud-side with Cloud Create Video, then pull the file down with Cloud Fetch Video (which returns a VIDEO object plus a local file path) or Cloud Save Video (which just writes the MP4 and returns the path). If you're generating at 1080p for minutes at a time, the second road is the whole reason this pack exists.

The inputs that matter

• images (CLOUD_IMAGE) - the frame batch, typically straight from a Cloud VAE Decode or Cloud Wan Image To Video.
• fps (FLOAT, default 30, 1–120) - playback speed for the assembled video. Wan 2.2 chains usually run 16 fps; LTX 2.0 runs 24–25 fps. Set it to match the model's native cadence, not your excitement level.
• audio (optional, CLOUD_AUDIO) - attach when you have a cloud-side audio track (LTX 2.0 audio workflows produce one from the audio VAE decode). Leave it disconnected for silent video.

Output: video (CLOUD_VIDEO) - wire it into Cloud Fetch Video or Cloud Save Video to bring the file home.

How it works

Every cloud node is an accumulation game: handles carry a growing workflow dict, and Cloud Create Video merges your images (and optional audio) handles' dicts and appends one CreateVideo spec referencing them. It does not submit anything. That only happens at a terminal - and for video, the terminals are the Fetch/Save video nodes. So a chain of VAE Decode → Create Video → Fetch Video is: assemble, submit, poll (queued_waiting through success), download the MP4, return it as a VIDEO object. The cloud does the encoding; you do the waiting.

How to install

cd ComfyUI/custom_nodes
git clone https://github.com/Dobidop/ComfyUI-CloudAPI-worker

Copy config.json.example to config.json, paste an API key from https://platform.comfy.org/profile/api-keys, restart. ComfyUI Manager works too. Dependencies are just requests, Pillow, safetensors - video encoding happens cloud-side, so no ffmpeg install on your end for the muxing itself (you may still want it locally for downstream work on the fetched file).

Common issues

• Audio silently missing - the audio input is optional and disconnected by default. For an LTX 2.0 audio workflow you must wire the audio handle in; forgetting it gives you silent video with no error.
• Wrong fps - you'll get a video, but juddery or speed-shifted playback if fps doesn't match the model's native rate.
• PoC caveats - the pack's own README lists dedicated cloud-side video encoding as a known missing piece, and the author's "very hacked together" framing applies double to video. Start from the repo's Wan and LTX example workflows; they're the tested paths.