20 ComfyUI Workflows You Didn't Know You Needed in 2026 (Production Ready)

20 ComfyUI workflows you didn't know you needed in 2026 (production ready)

Most "best ComfyUI workflows" lists are screenshots of a node graph with a one-line caption. That's fine if you're scrolling Reddit. It's useless if you're trying to figure out which patterns actually survive when 10,000 users hit your API at the same time.

This is a different kind of list. The 20 workflows below are the ones we see running in production across consumer apps, e-commerce platforms, and AI-native SaaS, including the ones inside BetterPic, which is Runflow's parent product and the reason we built this infrastructure in the first place. For each workflow you get: what it does, the JSON shape, the gotchas, and where it slots into a real pipeline.

A note on positioning. I'm Miguel, one of Runflow's two co-founders. We built Runflow after running BetterPic (AI headshots, still shipping, 100K+ jobs/month on the platform) and Better Studio (fashion AI, since sunset). The 20 workflows below are shaped by what we see in our own production and in the ComfyUI community we've spent the last two years inside of. The production notes come from what actually broke. Where that experience colors the advice, I'll say so.

The list is ordered as a maturity ladder. Workflows 1-5 are the foundations every ComfyUI user already runs. Workflows 6-10 introduce identity and style control. Workflows 11-15 are the production-hardening layer. Workflows 16-20 push into video and multi-model territory. Read top to bottom if you're new. Skip to your tier if you're not.

What are ComfyUI workflows?

A ComfyUI workflow is a directed acyclic graph of nodes (model loaders, samplers, conditioners, post-processors, savers) wired together to turn an input into a finished image, video, or audio output, serialized as a JSON file.

ComfyUI didn't invent the node graph pattern. Houdini, Nuke, TouchDesigner, Blender's Geometry Nodes, and a dozen audio tools all use the same visual programming model. What ComfyUI did was make this model the default UI for Stable Diffusion in 2023, and the ecosystem followed: 3,000+ custom node packages, thousands of community workflow shares, and an export format (workflow.json and workflow_api.json) that turned every workflow into a portable, diffable, version-controllable artifact.

That artifact is the part that matters for builders. A ComfyUI workflow is not a prompt and a model choice. It's a graph you can commit to Git, promote from dev to staging to prod, and version like code. Once you treat it that way, the rest of this article makes sense.

How ComfyUI workflows actually work (workflow.json internals)

A ComfyUI workflow.json is a JSON object containing a list of nodes (each with an ID, a class type, inputs, and widget values) and a list of links between node outputs and node inputs, plus optional metadata for the editor view.

There are two flavors you'll encounter. The default workflow.json is the editor format, including layout coordinates and UI state. The workflow_api.json is the leaner API-friendly format, stripped of editor metadata, which is what you submit to ComfyUI's /prompt endpoint when running headless. Most production teams version both: the editor JSON for human review, the API JSON for the server.

A simplified node from a workflow_api.json looks like this:

{
  "3": {
    "class_type": "KSampler",
    "inputs": {
      "seed": 42,
      "steps": 20,
      "cfg": 7.5,
      "sampler_name": "dpmpp_2m",
      "scheduler": "karras",
      "denoise": 1.0,
      "model": ["4", 0],
      "positive": ["6", 0],
      "negative": ["7", 0],
      "latent_image": ["5", 0]
    }
  }
}

The ["4", 0] syntax is the link: this node's model input comes from node "4" output slot 0. That's the whole graph in one pattern. Every link, every dependency, every connection point is one of these tuples. Once you can read this, every workflow in the rest of this article is just a longer version of the same JSON.

Why this matters for production: workflow.json is diffable. You can git diff two versions of a workflow and see exactly which sampler changed, which LoRA was added, which conditioning node was rewired. No other AI image stack gives you this. Treat it accordingly.

The 20 ComfyUI workflows every builder should know

These are organized into four maturity tiers. Each workflow gets the same treatment: what it does, the shape of the JSON, what breaks in production. We're not embedding every workflow.json inline (this article would be 80,000 words) but the structure for each is described concretely enough that you can build it yourself or pull a matching template from the libraries listed in the next section.

Image generation foundations (workflows 1-5)

