Package a Workflow Someone Else Can Run

A workflow JSON is not self-contained. It is a description of a graph that references things by name — node types, model filenames, LoRAs, embeddings — and it assumes all of them exist on the machine that opens it. On yours they do. On a colleague's they do not, and the error they get names one missing piece at a time, which turns a five-minute handoff into an afternoon.

Packaging is the small amount of work that prevents this, and it also happens to be what makes a workflow still runnable by you in six months.

What a graph silently assumes

Write these down alongside the JSON:

The application version. Node behaviour and defaults change between releases.

Every custom node pack, with a version or commit. Pack names are not enough — nodes get renamed, and a pack from six months ago is a different pack.

Exact model filenames. "SDXL base" is not a filename and there are many variants with different behaviour. Include the checkpoint, VAE, LoRAs, embeddings, ControlNet models, and upscale models, with the source you downloaded each from.

Any input files. Reference images, masks, and control images the graph loads by path.

The settings that are not in the graph. Anything configured at the application level rather than the node level.

What it is for, and what good output looks like. One paragraph and one example image. Without this, the recipient cannot tell whether their run succeeded.

A short markdown file next to the JSON covers all of it. This is not process for its own sake — the model filename list alone resolves most handoff failures.

Treat an incoming workflow as code

This deserves stating plainly: installing a custom node pack runs someone else's Python on your machine, with your file access and your network. It is not equivalent to opening a document.

Before installing something unfamiliar, spend two minutes on: how established the pack is and whether it comes from a known author or organisation; whether the source is browsable and the code readable; whether it is widely used and recently maintained; and whether the workflow genuinely needs it or is using it for something the core nodes already do.

Prefer packs distributed through the established registry over a link in a comment thread. Be more careful with a pack that requests network access or that arrives bundled with a workflow from an anonymous source.

Model files carry their own history — older serialisation formats could execute code on load, which is exactly why the safetensors format exists. Prefer it, and get weights from the original publisher rather than a re-upload.

None of this requires paranoia. It requires treating a workflow the way you would treat a script someone emailed you, because that is what it is.

Version so that a working state always exists

The failure mode is familiar: a graph works, you improve it for an hour, it no longer works, and there is no way back.

Keep a known-good copy of any graph that produces output you rely on, named with the model and date, and do not edit it in place. Work on a copy. When the copy is better, promote it and keep the old one.

Because ComfyUI embeds the workflow in the PNG it saves, the output images are also a version history — any image you kept can be dragged back in to recover the graph that made it. This is genuinely useful and it only works if you keep the images, so keep them.

For anything shared across a team, put the JSON and its manifest in version control. Diffs on workflow JSON are not pleasant to read, but the history answers "what changed between the version that worked and this one," which is the only question that matters at that moment.

Prune periodically. A folder of forty near-identical graphs with names like v3_new_final is functionally the same as having none.

Practice

Take your most-used workflow and package it. Then run the real test: hand the folder to a colleague on a different machine, say nothing, and watch.

Every question they ask is a missing line in your manifest. Fix those lines and repeat with someone else. Two rounds is usually enough to produce a package that works without you in the room, which is also a package that will work for you after you have forgotten everything about it.

Common mistakes

Sharing the JSON alone. It references things by name and assumes they exist.

Naming a model family instead of a file. Variants behave differently, sometimes very differently.

Installing node packs without looking at them. It is code execution with your permissions.

Editing the working graph in place. The version that worked should always still exist.