WAN22 Upscale Image
Two Inputs, One Cloud Bill
- input_image
- upscaled_image
- metadata
What it is
The most bare-bones node in the pack: instance_name plus input_image in, upscaled_image plus metadata out. And like its video siblings, the actual work happens on a RunPod serverless instance, not on your machine. Your image is base64-encoded and POSTed to the configured endpoint; the result - a ZIP of the upscaled image parked in Cloudflare R2 - is downloaded, extracted, and converted back into an IMAGE tensor. There is no local model, no VRAM usage, and no setting that changes what the server does.
When it makes sense
Honestly: only if you're already paying for the RunPod instance that runs this pack's upscale workflow. The local ecosystem does "more pixels" better and for free - an ESRGAN 4x model like 4x-UltraSharp or Remacri runs in milliseconds on your own GPU, adds no content, and can't hallucinate. The community's upscaling rules of thumb have been settled for a while: pixel upscalers for more pixels, generative restorers (SeedVR2, SUPIR) only when the image is genuinely soft or damaged.
What the cloud version buys you is the upscale happening off-device, so your VRAM stays free for the rest of the graph - plus whatever quality the server-side model has, which you can't change, because this node sends no model name and no scale factor. If the server runs a generative restorer, it will happily rewrite faces; keep anything with a recognisable person out of this path until you've seen its output.
The inputs and the output
instance_name- which configured endpoint gets the job. Defaults to "No instances configured".input_image- any IMAGE tensor.- Outputs:
upscaled_image(IMAGE), andmetadata(STRING JSON) - parameters, execution_time, delay_time, status, and r2_info. That metadata is the only place you'll see what the server actually did: which parameters it used, and how long the job sat in the queue.
Setting it up
Same story as the video nodes in this pack. Edit ComfyUI/user/default/comfy.settings.json:
{
"serverlessConfig": {
"instances": [
{ "name": "my-endpoint", "endpoint": "https://api.runpod.ai/v2/<endpoint_id>", "auth_token": "<runpod_api_key>" }
],
"offloadBucket": {
"cloudflare_account_id": "...",
"name": "my-bucket",
"secret_key_id": "...",
"secret_key": "..."
}
}
}
No R2 bucket, no result - the upscaled image is pulled from the bucket, not the endpoint.
Installing
ComfyUI Manager, search "ComfyBros" - or:
cd ComfyUI/custom_nodes
git clone https://github.com/turnbros/ComfyBros
Restart. The README's pip install -r requirements.txt is a phantom - no requirements.txt exists in the repo. This module imports boto3 at the top, and boto3 isn't in the declared dependency list, so run pip install boto3 into ComfyUI's Python environment or the node won't load.
Where people get burned
The scale factor is whatever the server workflow does - you can't pick 2x vs 4x from the node, and there's no way to tell what happened except the metadata output. If upscaled_image comes back the same size as the input, the server-side workflow wasn't actually configured to upscale; that's a server problem, not a node bug. And the cost thing: every run is a per-second bill plus queue time, so it's worth asking whether a local 4x pass would have been faster and free.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| instance_name | COMBO | No instances configured | 1 options: No instances configured |
| input_image | IMAGE | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| upscaled_image | IMAGE | — |
| metadata | STRING | — |