These are the canonical workflows that ship with ComfyUI by default or appear in the first hour of any tutorial. If you've built anything in ComfyUI, you already run these.

1. Text-to-image (the SDXL/Flux baseline)

The simplest possible workflow. CLIPTextEncode for positive and negative prompts, a UNet/Flux model loader, a KSampler, a VAE decoder, a SaveImage node. Five nodes minimum. Every other workflow on this list is a variation on this base. If you can't read the JSON for this one, the others won't make sense.

Production note: the difference between a SDXL text-to-image and a Flux text-to-image is the sampler scheduler (Flux Schnell uses a different solver) and the conditioning shape. Don't copy-paste between them blindly.

2. Image-to-image with denoise control

Same as workflow 1 but with a LoadImage node feeding into a VAEEncode, then into the KSampler's latent_image input instead of an EmptyLatent. The denoise parameter (0.0 to 1.0) controls how much the original image survives.

Production note: denoise values below 0.4 give you small edits, 0.6-0.8 gives you the variation sweet spot, 1.0 is functionally text-to-image. Most teams hardcode this per workflow rather than exposing it to end users.

3. Inpainting with a mask

LoadImage and LoadImageMask feed into a VAEEncodeForInpaint node, then into the sampler. The mask defines the region to regenerate. The unmasked area stays untouched (in theory).

Production note: ComfyUI's stock inpainting often leaves a visible seam at the mask boundary. The fix is either a feathered mask (GaussianBlur on the mask before encoding) or running a second pass with low denoise on the full image to harmonize the seam. The community workflows that solve this well stack 2-3 nodes for mask refinement before they hit the sampler.

4. Outpainting (canvas extension)

A LoadImage feeds into a PadImageForOutpainting node, which adds black pixels in the requested direction and produces a mask covering those pixels. Then standard inpainting fills the new region.

Production note: outpainting that extends by more than 50% of the original image dimension in one pass falls apart. Iterate in smaller steps (25-30% per pass) for stable results. Several community workflows automate the iteration loop.

5. ControlNet conditioning (depth, canny, pose)

A LoadImage feeds into a preprocessor (DepthMidasPreprocessor, CannyEdgePreprocessor, OpenPosePreprocessor), then into a ControlNetApply node that mixes the conditioning into the sampler's positive prompt path. Strength and start/end percent control how aggressively the ControlNet steers the output.

Production note: stacking three ControlNets (depth + canny + pose) is where teams shoot themselves in the foot. Each ControlNet adds VRAM overhead and the conditioning signals start to fight each other. Two is the practical limit. If you need three, train a fused conditioning model instead.

Identity, style, and brand consistency (workflows 6-10)

These workflows take a reference (a face, a style, a brand) and propagate it across many generations. They're the difference between "AI art" and "AI art that doesn't look like AI art."

6. LoRA-stacked generation

The base text-to-image workflow with one or more LoRALoader nodes inserted between the checkpoint loader and the sampler. Each LoRA has a strength_model and strength_clip value.

Production note: stacking LoRAs is multiplicative, not additive. Three LoRAs at 0.8 each is functionally a 0.5 of each because the cross-attention weights compete. Two LoRAs at 0.7 each is the realistic ceiling for clean output. If you need brand + character + style, train a single composite LoRA.

7. IP-Adapter reference workflow

A LoadImage (the reference) feeds into a CLIPVisionEncode, then into an IPAdapterApply node that injects the reference embedding into the sampler conditioning. You can apply IP-Adapter to faces, products, or general style.

Production note: IP-Adapter Plus and IP-Adapter Face are different models with different optimal strengths. Face needs ~0.7-0.9 to hold identity; Plus needs ~0.4-0.6 to avoid overpowering the prompt. Tune per workflow. There's no universal default that works.

8. InstantID / face identity preservation

A specialized variant of IP-Adapter optimized for face identity. Uses a face detector (RetinaFace or similar) to extract the face region, embeds it through a dedicated identity encoder, and conditions the sampler tightly on that embedding.

Production note: InstantID and PuLID give better identity preservation than vanilla IP-Adapter Face, but both add 3-5 GB of VRAM and 30-50% inference time. For consumer-facing apps where every second matters, this tradeoff is usually worth it. BetterPic's headshot pipeline runs a variant of this at scale (see the AI image workflows guide, use case 2).

