Mastering ComfyUI — Part 8: Workflow Management
Keep a growing library of ComfyUI workflows organized, reusable, and recoverable — saving and loading, templates vs subgraphs, naming conventions, backup, and version-controlling workflow JSON.
Goal for this part: keep a growing library of workflows organized, reusable, and recoverable — so six months from now you can find and trust the graph you built today.
Previous: Part 7 — Custom Nodes & Extensions
Workflows are just JSON
Every workflow — every node, every wire, every widget value — is stored as a JSON file describing the graph. This is worth internalizing early: it means workflows are plain text, diffable, versionable, and shareable exactly like code. Each saved workflow you're using is one JSON file on disk.
Saving and loading
Use the Workflows panel (left sidebar, Part 1) to save your current graph with a name, and to reopen any previously saved one. ComfyUI also auto-saves your current in-progress graph so a crash or accidental tab close doesn't lose work-in-progress — but auto-save is not a substitute for deliberately saving a workflow once it's actually working, under a name you'll recognize later.
Name workflows for what they do, not when you made them. Names like
sdxl-basic-txt2img or flux-portrait-hires tell you immediately what each is
for. A pile of workflows named workflow, workflow (1), workflow (2)
becomes useless within a week. Prefer <checkpoint-or-purpose>_<variant>
naming — it mirrors the snake_case convention used throughout this guide series
and keeps your workflow list sorted usefully.
Templates vs. saved workflows vs. subgraphs
These are three different things that are easy to conflate:
- Templates (Part 1) are ComfyUI's own built-in starting points for common tasks — a reasonable base to build from, not something you're expected to keep using unmodified.
- Saved workflows are your own complete graphs, saved exactly as you left them, ready to reopen and run again.
- Subgraphs let you select a group of nodes and collapse them into a single reusable node with its own inputs/outputs exposed — useful once you find yourself copy-pasting the same node cluster (a hires-fix pass, a particular LoRA stack) across multiple workflows. Rather than rebuilding it each time, build it once, convert it to a subgraph, and drop that single node into new workflows going forward.
Reach for a subgraph specifically when you notice repetition — there's no need to prematurely modularize a workflow you're still actively experimenting with.
Organizing a growing library
Once you have more than a handful of workflows, a flat list stops being enough. A few practices that scale:
- Keep one "known-good" version of each core workflow type (a basic SDXL txt2img, a basic Flux txt2img) separate from experimental variants — don't overwrite your working baseline while testing a change; save the experiment under a new name first.
- Periodically prune workflows you know you'll never reopen — old one-off tests clutter the list the same way a downloads folder does.
- For anything you consider genuinely valuable (a complex multi-subject setup, a tuned upscale chain), treat it like the important file it is — see backup below.
Backing up and version control
Because workflows are just JSON, they back up and version like any other text file:
- The simplest safety net: periodically copy your workflow files to a second location (external drive, cloud storage folder) — the same way you'd back up any other important file on this machine.
- For anything more serious, initializing a
gitrepository over your workflows folder gets you real version history: every save becomes a commit, you can diff exactly what changed between two versions of a workflow, and you can revert a broken edit instantly. This is genuinely worth doing once you have workflows you'd be upset to lose — it costs a few minutes to set up and pays for itself the first time an edit breaks something you can't remember how to undo.
The same "it's just a file, back it up like one" logic applies to LoRAs, checkpoints (where feasible given their size), and this kind of creative work generally — treat configuration and creative output with the same care as anything else you wouldn't want to lose.
Sharing a workflow
Because the JSON contains the full graph, sharing a workflow with someone else (or across your own machines) is as simple as sending the file — they can drop it into their own Workflows panel and it will attempt to load, with ComfyUI Manager's missing-node-resolver (Part 7) handling any custom node packs they don't have installed yet. Sharing does not include your checkpoints or LoRAs themselves (those are separate large files) — only the graph structure and settings, so whoever receives it still needs the actual model files referenced by name.
Troubleshooting
Saved workflow won't load / loads with broken or missing nodes. Most commonly a custom node pack referenced by the workflow isn't installed on this machine (see Part 7's missing-node-resolver), or a node type was renamed/removed by a ComfyUI update since you saved it. Check the error detail for the specific node type name it can't find.
Lost track of which workflow version actually produced a specific past result. This is exactly what version control (or, at minimum, deliberate save-as-new-name discipline) is for going forward. Without history, there's no way to reconstruct it after the fact — which is the practical argument for setting up backups before you need them, not after.
Next: Part 9 — Performance & Troubleshooting.
Previous: Part 7 — Custom Nodes & Extensions