OSS Login

If you run ComfyUI on Alibaba Cloud - or just want your generated images and videos to end up somewhere with a real public URL instead of buried on a local disk - this little pack is the missing piece. OSS Login is the first node in it, and despite the name it does none of the logging in. No token exchange, no handshake, no network call at all. What it actually does is bundle five pieces of connection info into a single socket so every upload node in the pack can share them.

Here's the context: OSS is Alibaba Cloud's object storage, the S3 equivalent, and it's the natural landing pad when you're running ComfyUI as a batch or API server on Alibaba infrastructure. The wider pattern - generate in the workflow, push the asset to cloud storage, get back a URL you can hand to a web app or another API call - is exactly what this pack is built around. Every node in it returns a url string you can wire into text display or HTTP nodes. The author (a solo dev, wenst, publishing as awsl1110) ships it bilingual EN/中文 and targets the Alibaba crowd specifically. It's MIT, tiny, and published to the Comfy Registry, so installation is painless.

How it works

Under the hood, OSSLogin takes your region, endpoint, bucket, access_key_id, and access_key_secret, builds an alibabacloud_oss_v2.Client, and stuffs it into an object it calls oss_connection. That's it. The trick that makes the pack work is that OSS_CONNECTION is a custom type only this pack knows about - so the only nodes that will accept it are this pack's four uploaders (Image, Video, Audio, File). Wire the credentials once, fan the socket out to every uploader, and when the keys rotate you change one node instead of five. That's the same value-node philosophy ComfyUI plumbing lives on: one authoritative source, many consumers.

The catch worth internalizing: nothing authenticates at this node. The OSS SDK v2 client doesn't contact the server when constructed, so OSS Login will happily report success with a garbage key. Wrong credentials only surface later, at the uploader node, as an auth error mid-run. The "login" is really just configuration wearing a login costume.

The inputs that matter

All five inputs are required, and honestly, three of them are set-and-forget:

• region - OSS region code, default cn-hangzhou. Used both for signing requests and building the public URL.
• bucket - your OSS bucket name.
• access_key_id / access_key_secret - your Alibaba Cloud RAM credentials. The secret field is typed as a password widget, so it's masked in the UI.
• endpoint - leave this blank unless you know why you need it. Blank means the node auto-builds the standard oss-<region>.aliyuncs.com endpoint from region. You'd fill it in for a VPC-internal endpoint (oss-<region>-internal.aliyuncs.com) or a CDN/CNAME custom domain.

The single output is oss_connection (type OSS_CONNECTION), which feeds directly into the uploaders' oss_connection input.

Installing it

Via ComfyUI Manager, search ComfyUI-OSS-Upload and hit install. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/awsl1110/ComfyUI-OSS-Upload.git
cd ComfyUI-OSS-Upload
pip install -r requirements.txt

Dependencies are just alibabacloud_oss_v2 and numpy - no model files, no heavy downloads. (scipy is only needed if you use the audio uploader.)

Where people get burned

• The name lies. If nothing uploads and there's no error until the uploader node, this is why - OSS Login never validates your key. Test with a real upload, not by staring at the login node.
• Your keys are in the workflow file. The AccessKey values sit in the workflow JSON in plaintext, so any workflow you save - or drag back in, or share - contains them. This is the pack's real trap, and the README is right: create a dedicated RAM sub-account with oss:PutObject permission scoped to just the target bucket, never your root account.
• README vs. code drift: the README promises uploads retry 10 times with 3-second delays; the shipped code sets retry_max_attempts = 3. Minor, but if you're tuning reliability, trust the code.

One last thing: the pack's uploaders have a SHA-256 dedupe that calls head_object to skip re-uploading identical files - that needs oss:GetObject in addition to PutObject. If you get a 403 on what should be a working upload, check the sub-account's permission list before blaming the node.