9. Style transfer via image conditioning

Two LoadImage nodes: one for the structural reference (your subject), one for the style reference (the look you want). The style image goes through IP-Adapter or a style-specific module while the structural image conditions via ControlNet or img2img. The sampler renders the subject in the style.

Production note: this works well when style and content are visually distinct. It falls apart when the style reference contains strong subjects (a portrait styled like another portrait will often blend the two faces). Pick style references that are texture-heavy and subject-light.

10. Multi-LoRA character + style composition

A more controlled version of workflow 6: one LoRA for character identity at 0.7, one LoRA for art style at 0.5, with a clean text prompt for the scene. Often combined with a low-strength ControlNet for pose control.

Production note: this is the workflow most consistent-character storyboarding tools use under the hood. The trick is training your character LoRA with style-neutral training data so it doesn't fight the style LoRA at inference time.

Production image pipelines (workflows 11-15)

This is where the article gets honest about what separates a workflow demo from a feature you can ship. These five patterns handle the layers that come after the generation model: cleanup, scaling, retry, batch.

11. Face restoration chain (GFPGAN + CodeFormer)

The base generation feeds into a FaceDetailer or equivalent node that runs face detection, crops detected faces, processes each through GFPGAN or CodeFormer at a higher resolution, then composites them back into the original image.

Production note: face restoration models add their own bias. GFPGAN tends to over-smooth, CodeFormer tends to add a slight plastic sheen. Pick based on your aesthetic. For headshot use cases (use case 2 in our AI image workflows guide), this step is non-optional. Without it, ship rate drops by 30-40%.

12. Upscaling chain (Real-ESRGAN + SUPIR)

A two-stage upscale: Real-ESRGAN (or 4x-UltraSharp) for the 2x-4x bump, optionally followed by SUPIR for diffusion-based detail enhancement on the result. SaveImage at the end with quality controls.

Production note: SUPIR hallucinates. It will invent buttons on a shirt, text on a sign, freckles on a face that weren't in the original. Beautiful for hero shots, dangerous for product catalogs. The two-model split lets you pick: Real-ESRGAN for faithful upscale, SUPIR for creative upscale, never the second one for legal or commerce work.

13. Background removal + replacement (SAM + inpaint)

A LoadImage feeds into a SAM (Segment Anything) or BiRefNet segmentation node, which produces a clean alpha mask. The mask drives an inpainting pass that replaces the background with a prompt-described scene. A relighting pass (often a small dedicated model) harmonizes the lighting between subject and new background.

Production note: mask quality is everything here. Naive segmentation leaves halos around hair and translucent objects, which kills the composite. Matting models (BiRefNet, MODNet) outperform segmentation models for this use case. Run a mask refinement pass before the inpaint.

One production pattern we tested in May: a two-pass pipeline using Runflow's background-removal endpoint ($0.045/call, 3s) for the alpha cutout, then GPT Image 2's edit mode ($0.30/call) for re-rendering the subject into a new scene with relighting. The second pass re-synthesizes the entire frame in one go, which means subject and background share one noise distribution and pass forensic integrity checks (ELA) that cutout-and-composite never will. The honest limit: that second pass re-renders the subject pixels too, so it doesn't preserve identity at the pixel level. For brand-controlled face cases, you'd need a third pass with masked relighting on just the boundary zone.

14. Quality scoring + retry loop

The output of any generation feeds into a quality scoring step that checks the result before delivery. If the score fails, the workflow retries with a new seed. The scoring approach matters: CLIP-based aesthetic scorers are cheap but miss use-case-specific failures (wrong logo, face drift, garment errors). Face-match checks catch identity problems but nothing else. A production gate needs multiple dimensions at once.

Production note: this is the single workflow that separates products from demos. Without a quality gate, you ship 5-15% of bad outputs and they become refund tickets. ComfyUI's native looping is limited, so most production teams handle the retry outside ComfyUI in their orchestration layer, calling the workflow N times with different seeds and picking the best.

