🅐 Image Load From Cloud

Most of us drag images into ComfyUI's input folder and call it a day. But if your ComfyUI runs on a headless box or a rented GPU instance and your renders pile up in a cloud bucket, the drag-and-drop world doesn't apply. 🅐 Image Load From Cloud is the pack's bridge for that world: point it at an object in AWS S3 or Alibaba Cloud OSS, and it pulls the file down into ComfyUI's temp directory and hands you a proper IMAGE (plus a mask) like any other loader. If you've never touched S3, this node is probably not for you - but if you have, it's refreshingly direct.

How it works

The required inputs are the usual cloud-storage incantation:

• cloud - aws-s3 or aliyun-oss.
• bucket, region, filepath - where the object lives.
• access_key_id, access_key_secret - your credentials, typed straight into the node.

Under the hood it uses boto3 for S3 (download_file) or oss2 for Aliyun (get_object_to_file) to fetch the object into ComfyUI/temp/<bucket>/<filepath>. From there it loads the file the same way ComfyUI's core image loader does - honoring animated formats and EXIF - and returns two outputs: the IMAGE and a MASK derived from the image's alpha channel (inverted, so the mask is 1 where the image is transparent, matching ComfyUI's mask convention).

Inputs and outputs

• All six required inputs as above.
• Outputs: IMAGE, MASK.

Where it fits

This is a workflow-plumbing node for cloud-backed pipelines: a remote job renders, saves to a bucket (see the sibling 🅐 Image Save To Cloud), and this node pulls it in for post-processing. The mask output means you can even handle PNGs with transparency in one step. But it's niche - you need a bucket, credentials, and a reason not to just download the file manually.

Install

Ships in hay86/ComfyUI_AceNodes:

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

Restart ComfyUI and find 🅐 Image Load From Cloud under Ace Nodes. Manager users search ComfyUI_AceNodes. The boto3 and oss2 dependencies come from the pack's requirements.txt, so they're installed with it.

Gotchas

Credentials live in the node itself as plaintext widgets - anyone who can read your workflow JSON can read your keys, so keep those workflows private and use scoped keys. The region matters for S3 (it's required by the client), and the OSS region string has a specific format that has to match your bucket's endpoint. There's also no error surfacing worth its salt here - a wrong key or missing object fails at execution with a raw SDK error. And remember the whole pack's heavy requirements.txt installs with it. For everyone without a bucket, this node can safely stay unused; for cloud pipelines, it's the missing piece.