Guides

How to Add Cloud Burst to a ComfyUI Pipeline Without Rewriting Workflows

ยท RenderBob team

The promise of a local+cloud expansion pipeline is simple: baseline load on owned hardware, peaks on rented cloud nodes, and artists who never have to think about which is which.

One unchanged node graph bridges a local GPU rack and elastic cloud compute.

A local+cloud expansion pipeline means baseline load on owned hardware, peaks on rented cloud nodes, and artists who never have to think about which is which. The failure mode is equally simple: two disconnected setups, two ways to submit, and a team that treats "the cloud one" as a separate, scary machine. Add burst capacity so it feels like one farm.

Keep one submission layer

Artists should submit the same way regardless of where a job runs. If bursting means a different app, a different login, or a manual file upload, adoption dies. The submission point stays put; only the destination of the job changes.

Make deployment a configuration, not a rebuild

The same ComfyUI workflow (same nodes, same model versions, same settings) must run on an owned node and a cloud node without edits. That requires the cloud node to mirror the owned environment: identical model registry, pinned versions, matching custom nodes. Environment drift between local and cloud is the number-one cause of "it worked here but not there."

Solve model availability before the first burst

Cloud nodes need the same checkpoints, LoRAs and custom nodes your workflow expects, staged and version-matched. Pre-sync them; do not discover a missing 12GB checkpoint mid-deadline.

Put the routing decision in one place

Define, in writing, what sends a job to cloud: a VRAM ceiling the local node can't meet, a full local queue during a delivery window, or a resolution/length threshold. That is your overflow rule (see post #20). It should be a policy, not an artist's judgement call at 9pm.

Cap the spend

Cloud burst without a ceiling produces a surprise invoice. Set a hard fleet-size cap, per-job node limits, budget alarms with named recipients, and automatic node shutdown on idle and on job completion. The studio should own its cloud account and see the bill directly: no hidden compute margin, no incentive to run inefficiently.

Report on both halves

One monthly view of utilisation and cost-per-frame across owned and cloud nodes keeps the pipeline honest and shows exactly when bursting paid for itself.

The heavy jobs quietly find capacity, the baseline jobs stay home, and nobody re-learns their tools. That is the whole point of adding burst.

More from the blog

  • A Risk Ladder for AI in Documentary

    Screenweaver's 8 October guide ranks five documentary uses of AI by risk, from archive restoration to a synthetic face, and pairs them with EU disclosure rules now in force.

  • The B-Roll Gap: Generated, Selected, or Shot

    Every cut eventually needs a shot that does not exist. AI can generate it or search a library for it, and stock libraries are answering with different rules. Here is how to choose.

All posts