10 Best Use Cases of AI Image Workflows in 2026

10 Best Use Cases of AI Image Workflows in 2026

Most articles about "AI image generation" stop at the model. Pick Flux, pick Imagen, pick Nano Banana, ship. That's fine if you're generating one image for a blog post. It falls apart the moment you try to do this 100,000 times a month for paying users.

What product and engineering teams actually build is a workflow: a chain of steps that takes an input (a user photo, a prompt, a brand asset, a SKU), runs it through one or more models, post-processes the result, scores it for quality, and ships it back to the caller. The model is one node in that graph. Sometimes it isn't even the hardest node.

This article covers the 10 workflows we see running in production right now, across e-commerce, consumer apps, marketing teams, and ML pipelines. For each one: the business problem, the workflow shape, the production gotchas, and who's actually running it. No model rankings. No "you won't believe number 7." If you're building a visual feature into your app and want to know what shapes the work actually takes, this is for you.

A note on where this comes from. Runflow's two co-founders ran the consumer side of this market before pivoting to infrastructure. BetterPic (AI headshots, still in market, 100K+ jobs a month). Better Studio (a fashion AI consumer product, since sunset, where Graswald is the equivalent player today). We pivoted because the consumer products kept teaching us the same lesson: the infrastructure underneath the model was the bigger and harder business. The 10 workflows below are shaped by what broke at our own companies and at the brands now testing or running on Runflow. Where a workflow is one I've personally watched fall over in production, I'll say so.

What is an AI image workflow?

An AI image workflow is a chained sequence of nodes (input handling, one or more generation or editing models, post-processing, and quality checks) that turns a structured request into a finished image, repeatedly and reliably.

The word "workflow" matters. A single API call to a hosted text-to-image endpoint is a request. A workflow is what you build when one request isn't enough: a face-restoration pass after generation, a background swap before delivery, a quality classifier that rejects bad outputs and retries, a LoRA loaded on top of a base model so brand consistency holds across 10,000 generations.

ComfyUI made this pattern visible by turning the graph into a UI. Most production AI image systems today, whether they're running ComfyUI under the hood or a custom pipeline, look like a directed graph: nodes for input, nodes for models, nodes for post-processing, nodes for output. The teams that ship visual features in their apps think about this graph the way backend engineers think about request lifecycles.

The anatomy of a production AI image workflow

Every production AI image workflow has five layers: input handling, model execution, post-processing, quality evaluation, and delivery. Skip any one and you'll feel it within a week of going live.

Here's the shape, in plain terms:

The 10 use cases below are variations on this anatomy. The interesting differences are in which layer gets the most attention and which model combinations sit in the middle. Keep this five-layer picture in mind. It's the only structural model you need to read the rest of this article cleanly.

Use case 1: e-commerce product photography at scale

E-commerce AI image workflows generate product-on-white, lifestyle, and multi-angle shots from a single reference photo, replacing studio shoots for the long tail of a catalog.

The business problem is simple math. A studio shoot for one SKU runs $200 to $2,000 by the time you've paid for the photographer, the model, the location, the editor. A Shopify store with 5,000 SKUs cannot shoot all of them. So they shoot the hero products and live with stock photography or terrible phone shots for the rest. AI image workflows close that gap.

The workflow shape: a single reference photo (often a flat-lay or a quick phone shot) goes in. A masking step isolates the product. An image-to-image generation pass renders the product in a new scene (lifestyle, on-model, in context) using ControlNet to preserve the product's exact shape and proportions. A face-restoration pass cleans up any models in the shot. A background harmonization pass blends lighting and shadows. Output is delivered as multiple aspect ratios for the storefront, ad platforms, and social.

Production gotchas: identity drift on the product itself is the first one. ControlNet conditioning has to be tight enough that the actual shoe in the photo is the actual shoe in the output, not "a similar shoe." Teams that get this right run reference conditioning with both depth maps and canny edges, not just one. The bigger gotcha is the upstream model silently degrading. We had a pilot last month with a digital-first fashion brand whose pipeline (CLO 3D source, ComfyUI, Nano Banana Pro) started producing phantom pockets and ghost sleeve plackets that weren't in the 3D file. The hosted model was silently downgrading under load with no notification, and the inpainting step was dropping their 3,000x4,000 px marketplace requirement down to a resolution they had to Photoshop back up. The fix that worked in production was masked inpainting at original resolution on reserved capacity. None of that shows up in a model leaderboard.