This is what Sentinel does. Three-stage pipeline: a Router that creates a dynamic evaluation plan per input, Preprocessors that extract structured data (segmentation, face similarity models, mathematical color checks, pose estimation running in parallel), and per-dimension LLM Judges that score each aspect independently. The dimensions aren't fixed; Sentinel decides what to evaluate based on the use case description. Acceptance criteria are configured in plain text ("the garment must match the reference stitching pattern and color"), not numerical thresholds. $0.05 per evaluation, flat. BetterPic runs 7 different Sentinel configs across its workflow types, generates 240 candidates per user, and ships only the top 60. Zero manual QA. Most common defects caught in production: text errors, wrong coloring, product fidelity issues, face drift, distorted hands, and logo misplacement. The full BetterPic case study is in the AI image workflows guide.

15. Batch processing with metadata pass-through

A LoadImagesFromDirectory or LoadImageBatch node feeds N inputs through the same workflow graph in a single execution. Each output is tagged with metadata (input filename, seed, settings) via a SaveImageExtended node so you can trace which inputs produced which outputs.

Production note: native batch processing in ComfyUI is memory-hungry because it tries to hold all latents in VRAM. For batches over 8-16 images depending on resolution, run them as separate prompts queued to the same warm worker rather than as one batch. Throughput is the same; memory pressure drops to manageable.

Video and multi-model workflows (workflows 16-20)

These are the workflows that didn't exist 18 months ago. Video diffusion, audio-conditioned animation, and LLM-routed graphs are where ComfyUI is actually pushing the frontier in 2026.

16. Image-to-video (Wan, Kling, Hunyuan)

A LoadImage feeds into a video model loader (Wan 2.2, Hunyuan Video, or a Kling API node) along with a motion prompt. The model generates 24-48 frames. A frame interpolation pass (RIFE or FILM) doubles framerate. A VideoCombine node assembles and exports as MP4.

Production note: VRAM is the killer. Wan 2.2 needs 24-40GB depending on resolution and frame count. Even quantized, you're on a single 24GB GPU running at the edge. For consumer-facing video generation, hosted APIs (Kling, Runway) are often the right call until VRAM efficiency improves.

17. AnimateDiff temporal consistency

For style-driven animation rather than realistic video. An AnimateDiffLoader injects a motion module into a standard SDXL workflow, which makes the sampler aware of temporal context. The result is a 16-32 frame clip with consistent style and identity across frames.

Production note: AnimateDiff is good for stylized motion (anime, illustrated, abstract). It's bad for realistic human motion. For realistic video, jump to workflow 16. For stylized loops, this is still the standard.

18. Multi-model routing in one graph

A conditional workflow that routes to different models based on input characteristics. Example: a Switch node that detects whether the input prompt is portrait-oriented or landscape-oriented and routes to a different LoRA stack. Or a quality classifier that runs a fast model first and only escalates to a heavy model if the fast output fails a check.

Production note: ComfyUI's native conditional logic is limited. Most multi-model routing happens in the orchestration layer (your API server) rather than in the workflow itself. The pattern is to expose N workflows and pick between them in your application code, not in the JSON graph. One concrete routing pattern we run: GPU auto-promotion. A job starts on the cheapest tier (RTX 4090), and if it OOMs, the orchestrator promotes it to the next tier (L40S, then A100, then H100) automatically. The working GPU tier is persisted at the workflow level so future runs skip the trial-and-error. Simple, but it saves users from guessing GPU requirements for every workflow they deploy.

19. Audio-to-video (lip sync, voice-driven animation)

A LoadAudio node feeds into a phoneme extraction step, which conditions a face animation model (LatentSync, MuseTalk, or similar) along with a portrait image. The output is a video where the portrait lip-syncs to the audio.

Production note: lip sync quality varies wildly by language and audio quality. English audio with clear speech works well; multilingual or background-noise-heavy audio falls apart. Pre-process audio with noise reduction and silence trimming before feeding it to the workflow.

20. Agentic workflows (LLM-controlled node selection)

A newer pattern: an LLM node (Claude, GPT, or a local model) reads the user's input and decides which sub-workflow to run, what parameters to set, and how to chain the results. The LLM acts as a router and parameter optimizer inside the graph.

