GCP: Write Images

The write half of the two-node ComfyUI-GCP_Storage_tools pack. Feed it an image and it saves it to disk, uploads it to a Google Cloud Storage bucket, deletes the local copy, and reports the result to the UI. Its real use case is automation: a headless ComfyUI box, a scheduled batch, or a pipeline that consumes generated images from GCS. If your outputs already end up in the cloud anyway, this skips the "download from the UI, upload manually" dance entirely.

If that's not you - if you're generating for fun on a desktop - don't bother. The built-in Save Image node is fine and your output folder is exactly where you want it. This node is for people whose render farm and storage live in different places.

How it works

Auth is the same as its sibling: a service-account JSON file path, which the node drops into GOOGLE_APPLICATION_CREDENTIALS so the google-cloud-storage client can authenticate. Each image in the incoming batch is saved locally as a PNG (compression level 4), then the file is uploaded to bucket_path/file_name and removed from disk. It's an output node, so it also shows the saved images in the UI.

Two quirks in the source you should know about before it bites you:

• Batches silently collapse to one file. The loop saves every frame of the batch to the same local filename, overwriting as it goes - only the last frame of the batch actually gets uploaded. If you feed it 4 images, one lands in GCS. Feed it single images, or keep the batch at size 1.
• Slashes in file_name break it. The write path doesn't create intermediate folders, so file_name: sub/img.png fails before the upload even starts. Keep it a plain filename like render_001.png.

Also worth knowing: on success the node returns UI results rather than filling its declared outputs, and the error_message output only carries text when something fails. Wire it up if you want failure to be visible, but don't expect a live status channel.

The inputs and outputs

• images (IMAGE) - what you're uploading. Wire this from your VAE decode or upscale step.
• bucket_name - your bucket (globally unique name, exact).
• bucket_path - destination folder in the bucket (default some/folder is a placeholder).
• file_name - the object name to write, no slashes.
• gcp_service_json - absolute path to the service-account JSON.

Outputs: images (IMAGE, mostly cosmetic on success) and error_message (STRING, populated on failure with something like Upload failed: ...).

Installing it

Search ComfyUI Manager for "ComfyUI-GCP_Storage_tools", or:

cd ComfyUI/custom_nodes
git clone https://github.com/ahernandezmiro/ComfyUI-GCP_Storage_tools gcp_nodes
pip install google-cloud-storage

Restart ComfyUI. The pack tries to auto-pip google-cloud-storage at startup, but install it yourself - that self-install path is fragile. That's the whole dependency story; no models, no weights, nothing heavy.

Where people get burned

• Placeholder defaults. All four string fields ship with fake values (my-bucket, some/folder, /path/to/service_account.json). Forget one and you get Credential file not found or an upload to a literal folder named some/folder.
• Permissions. The service account needs storage.objectCreator (or storage.objectAdmin) on the bucket, or you'll see a 403. Read access isn't enough for writes.
• The batch and slash gotchas above - these are the ones that look like network errors but are actually the node's own quirks. Check the console line it prints (Uploading blob to bucket/path/file..) to see exactly what it's doing.

It's a thin, unglamorous node with no community footprint, and it's honest about that: no retries, no progress bar, no multi-provider support. If GCS upload is a serious part of your pipeline rather than a nicety, the more mature crowd (ComfyUI Save/Load Extended) wraps GCS along with S3, Azure, and Drive behind a proper UI with progress and toasts. This one wins when you want the smallest possible thing that pushes one image to a bucket.