Who's running this: Shopify brands with 1,000+ SKUs, marketplaces like Etsy and Faire on the seller-onboarding side, and any e-commerce platform that wants to offer "AI-enhanced product photos" as a feature. See the product photography automation playbook for the marketplace-spec layer on top.

Use case 2: AI headshots and identity-preserving avatars

Headshot workflows train a temporary identity model (LoRA or embedding) from 10-20 user selfies, then generate dozens of styled portraits while preserving the user's likeness.

Disclosure up front: this is the workflow Runflow grew out of. BetterPic, Runflow's parent product, has been running this pipeline since 2023 across hundreds of thousands of paying users. The notes below come from that, so take them with the bias acknowledged.

The business problem: professional headshots cost $200 to $500, take a week of scheduling, and most people redo them every 2-3 years. The market for "good headshot, no studio" is enormous, which is why a dozen consumer apps have been built on this exact workflow.

The workflow shape: user uploads 10-20 selfies. A face-detection pass filters out bad inputs (no face, multiple faces, sunglasses, blurred). A LoRA or textual inversion training step runs, typically 500-2000 steps on a small custom model. The trained identity is then used as conditioning during generation across N styles (corporate, casual, outdoor, studio lit). Each generation goes through face restoration, then a face-match classifier that compares the output to the input embeddings and rejects anything below a similarity threshold. Survivors are upscaled and delivered.

The production-grade move (from running BetterPic at scale): generate 4x more candidates than you ship and let the scorer choose. BetterPic generates 240 headshots per user, runs each through Sentinel face-fidelity scoring plus seven other quality dimensions, and only delivers the top 60. Manual QA went to zero. The headshot product runs at 87% gross margin because of that scoring step, not because of model choice.

Production gotchas: the quality gate is what separates a working product from a refund machine. Without face-match scoring, you ship 5-15% of outputs that look like "a person who could be the user's cousin," and customers notice immediately. The second gotcha is the cold-start cost of training. If every user request triggers a fresh LoRA training run, your GPU bill is brutal. Teams running this profitably batch users into training cohorts or share compute across the training and inference fleet.

Who's running this: BetterPic, Aragon, HeadshotPro, Secta Labs, plus a long tail of vertical headshot apps for real estate, LinkedIn, dating. See the AI headshot generator API roundup for a vendor-by-vendor comparison.

Use case 3: marketing creative and ad variants at scale

Marketing workflows take one creative concept and a brand kit, then output dozens of platform-sized variants (Meta feed, TikTok, YouTube thumbnail, display banners) as a single batch.

The business problem: a single ad campaign needs 30+ creative variants by the time you account for placements, aspect ratios, A/B test cells, and audience segments. Designers can't keep up, so most variants end up as cropped versions of the hero asset, which Meta and TikTok algorithms penalize.

The workflow shape: input is a creative brief (headline, key visual, brand kit). A layout model generates the composition. A text rendering model (GPT Image 2 and Ideogram v3 are the current leaders here) places the copy with correct kerning and brand fonts. A background generation pass creates the scene. Brand-kit conditioning (logo placement, color palette enforcement) runs as a post-process. The output is then resized and recomposed for each target placement, with smart cropping that respects the focal point.

Production gotchas: text rendering is still where these pipelines fail most often. Even with the latest models, you'll see misspellings and broken kerning on 10-20% of outputs, which means a human-in-the-loop check is mandatory before publishing. The second gotcha is brand color drift: AI models hallucinate close-but-wrong shades of brand colors unless you post-process with a strict color-replacement step.

Who's running this: in-house creative teams at DTC brands, ad agencies running performance marketing at scale, platforms like AdCreative.ai and Pencil that productize this workflow.

Use case 4: personalized in-app image generation (user-facing)

In-app workflows expose AI image generation as a feature inside a SaaS product, where the user's input (a prompt, a reference, a profile) drives a tightly-scoped generation pipeline returning images in seconds.

This is the category Runflow's API customers fall into most often, so calling it out plainly: if you're building a feature like "users can generate a custom cover image for their post," this is your shape.

The business problem: you're not Midjourney. You don't want to expose model selection, sampler choice, or prompt engineering to your users. You want to expose a button that says "Generate cover image" and have it return something good in under 10 seconds, on-brand, every time. That requires hiding the entire workflow behind a single API contract.