Production note: this is genuinely useful for end-user-facing tools where users describe what they want in natural language rather than picking from a workflow menu. It's also expensive (extra LLM call per request) and adds a non-deterministic step that complicates debugging. Use it when the input space is too varied for fixed workflows. We ran a livestream demo in April where Claude Code controlled a local ComfyUI instance via its REST API: queued prompts, downloaded missing LoRAs, ran batch generations, and self-diagnosed a broken audio-conditioning node (encoded but never wired into the sampler) without human intervention. The pattern works. The debugging story when it doesn't is still painful.

Where to find and download ComfyUI workflows

The most useful sources for downloading ComfyUI workflows in 2026 are Comfy.org's official gallery, ComfyWorkflows.com (community-driven), OpenArt's ComfyUI section, Civitai, RunComfy's curated catalog, and the ComfyUI examples GitHub repo. Each has tradeoffs around quality, license, and version freshness.

Two warnings nobody on the SERP gives you. First, check the license on every downloaded workflow. Many community workflows embed model references (LoRAs, custom nodes) that have non-commercial licenses, which means the workflow itself is fine but using it commercially requires swapping those out. Second, version-staleness is real. A workflow uploaded in mid-2024 may reference custom nodes that have changed APIs since. The fix is pinning, which is the next section.

For our own production stack, Runflow maintains 17 validated workflows that map to the patterns above, with version pinning and environment management (dev, staging, prod) baked in. Honest framing: that's our product, not a community library. If you want free workflows to learn from, comfy.org and comfyworkflows.com are the best starting points.

How to run ComfyUI workflows in production

Production-grade ComfyUI workflows need five hardening layers: version pinning, warm worker pools, automated quality gates, observability, and per-workflow cost tracking. Skipping any one of them is how 3 AM pages happen.

"ComfyUI is notoriously hard to productionize" has appeared word-for-word across SimpliSmart, Cerebrium, BentoML, and multiple GitHub discussions, independently and unprompted. The gap between "it works on my GPU" and "it serves 1,000 users via API" is real and measured: the community's top 5 pain points are (1) no standard API with WebSocket failures on ~1 in 5 calls, (2) dependency hell across custom nodes, (3) cold starts of 60-120 seconds, (4) zero built-in security with 1,000+ exposed instances on Shodan, and (5) no scaling beyond single-user sequential execution. Those five drove us to build Runflow Deploy. Each layer below addresses one or more of them.

Version pinning. ComfyUI ships an update almost weekly. Custom nodes update on their own cadence. A workflow that ran clean yesterday returns a different image (or errors out) tomorrow because some dependency changed an output shape. The fix is pinning everything: ComfyUI version (specific git commit), custom node packages (specific releases), model checkpoints (specific file hashes). Treat the workflow + its environment as a single immutable artifact.

We take this further with a runtime fingerprint: a hash of the org ID, workflow ID, GPU type, ComfyUI version, custom node versions, and Python package lockfile. When a job arrives, the orchestrator checks if any warm worker has a matching fingerprint. If it does, ComfyUI stays alive and the job runs immediately with zero reinstall. If it doesn't, the worker kills the current process, sets up the new environment, and starts fresh. This is the mechanism behind container reuse at scale, and it's the single biggest factor in whether your users experience 3-second starts or 90-second ones. The ComfyUI API developer's guide covers the broader pinning pattern in detail.

Warm worker pools. Cold starts are brutal. Community-measured cold starts for ComfyUI on serverless infrastructure run 60-120 seconds, with model loading alone accounting for 30-60 of those seconds. Custom node and Python package installation is fast (a few seconds), but model download from source can hit 10-20+ minutes if nothing is cached locally. The production pattern is to keep N warm workers per workflow type, sized to your traffic shape, so incoming requests hit a hot container. Pure autoscaling without warm pools means your first user after a quiet period gets a 90-second wait.

Automated quality gates. Already covered in workflow 14 above, but worth restating: every production workflow should produce a quality score before delivery. Sentinel handles this by dynamically evaluating each output across whatever dimensions the use case requires (face fidelity, product accuracy, text correctness, background quality, style drift, logo placement). $0.05 per evaluation, with acceptance criteria configured in plain text. Details and the BetterPic proof point are in workflow 14 above.

