Cloud Upload Image

Every node in this pack is about building a workflow JSON and letting ComfyUI Cloud do the heavy lifting. But at some point a workflow needs an image that exists on your machine - an img2img source, a reference, a start frame. Cloud Upload Image is the door: it takes a real local IMAGE tensor, uploads it to the cloud, and hands back a CLOUD_IMAGE handle the rest of the cloud chain can use.

How it works

When the node executes, it converts your IMAGE tensor to a PIL image and POSTs it to the cloud's /api/upload/image endpoint as a PNG. Then it builds a LoadImage node into the assembled workflow that references the uploaded file, and returns a CLOUD_IMAGE handle pointing at that node. From the cloud's point of view, your local image is just another file in its input folder - nothing about the rest of the chain changes.

The important word is "one-way." The README is explicit: comfy-cloud has no LoadLatent support, so a local latent can't be pushed back into a cloud chain. Local images go up; cloud latents can come down (via Cloud Materialize Latent). That's the whole traffic flow, and it's why this node is the bridge rather than a tunnel.

The inputs and outputs that matter

• image (IMAGE) - a real local tensor, e.g. from Load Image or anywhere else in your local graph.
• filename (default uploaded.png) - the name the file is uploaded under. Mostly cosmetic, but handy if you want to recognize it in cloud storage later.
• Output: image (CLOUD_IMAGE) - the bridge into cloud-land.

Cloud Upload Image vs Cloud VAE Encode

This is where people trip. Cloud Upload Image stops at CLOUD_IMAGE - a LoadImage reference. Cloud VAE Encode takes the same local image, uploads it, and goes one step further: it appends a VAEEncode node and returns a CLOUD_LATENT. Which one you want depends on what the downstream cloud node expects - pixels (feed Cloud Upload Image) or latents (feed Cloud VAE Encode). And note: Cloud Wan Image To Video accepts a plain local IMAGE as its start_image and uploads it itself, so for that specific case you may not need this node at all.

Installing it

Install via ComfyUI Manager (search "ComfyUI-CloudAPI-worker") or:

cd ComfyUI/custom_nodes
git clone https://github.com/Dobidop/ComfyUI-CloudAPI-worker
cd ComfyUI-CloudAPI-worker
cp config.json.example config.json

Paste your API key from https://platform.comfy.org/profile/api-keys into config.json and restart ComfyUI. Dependencies are just requests, Pillow and safetensors.

Common issues & troubleshooting

• It needs a working API key at execution time - this node makes a real network call the moment it runs, so an unset or wrong key fails here before anything else in the chain. The console prints an "Uploaded image as ..." line when it succeeds.
• It uploads on every execution - there's no dedup of uploads, so a workflow you re-run a few times leaves a few extra copies in cloud storage. Harmless, just slightly untidy.
• Watch the security angle - this is the pack's designed phone-home. An API-wrapper node holding a key and making network calls is exactly the shape of the things that've gone wrong in this ecosystem before, so only install the pack from the official repo and keep the key in config.json, not in a shared workflow file.