The workflow shape: user action triggers an API call with structured inputs (not a free-text prompt, usually). The workflow expands the structured input into a model-ready prompt using a small LLM. Generation runs with brand-safe conditioning and a fixed style LoRA. Post-processing applies any required overlays or watermarks. A safety classifier checks for NSFW or policy violations. The image is uploaded to your CDN and the URL returned via webhook or polled status endpoint.

Production gotchas: latency budget is the hard one. Users will tolerate 5-8 seconds, not 30. That means cold starts kill you, so warm workers per workflow type are mandatory. The second gotcha is observability: when a user complains that "the generations got worse this week," you need per-workflow versioning to roll back. Without it, you're diffing screenshots from Slack.

Who's running this: Canva, Notion, HubSpot, every SaaS product that has shipped an AI image feature in the last 18 months, plus the long tail of vertical SaaS with image generation as a wedge feature.

Use case 5: brand-consistent generation via LoRA fine-tuning

LoRA workflows train a small adapter (50-200MB) on a brand's visual style or product line, then load it on top of a base model at inference time to enforce visual consistency across thousands of generations.

The business problem: stock-prompt generation produces images that look like AI generated stock. A brand with a real visual identity (signature color, lighting, mood, illustration style) can't ship that. The cheap fix is prompt engineering, which works for the first 20 images and then drifts. The durable fix is LoRA fine-tuning.

The workflow shape: training is a one-time job. Curate 30-100 images that represent the brand style. Run LoRA training (1-3 hours on a single A100, depending on rank and steps). Validate the checkpoint by generating test prompts and checking style adherence. At inference time, the LoRA loads on top of the base model (Flux, SDXL, whichever) and conditions every generation. The rest of the workflow looks like any other generation pipeline.

Production gotchas: LoRA stacking is where teams shoot themselves in the foot. Loading three LoRAs at once (brand style + character + lighting) will VRAM-thrash on a 24GB GPU and produce washed-out outputs because the cross-attention weights fight each other. Train a single composite LoRA or accept that you can only stack two cleanly. The second gotcha is staleness: your brand's visual identity will shift, and the LoRA won't follow. Plan a retraining cadence (we see quarterly as standard).

Who's running this: any DTC brand with a distinct visual identity (Liquid Death, Magic Spoon, Glossier-style), illustration-heavy SaaS (Notion, Linear), and creative agencies that maintain brand-specific LoRAs as client deliverables.

Use case 6: image-to-video pipelines

Image-to-video workflows take a generated or uploaded still and animate it into a 3-10 second clip using a video diffusion model (Wan, Kling, Hunyuan), often with camera control and prompt-guided motion.

The business problem: static images are losing the engagement battle on TikTok, Reels, and YouTube Shorts. The fastest way for a content team to ship video without learning DaVinci Resolve is to generate the image, then animate it. The output isn't a feature film, but it's enough for a 5-second hook in a paid ad or organic post.

The workflow shape: a still image (generated upstream or uploaded) goes in along with a motion prompt ("slow zoom in, leaves rustling, soft camera shake"). The video diffusion model generates 24-48 frames. A frame interpolation pass (RIFE, FILM) doubles the framerate for smoothness. An upscaling pass takes the output from 480p or 720p up to 1080p. Audio (if needed) is layered separately. Final encode is delivered as MP4.

Production gotchas: VRAM is brutal. The current generation of open video models (Wan 2.2, Hunyuan Video) needs 24-40GB just for inference, and that's after quantization. The second gotcha is identity drift across frames: faces and products morph subtly between frames unless you condition aggressively with the input image. Teams running this in production are either accepting short clips (3-5 seconds) or using closed APIs (Kling, Runway) and paying the per-second cost.

Who's running this: social media managers at consumer brands, AI-native ad platforms (Arcads, HeyGen for talking-head use cases), and any product that has shipped an "animate this image" button.

Use case 7: background replacement and product staging

Background workflows mask out the subject of an existing photo, generate a new background scene around it, and blend lighting and shadows so the composite looks like one shot.

The business problem: most product photography is shot on white or in one location, but storefronts and ad platforms want lifestyle imagery showing the product in different contexts. Reshooting is expensive, so you stage the same product photo into dozens of scenes.

The workflow shape: input is a product photo. Segmentation (SAM, BiRefNet, or a fine-tuned matting model) extracts a clean alpha mask of the subject. The original background is discarded. A prompt-driven inpainting or outpainting model generates the new scene around the subject. A lighting harmonization pass (often a small dedicated model or a diffusion-based relighting step) matches the subject's lighting to the new background. Shadow generation adds a contact shadow under the subject. Output is the composite.

