WAN22 Generate Video

What it is

Same RunPod-client pattern as ComfyBros Text to Video, but this one is image-to-video, and it's Wan 2.2 under the hood. Feed it a still, get back a clip. The giveaway is the parameter list: high/low CFG schedule, shift, context windows, fuse_method, closed_loop - that's WanVideoWrapper's sampling config surfaced through a remote call, so what's actually running on the other side of that endpoint is effectively a Wan 2.2 workflow.

Wan 2.2 is worth knowing about because it's the frozen open base the community still treats as the reference for quality local video - Alibaba's last open numbered release, Apache 2.0, and the thing ByteDance and Z.ai later built their own models on. Image-to-video from a strong still is the default way people use it. This node just moves that default onto rented hardware.

How it works

Your input image is base64-encoded, bundled with a couple dozen parameters, and POSTed to {endpoint}/run. The node then polls {endpoint}/status/{job_id} every four seconds, up to a 15-minute hard cap, and when the job completes it downloads a ZIP of frames from your Cloudflare R2 bucket, sorts them, and reassembles them into an IMAGE batch. Nothing is computed on your machine - this is a client, not a generator.

The parameters that actually matter

• instance_name, input_image, positive_prompt - the essentials. The instance_name dropdown defaults to "No instances configured" until you set one up.
• length - 240 frames by default, which is 10 seconds at 24fps; up to 800.
• total_steps - defaults to 4, not 20–50. That's the distilled speed-LoRA regime: high_cfg 2.0 for the first two steps, low_cfg 1.0 for the last two. If your server workflow isn't running the distilled model, four steps will come out mushy - and if it is, raising steps just adds cost and queue time without much gain.
• shift / shift_model - the standard WanVideoWrapper shift value. Leave the model toggle off unless your server workflow expects it.
• context_length (default 81 - Wan's native context), context_overlap, context_schedule, context_stride, closed_loop, fuse_method - how long clips get generated in chunks and stitched back together. This is also where quality falls apart: identity drift across chunk boundaries is the classic Wan long-video failure, so don't expect 800 frames to hold a face.
• upscale (bool) - whether the server runs an upscale pass on the frames. Off by default for good reason: it roughly multiplies render time.
• Outputs: frames (IMAGE batch) - wire into any video preview/save node; metadata (STRING) - JSON with frame_count, execution and delay time, status, and R2 info.

Setup and install

Identical to Text to Video. Edit ComfyUI/user/default/comfy.settings.json with serverlessConfig.instances (name, endpoint, auth_token) and serverlessConfig.offloadBucket (Cloudflare R2 account id, bucket name, access key id, secret key) - the frames come back from R2, so the bucket is mandatory, not a nice-to-have.

Install via ComfyUI Manager (search "ComfyBros"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/turnbros/ComfyBros

Restart, then pip install boto3 - the README's pip install -r requirements.txt is a phantom (no requirements.txt exists), and boto3, which the module imports at the top, isn't in the declared dependency list. Without it the node won't load.

The honest verdict

If you already run Wan 2.2 locally with WanVideoWrapper, this is strictly more expensive and slower than your own GPU - you'd only reach for it to keep your local VRAM free for something else. If you have no local GPU but do have a RunPod budget, it's a legitimate way to drive Wan 2.2 from the ComfyUI graph you already know. Either way, run at the defaults first and read the metadata output - it's the only place you'll see what the server actually did, how long it sat in the queue, and whether the frames came back at the size you asked for.