Observability. Per-workflow metrics: P50/P95/P99 latency, success rate, quality score distribution, GPU utilization. When a user complains that "the generations got worse this week," you need to be able to answer "yes, the LoRA fingerprint hash changed at commit X" within minutes, not days. Most ComfyUI deployments have zero of this and find out by reading their Twitter mentions.

Per-workflow cost tracking. GPU bills don't itemize. By the time you're at $20K/month spend, finding out which workflow eats 40% of compute is a 2-week archaeology project unless you instrumented from day one. Tag every job with workflow ID and workflow version. Aggregate cost by tag.

Runflow Deploy was built around these five layers because BetterPic was running workflow 8 (InstantID face identity) at 100,000+ jobs a month, and we hit every one of these problems the hard way. Per-second GPU billing (A100 80GB at $4.93/hr, H100 at $5.96/hr, zero idle cost), per-org worker isolation, Sentinel scoring in the pipeline, and per-workflow cost attribution are the specific product responses. The ComfyUI API endpoints reference covers the underlying mechanics if you want to build this yourself.

Workflow versioning and JSON internals (advanced)

Production ComfyUI workflows should be versioned like code: workflow.json committed to Git, environments pinned, semantic versioning applied, and changes promoted dev to staging to prod with regression tests at each gate.

Four patterns worth knowing if you're operating workflows at scale.

workflow.json vs workflow_api.json. The editor format (workflow.json) is what ComfyUI saves when you hit "Save" in the UI. It includes layout coordinates, group boxes, and editor state. The API format (workflow_api.json) is what you get from "Save (API Format)" and is what you POST to /prompt. They're structurally different. Production teams version both: editor format for humans to review in PRs, API format as the source of truth for the running server.

Semantic versioning for workflows. Tag workflow.json files with semver: face-restoration-v2.3.1.json. Major version bumps mean a breaking API change (new required inputs, removed outputs). Minor version bumps mean new optional inputs or models. Patch versions are bug fixes or parameter tweaks. This lets you migrate consumers gradually instead of breaking everyone at once.

Diff-friendly JSON. ComfyUI's exported JSON isn't pretty-printed by default and uses integer node IDs that change every time you save. The fix is a normalization step: sort node IDs lexicographically, pretty-print with 2-space indent, sort keys alphabetically. Once normalized, git diff between two workflow versions shows actual semantic changes, not noise. Most teams write a small pre-commit hook to normalize.

Runtime fingerprint for container reuse. At deploy time, Runflow's orchestrator computes a fingerprint from the workflow's full dependency tree: org ID, workflow ID, GPU type, ComfyUI version, custom node versions, and Python package lockfile. Workers report their current fingerprint on heartbeat. When a job arrives, the orchestrator routes it to a worker with a matching fingerprint (zero setup, immediate execution) before considering cold workers. This is the infrastructure version of "warm workers per workflow type." Input values are wrapped in template brackets ({{input_id}}) on deploy and substituted at runtime, so the same versioned workflow serves different users and inputs without a rebuild.

If your workflows are running real traffic, treat their JSON the way you treat your application code. The teams that don't end up rewriting their workflow library every six months because they can't remember which version worked.

FAQ: ComfyUI workflows

What is a ComfyUI workflow?
A ComfyUI workflow is a directed graph of nodes (model loaders, samplers, conditioners, post-processors) wired together to produce an image, video, or audio output from an input. It's serialized as a JSON file that can be saved, shared, version-controlled, and run via the ComfyUI API.

How do I download ComfyUI workflows?
The main sources are comfy.org/workflows (official), comfyworkflows.com (community), openart.ai, civitai.com, and runcomfy.com. Each has different curation standards and licensing. Always check the license and verify the workflow's custom node dependencies before running.

Where are ComfyUI workflows saved?
By default, ComfyUI saves workflows to the user/default/workflows/ directory inside your ComfyUI installation. You can change this path in the settings, and many users move workflows to a Git-tracked directory outside the install for version control. On Runflow, workflows are stored as versioned entities with environment pinning and promotion (dev, staging, prod) baked in.