Production gotchas: mask quality is the entire game. A 1-pixel halo around the subject ruins the composite, and naive segmentation models leave halos around hair, fur, and translucent objects. Teams running this in production are running matting models (not segmentation), often with a refinement pass.

The second gotcha shows up in fashion specifically. At Stride Europe 2026 in Venice last month, the team leader of digital creation at one of the major heritage fashion houses stopped by our booth and told us her team's biggest workflow pain wasn't generation. It was approval. They render a canonical 3D keyshot of every shoe and garment, and every downstream AI variant has to stay faithful to that keyshot. The eye picks up a wrong stitch, a swapped material, a recolored sole at a glance. The fix is a comparison loop. Every candidate gets scored against the reference keyshot before delivery, and a failing score triggers a targeted regeneration with a refined prompt. The generator choice matters less than people think; the scoring step is where the real engineering happens.

Who's running this: e-commerce platforms (Photoroom productizes this exact workflow), real estate (virtual staging), and ad creative tools.

Use case 8: character and product consistency across a series

Consistency workflows use reference-conditioning models (IP-Adapter, InstantID, ControlNet) to generate the same character or product across many scenes, poses, and styles without drift.

The business problem: comics, storyboards, game asset packs, brand mascots, episodic content. Anything where the same entity needs to appear in 10+ images consistently. Without conditioning, every generation gives you a new character.

The workflow shape: a reference image (or a small set of reference images) goes in. An encoder (CLIP, DINO, or a model-specific image encoder) embeds the reference. At generation time, the embedding conditions the output through IP-Adapter or a similar reference-conditioning module. Pose and composition are controlled separately via ControlNet (depth, pose, canny). The model generates the new scene while keeping the entity faithful to the reference. A face-match or product-match classifier validates consistency and triggers a retry if the score is too low.

Production gotchas: the tradeoff between adherence and flexibility is fundamental and won't go away. Crank up the IP-Adapter weight and your character is faithful but stuck in one pose. Drop it and you get variation but identity drifts. Tune this per workflow, and budget for the iteration.

The second gotcha is the QC layer for consistency itself. Most fashion AI platforms we've talked to use specialized similarity models (face encoders, garment encoders) for this check, not LLM-based vision judges, because the similarity models return a stable per-frame score you can threshold against. LLM judges drift on prompt wording and aren't reproducible run-to-run. Build the scoring on encoders.

The third gotcha is multi-character scenes: putting two consistent characters in the same image is still genuinely hard, even in 2026. Most teams ship single-subject scenes and composite multiple subjects in post.

Who's running this: storyboard tools (Storybird, ShortBread), comic generators, game studios doing concept art, and any IP holder generating branded content at scale.

Use case 9: upscaling and restoration pipelines

Upscaling workflows take a low-resolution or degraded image and run it through a chain of super-resolution and restoration models to produce a high-resolution clean version.

The business problem: legacy catalogs full of 600px product photos. Old scanned documents and photos. Generated images that came out too small. Anywhere a higher-resolution version is needed and reshooting isn't an option.

The workflow shape: input goes through a denoising pass if the source is grainy. A super-resolution model (Real-ESRGAN, SwinIR, or diffusion-based upscalers like SUPIR) runs the actual upscale, typically 2x or 4x. A face-restoration model (GFPGAN, CodeFormer) runs as a post-process if there are faces in the image. A sharpening pass and a final color correction round out the pipeline. Output is the upscaled image, often with a side-by-side preview for human review.

Production gotchas: hallucination on upscaling is real. Diffusion-based upscalers like SUPIR look incredible on hero shots but invent details that weren't in the original, which is unacceptable for product catalogs and legal documents. Pick the model class based on whether your use case tolerates invented detail.

The second gotcha is batch throughput. Upscaling pipelines look cheap until you try to run 100,000 of them and discover that 4x upscaling at production quality is 5-15 seconds per image even on an A100. The cost math at that scale, using Runflow's published per-second rate of $4.93/hr for an A100 80GB: 10 seconds per image is about $0.014. Fine for a hero product shot. Painful at 100K-per-month volume. Plan the batch architecture (and pick the GPU tier) before you turn this on.

