Load ZIP Archive

Cloud APIs love handing you ZIP files. It's the natural packaging for a model that returns multiple images, a batch of frames, or a whole set of outputs - one download, one file. The problem is that a ZIP is a dead end in ComfyUI: you can't wire a ZIP into the graph. This node is the bridge. It takes a ZIP - from a URL or a local path - pulls out all the PNGs inside, and hands them back as a single batched IMAGE tensor, ready to pipe into whatever comes next.

Mechanically it's straightforward: it fetches the ZIP (via urllib for URLs, straight file read for local paths), opens it, collects the .png files in sorted order, decodes each into a tensor, and concatenates them into one batch. Outputs: images (the IMAGE batch) and zip_info (a string - "Loaded N images from ZIP", or a status message if something went wrong). If the archive has no PNGs at all, you get None for images and the info string tells you so rather than crashing.

The single required input is zip_path - a URL (http/https) or a local file path. That's the whole input surface. No token, no API, no GPU; one of the pack's genuinely local utility nodes.

Where you'll actually use it: in this pack's world, several Replicate models return their multi-image output as a ZIP, and this node is how you get that output into a ComfyUI workflow as usable tensors - a batch of faces to feed a face-restoration pass, a set of variants to compare, a frame sequence to upscale. It also pairs with the pack's Load Replicate Prediction node, which already unwraps zips on the prediction side; this node covers the cases where you have the raw ZIP file yourself (downloaded to disk, or a URL you saved) and want it in the graph.

Install is the pack standard - ComfyUI Manager (search ComfyUI-API-DockerCPU), or:

cd ComfyUI/custom_nodes
git clone https://github.com/trustypangolin/ComfyUI-API-DockerCPU
cd ComfyUI-API-DockerCPU
pip install -r requirements.txt

Restart and find it under 🎨 DockerCPU API/Utilities.

The gotchas, honestly: it only loads PNGs - a ZIP full of JPGs or WEBPs comes back as "No PNG files found," and there's no setting to change that. It reads the whole archive into memory, so a huge ZIP on a small VM (which, remember, is the exact audience for this pack) can be a memory event - for a genuinely massive batch, consider splitting the ZIP or loading in pieces. And it sorts by filename, so if you need the images in generation order and the producer named them carelessly, check the batch order before you trust downstream results. Small node, small failure surface, but those three are where it bites.