FL Zip Directory

There are two zip nodes in this pack and they solve different problems. FL_ZipDirectory builds a ZIP archive of a folder entirely in memory and hands you the raw bytes - it never touches disk itself. If what you actually want is a .zip file saved somewhere, you want its sibling, FL_ZipSave, instead. This one exists for the case where the zip is an intermediate step: you're about to upload it somewhere (a Hugging Face dataset push, a webhook, an API call) and don't need or want a copy sitting on disk along the way.

How it works

Give it a directory path, and it walks the whole folder structure and compresses everything into a ZIP archive using standard ZIP_DEFLATED compression, held in memory. Notice what's not in the input list: there's no output_directory. That's the tell that this node genuinely never writes anything to disk - the ZIP object it returns is just bytes, waiting for whatever comes next in your graph to do something with them.

The inputs and outputs that matter

Two required inputs, both plain strings:

• directory_path - the folder you want zipped. Needs to exist and be readable; it zips the whole structure recursively, not just the top level.
• zip_filename (default archive.zip) - since this node doesn't write to disk, this isn't a save path. It's metadata carried along with the ZIP object for whatever downstream node consumes it - for example, something that needs a filename to hand a server during an upload.

One output: ZIP - the in-memory archive object, is_output_node is false, so this node is meant to feed something else, not to be the end of your workflow.

How to install it

Through ComfyUI Manager - search ComfyUI_Fill-Nodes (or Fill-Nodes) - or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

Restart ComfyUI. Zipping is stdlib Python (zipfile) - no extra dependencies or model downloads for this node specifically.

Common issues & troubleshooting

Wrong node for the job. If your goal is "I want a zip file to end up on my disk," this isn't it - that's FL_ZipSave. FL_ZipDirectory only makes sense when something downstream actually consumes the ZIP output; if nothing does, the archive is built and then discarded, which wastes the compression work for nothing.

Large directories eat memory. Because the whole archive is held in memory before being passed along - not streamed to disk - zipping a folder full of large model files or a big video dataset can spike your RAM usage noticeably more than a disk-based zip would. Fine for a folder of captions and small images; think twice before pointing it at tens of gigabytes.

directory_path typos fail silently in unhelpful ways. Double-check the path exists and is spelled correctly before running - a bad path here fails at the point this node runs, not earlier, so it's easy to lose time on a long workflow only to find the very first step never had a real folder to zip.