Who's running this: e-commerce platforms cleaning up seller catalogs, photo apps (Topaz, Remini), and AI image platforms offering a "high-res" tier.

Use case 10: synthetic dataset generation for ML training

Synthetic dataset workflows generate large volumes of labeled images for training computer vision models, replacing or augmenting human-labeled real-world data.

The business problem: training a defect-detection model needs thousands of examples of defective parts. You don't have thousands of defective parts because, well, your factory is good at its job. Or training an object detector for a rare object class means weeks of manual data collection and labeling. Synthetic data shortcuts both.

The workflow shape: a parameterized prompt template defines what to generate ("a [defect_type] on a [product_type] under [lighting_condition]"). A generation model produces the image. A bounding-box or segmentation annotation is generated either by the same model (with explicit conditioning) or by a post-hoc detection model. Quality checks filter out implausible outputs. The image and label pair is appended to the dataset. Repeat at scale.

Production gotchas: distribution shift is the killer. A model trained purely on synthetic data often fails on real data because the synthetic distribution is too clean, too consistent, too well-lit. The fix is mixing synthetic and real data (usually 70/30 or 50/50) and using synthetic data for class balancing rather than as a full replacement. The second gotcha is annotation quality: it's tempting to assume the generation prompt is the ground truth, but the model doesn't always render what you asked for, so a verification pass on the annotations matters more than people think.

Who's running this: autonomous driving (Waymo, Wayve), industrial inspection, agritech, medical imaging research, and any vertical AI startup where labeled real-world data is the bottleneck.

What separates a workflow demo from a production pipeline

You can build any of the 10 workflows above in ComfyUI in an afternoon. Demo-to-production is a different distance entirely, and it's where most teams burn 3-6 months they didn't plan for.

Five things break first.

Cold starts. A workflow that takes 8 seconds warm takes 90 seconds cold because the model has to load from disk into VRAM. Users won't wait. The fix is warm worker pools per workflow type. Pool sizing is operationally annoying. Our internal default is a baseline floor of 2 warm workers per GPU tier, scaled up on queue depth. Anything less and the first request after an idle minute eats the cold-start hit.

Queue management. Burst traffic (a viral post, a marketing campaign) piles up requests faster than your GPUs can drain them. Without backpressure and prioritization, free users wait 30 seconds and paying ones wait next to them in the same queue. The non-obvious move is to score worker fitness by how many GB of models the job needs that the worker doesn't already have on disk. A worker that already has the right 14GB Flux checkpoint resident is worth more for that job than a freshly-spun-up worker on the same GPU. We learned that one the hard way after a few weeks of "why is our hot worker idle while a cold one is grinding."

Version pinning. ComfyUI updates weekly. Custom nodes update on their own schedule. A workflow that worked yesterday breaks tomorrow because some dependency changed an output shape. Production teams pin everything (ComfyUI version, custom node commits, model files) and only update on a scheduled cadence with regression testing. The model layer of this is easier if you content-address everything by SHA hash of the file bytes rather than by filename. A "model update" can't silently sneak through a filename collision when the cache key is the hash.

Quality gates. Every workflow above benefits from automated quality scoring before delivery. Without it, you ship the 5% of bad outputs to your users and they email support. Sentinel is what we built for this layer: 8 scored dimensions per output (prompt alignment, artifact detection, composition, sharpness, plus use-case-specific ones like face fidelity, garment accuracy, background consistency, expression), with configurable pass/fail thresholds and an auto-retry on miss. The BetterPic 240-candidates-ship-top-60 model in Use case 2 is what this looks like in production. The 87% gross margin number comes from that loop, not from picking a better model.

Cost observability. GPU bills don't itemize by workflow. You'll find out which workflow is eating 40% of your compute when you're already at $20K/month and trying to figure out where to cut. Per-workflow cost attribution has to be baked in at the orchestration layer, not bolted on six months later.

This is the problem space Runflow Deploy was built for. We run ComfyUI workflows as a production API with pinned versions, warm worker pools per workflow type, Sentinel scoring built into the pipeline, and per-workflow cost tracking on per-second GPU billing (A100 80GB at $4.93/hr, H100 at $5.96/hr, no idle cost). Honest disclosure: it's our product. We built it because BetterPic was running the headshot workflow above (Use case 2) at 100K+ jobs a month and we got tired of every ComfyUI update breaking production. The broader Runflow platform runs 17 production-validated pipelines on the same stack today. If your workflow has graduated from notebook to feature, the ComfyUI API developer's guide, the ComfyUI API endpoints reference, and the ComfyUI cloud provider comparison are the next three reads.