What's the difference between workflow.json and workflow_api.json?
The workflow.json is the full editor format including layout and UI state. The workflow_api.json is the leaner API format used when submitting to ComfyUI's /prompt endpoint. They're not interchangeable; production deployments use the API format.

What are the best ComfyUI workflows for Flux?
Flux works best with text-to-image, IP-Adapter (Flux-compatible variants), and ControlNet workflows. Flux Schnell is faster but lower quality; Flux Dev produces better outputs but is non-commercial. Workflows 1, 2, 5, and 7 above all have well-tested Flux variants.

Can I run ComfyUI workflows commercially?
That depends entirely on the models and LoRAs in the workflow. Flux Schnell, SDXL, and Stable Diffusion 1.5 are commercial-friendly. Flux Dev is non-commercial. Many community LoRAs have CC-BY-NC licenses. Always verify the license of every model in the workflow before shipping.

How do I share ComfyUI workflows with my team?
Commit the workflow.json (and workflow_api.json) to a Git repository alongside any custom node references and model checkpoints (or hash-pinned references). For larger teams, a registry pattern works better: a central system that stores workflows by ID and version, with environment-pinned execution. This is the pattern Runflow exposes via its deploy platform.

What are ComfyUI workflow templates?
Templates are pre-built workflows designed to be customized rather than used as-is. They cover common patterns (text-to-image, face restoration, upscaling) with reasonable defaults. The ones bundled inside ComfyUI's official examples are the safest starting point because they're maintained alongside the core release.

How do I version control ComfyUI workflows?
Save the workflow as JSON, commit it to Git, and pin everything it depends on (ComfyUI commit, custom node versions, model checkpoint hashes). Use a normalization step (sort keys, pretty-print) so diffs are meaningful. Tag releases with semver to signal breaking vs additive changes.

Why do ComfyUI workflows break after updates?
Custom nodes change their input/output shapes between versions, ComfyUI core changes default behaviors, and model checkpoint references may point to files that have been updated. Dependency conflicts are the #2 most severe pain point in the ComfyUI community (behind API design), documented across Reddit, GitHub issues, HN threads, and Discord. Python 3.12 alone caused a cascade of custom node failures that took weeks to resolve across the ecosystem. The fix is pinning every dependency to a specific version (or commit hash for git-based custom nodes) so updates only happen when you explicitly opt in.

What's the maximum complexity of a ComfyUI workflow?
There's no hard limit, but practical ceilings exist. VRAM caps how many models you can load simultaneously. Execution time scales with node count. Workflows above ~50 nodes become hard to maintain visually. Most production workflows split complex pipelines into smaller workflows orchestrated externally rather than building one giant graph.

Can I run ComfyUI workflows without a GPU?
Yes, but slowly. CPU-only inference runs at 50-200x slower than GPU. For testing workflow structure, CPU works. For real output, you need a GPU with at least 8 GB VRAM for SD 1.5 workflows, 16 GB for SDXL, and 24 GB+ for Flux or video workflows.

Where to go next

If you're going to build production workflows on top of any of the 20 above, here's the order I'd work in:

1. Pick three workflows that map to your actual use case. The ladder is 1-5 (foundations), 6-10 (identity/style), 11-15 (production layers), 16-20 (video and multi-model). Most products only need three or four. Don't try to ship all 20.
2. Get them running locally first. Build the graph in ComfyUI, export both workflow.json and workflow_api.json, commit to Git. This is your source of truth.
3. Add the quality gate (workflow 14) before you add features. Every other improvement is faster when you can score outputs automatically.
4. Pin your environment. ComfyUI commit, custom node versions, model hashes. Document the pins in a README next to the workflow JSON.
5. Read the ComfyUI API developer's guide. When you're ready to call your workflow as a service instead of running it manually, this is the next read.
6. Skim the ComfyUI API endpoints reference. Bookmark it. You'll need it the first time something breaks.
7. Compare ComfyUI cloud providers. When you've outgrown localhost, that roundup covers the five real options with honest verdicts.
8. Look at Runflow when the infra layer is eating your week. When ComfyUI updates break production every other Tuesday and you're spending more time on pinning than on workflows, that's the signal.

The workflow is the unit of work. Every other decision (which model, which GPU, which hosting platform) is downstream of getting the workflow right first. Build accordingly.