💾 Save Your Image to S3

The one-line pitch

Save Image To S3 takes the IMAGE tensor that would normally go into the core Save Image node, encodes it to PNG, and uploads it to your S3 bucket instead of your local output folder. It's an output node - the end of the line for your graph - and it needs nothing except a bucket, a name, and (depending on your setup) credentials.

Where this shines: team buckets, headless ComfyUI instances with ephemeral local disk, and batch farms where the next step in the pipeline is watching an object store. Where it's silly: you're a solo local user and your "cloud" is a folder on the same drive. You'd be paying for storage and transfer on files you could keep on disk, while losing the conveniences of Save Image - no browser preview, no workflow re-drag from the file itself. If you're local, run plain Save Image and move on.

How it works

The mechanism is boring in a good way. It iterates the batch, converts each image tensor to a PIL image, encodes it as PNG into a BytesIO buffer, and pushes it with a single put_object call. The object key is built as "<pathname>_<n>.png", where n is the index in the batch - so a batch of four becomes render_0.png through render_3.png.

A few things worth flagging because they bite people. There's no format choice: it's always PNG. No timestamps, no counter folders, no date stamps - just your pathname plus the batch index. And it writes nothing locally; the node reports the filenames it uploaded to the ComfyUI UI, but unlike Save Image there's no local copy sitting in output/. If you want both, wire a plain Save Image in parallel. Also note put_object is a single-call upload - totally fine for PNGs, but don't point this at huge files expecting multipart.

The inputs that matter

images is the wire that carries your render in. Then s3_bucket, region (defaults to us-east-1), and pathname - the base name of your object. Don't type an extension; the node appends _0.png itself, so "render.png" in the field gives you render.png_0.png.

Credentials work the same way as the sibling Load node, and the same advice applies: leave aws_ak, aws_sk, and session_token empty and let boto3's default credential chain do its thing - environment variables, ~/.aws/credentials, or an IAM role. That keeps secrets out of the graph entirely. If you do type keys in, both access key and secret are required; a lone aws_sk silently falls through to a broken client. All three together means temporary credentials via a session token.

Install

Same pack as Load Image From S3, so one install gets you both. ComfyUI Manager, search "ComfyUI-S3-Tools":

Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/kealiu/ComfyUI-S3-Tools

Restart ComfyUI after. No models to download, and of the declared dependencies only boto3 isn't already part of ComfyUI (torch, numpy, PIL ship with it). pip install boto3 in your environment if Manager doesn't pull requirements.

Common issues

• pathname for file_0.png is now in your bucket. The defaults are placeholders, not examples. Change pathname (and the bucket) before your first run or you'll upload under a literally meaningless key.
• Credentials in shared workflows. Because access keys live as widget values, they end up in the workflow JSON - which gets embedded in output PNG metadata and shared as a file. Every time you drag a workflow in from an image, whatever secrets were typed into it go with it. Empty credential fields plus the default chain is the secure setup, not just the lazy one.
• Batch keys are opaque. With a batch of five, the UI shows you x_0.png through x_4.png but gives you no mapping back to which prompt or seed made which one. If you need provenance, stamp it into the image yourself or use a folder-style pathname per run.
• Upload failure kills the run. It's an output node, so a failed put_object (wrong region, bad perms, no creds) errors the whole graph. Check region and bucket permissions before you blame the node.