FAQ: AI image workflows

What is an AI image workflow?
An AI image workflow is a chained pipeline of input handling, model execution, post-processing, quality evaluation, and delivery that turns a structured request into a finished image. It's distinct from a single API call to a text-to-image endpoint because workflows usually involve multiple models, conditioning steps, and quality checks chained together.

What are the steps in an AI image generation workflow?
The five canonical steps are: (1) input handling and validation, (2) one or more model passes (text-to-image, image-to-image, inpaint, upscale), (3) post-processing like face restoration or background harmonization, (4) automated quality evaluation, and (5) delivery to storage or webhook. Specific workflows add or rearrange steps based on the use case.

What does an AI image generation workflow diagram look like?
It looks like a directed graph of nodes, similar to a DAG in data engineering or a visual programming language. Each node performs one operation (load model, encode prompt, sample, decode, save). ComfyUI made this graph visible in a drag-and-drop UI, which is why so many production teams use it under the hood even if they hide it from end users.

What's the difference between an AI image workflow and an AI image generator?
A generator is a single model (Flux, Imagen, SDXL). A workflow is a pipeline that may use one generator or many, plus pre- and post-processing. Most production visual features in SaaS products are workflows, not generators, even if they expose themselves to users as a simple "generate" button.

Can you build AI image workflows without ComfyUI?
Yes. Workflows can be built in Python with the diffusers library, in n8n or similar automation tools, or as bespoke services calling hosted APIs. ComfyUI is the most common environment because of its node graph UI and ecosystem of custom nodes, but the workflow concept is tool-agnostic.

What's the best AI image workflow for e-commerce?
The most common production pattern is image-to-image with ControlNet for product preservation, plus a background replacement and lighting harmonization pass. Photoroom and similar platforms productize this. For teams building it themselves, the workflow shape under Use case 1 above is the standard starting point.

How long does it take to build a production AI image workflow?
A working demo takes a day. A production-ready pipeline with quality gates, observability, version pinning, and cost controls takes 3-6 months of engineering for most teams, which is why managed platforms exist. The biggest time sinks are not the model selection but the infrastructure around it.

What's the typical cost of running AI image workflows at scale?
Cost-per-image depends on the workflow complexity, model choice, and GPU type, but a rough benchmark: simple text-to-image runs at $0.001-$0.005 per image on self-hosted infrastructure, while complex multi-model workflows (LoRA + reference + upscale) run $0.02-$0.10 per image. Hosted APIs are usually 5-20x more expensive but require zero infrastructure investment.

Can I use AI image workflows for commercial purposes?
That depends entirely on the models in the workflow. Flux Dev is non-commercial, Flux Schnell and SDXL are commercial-friendly, GPT Image 2 has its own license terms, and any LoRA you train inherits the base model's license. Always check the license of every model in the workflow before shipping.

Where are AI image workflows headed from here?
The clearest trend is the move from notebook demos to embedded product features, which is forcing the infrastructure layer to grow up. Expect more workflow-level APIs (rather than model-level), more attention on quality scoring and per-workflow cost observability, and tighter integration between image and video generation as the line between them blurs.

Where to go next

If you're going to build one of these workflows yourself, here's the order I'd work in:

1. Pick the workflow shape, not the model. Decide which of the 10 use cases above maps closest to what you're building. The workflow shape tells you what infrastructure you need; the model is a swappable variable.
2. Prototype in ComfyUI. Build the graph visually first, even if you'll eventually rewrite it in Python. Seeing the node graph helps you debug what's actually happening.
3. Add the quality gate before you add features. A workflow without automated quality scoring is a workflow that will ship bad outputs. Build the gate early.
4. Pin everything. ComfyUI version, custom node commits, model checkpoints. Version control your workflow JSON. Treat it like code, because it is code.
5. Plan for warm workers. Cold starts are the difference between an 8-second response and a 90-second one. If your workflow is going user-facing, warm pools are mandatory.
6. Read the ComfyUI API developer's guide. When you're ready to move from "running locally" to "running as a service," that's the next read.
7. Look at Runflow when you've outgrown your first deployment. When ComfyUI updates start breaking production and you're spending more time on infra than on workflows, that's the signal.

The workflow is the unit of work. The model is just the part that fits in the middle of it. Build accordingly.