API Core-RustFS

This is the same idea as the pack's API Core node - send a prompt to a hosted image API, get previews back - with one crucial difference in plumbing: instead of handing the third-party service a URL to your ComfyUI so it can fetch your reference images, this variant uploads those images to a self-hosted object store first. It exists for the situation API Core can't handle: your ComfyUI is behind NAT, or on a laptop, or you simply refuse to expose it to the internet.

The price of that safety is setup. API Core-RustFS requires you to run your own RustFS instance - an S3-compatible object storage server - and hand this node its endpoint plus AWS-style credentials. If that sentence makes you want to close the tab, honestly, the regular API Core node is the easier life when a public address is possible. This variant is for people who already run S3-compatible storage or who need their reference images to travel through a bucket, not through a port-forwarded web server.

How it works

Same core as API Core: prompt, api_key, model (default gemini-3-pro-image-preview), size (ten aspect ratios), and n (1–10 images). Same outputs: response (raw text) plus preview_1 through preview_10 as IMAGE tensors. Same dynamic image_1 reference slots that grow as you connect images.

What's different is where those reference images go. Instead of building a ComfyUI /view URL from a server_origin, the node uploads them to your RustFS bucket using the S3 credentials you provide:

• endpoint_url - your RustFS endpoint.
• aws_access_key_id / aws_secret_access_key - S3-style credentials for that bucket.
• bucket_name - where images land before the API pulls them.

All four are marked required in the tooltips; none of them has a sensible default.

Install

Same pack install, no extra Python deps:

cd ComfyUI/custom_nodes
git clone https://github.com/LaoMaoBoss/ComfyUI-WBLESS

restart ComfyUI, or ComfyUI Manager → "ComfyUI-WBLESS." The hard part isn't the node - it's standing up RustFS and having working S3 credentials before you start.

Troubleshooting

If uploads fail, work the S3 layer first: is the endpoint reachable from your machine, are the credentials valid for that bucket, and does the bucket exist? A misconfigured endpoint_url fails in exactly the same way as a wrong password, which makes debugging sneaky. And keep the same expectations as API Core: this is a paid hosted image API, so costs, availability, and model lineup are all on the third party. The real reason to reach for this node over its sibling is purely architectural - if you already run object storage, it's the cleaner, safer pipeline. If you don't, API Core's server_origin is the shortcut you were probably looking for.