Skip to main content
July 21, 2026 Want to run ComfyUI on a cloud GPU without touching a terminal? With comfyui-mcp’s first-party RunPod connector (≥ v0.44.0) you rent a GPU pod by the hour and drive it in natural language from the same Agent Panel you already use locally. Ask the agent to deploy a pod, it boots your ComfyUI environment — your custom nodes, your LoRAs, your models — and you render on it. One tap flips back to your local rig when you’re done. This guide covers the full loop: deploy, manage, render, and stop without leaving the panel or your phone.

Why rent a GPU for ComfyUI?

Not everyone has a 24 GB card. Even if you do, some jobs want more: a WAN 2.2 video batch, a big Flux upscale, or a LoRA train that would tie up your desktop for an hour. Renting a cloud GPU on RunPod gives you an RTX 5090 (or bigger) on demand, billed per hour, and hands it back when you stop. The catch has always been reproducing your canvas on the rented box. A generic “managed template” cloud runner only serves official templates — it can’t reproduce the custom node graph you actually work in. comfyui-mcp closes that gap: the pod runs the full comfyui-mcp environment, so the agent installs your custom nodes and LoRAs and downloads your models onto it. You get exact canvas parity on the pod, not a stripped-down stand-in.

Deploy ComfyUI on RunPod in one tap

The runpod tool’s create action deploys the project’s own RunPod template (artokun/comfyui-mcp-runpod) through a referral deploy link — no console clicking, no template hunting. Just ask:
Capacity on cloud GPU hosts is spiky, so the connector doesn’t give up on the first “unavailable.” It falls back across GPU types and, when a community region is dry, from COMMUNITY to SECURE cloud automatically. You get a pod instead of an error. Already have a pod running? Manage any live pod by ID with the connector’s tools — status, start, stop, troubleshoot, and connect — all from the panel. The Deploy action is confirm-armed so you never spin up a billable GPU by accident.

Your exact environment on the pod

This is the part generic cloud runners can’t do. Because the pod runs the same comfyui-mcp stack as your desktop, the agent reproduces your canvas on it:
  • Custom nodes — cloned and installed on the pod.
  • LoRAs — staged where your graph expects them.
  • Models — downloaded onto the pod’s volume.
The result is that the workflow you were editing locally renders the same on the pod. For the full picture of what persists across pod restarts (models, custom nodes, user settings all live on the network volume) and how the topology keeps your Claude/ChatGPT login on your own machine, see Cloud deployment.

Honest host switching — you always know where a render runs

Cloud rendering goes wrong when you think you’re on the pod but you’re actually burning your local GPU, or vice versa. The panel toolbar shows an unambiguous host pill:
  • 🟢 Local · <your rig> — rendering on your own machine.
  • 🔵 RunPod · <pod> · GPU · $/hr — rendering on the rented pod.
That pill is driven by a comfyui_target broadcast pushed on every retarget, so it’s never stale — it reflects where the next render will actually execute. A one-tap Local ⇄ Pod switch (runpod with action: "use_local") moves you between them instantly. Point the pod at your canvas for the heavy job, flip back to local for quick iteration, and the pill tells you the truth the whole time. It’s the same honest-target philosophy behind panel-owned sessions — the canvas target is explicit, never guessed.

Cost control and idle auto-stop

A rented GPU costs real money every hour it runs, so the connector is built to keep you honest about spend. The live status broadcast (runpod_status) surfaces a card with GPU / VRAM / uptime / $·hr so the meter is always visible. The budget backstop is idle auto-stop: after N minutes of inactivity the connector stops the pod for you — but only when you’re actually rendering on it, so it never yanks a pod out from under an active session. Tune the window with RUNPOD_IDLE_STOP_MINUTES. A countdown shows in the status card so there are no surprises.
Renting a GPU bills by the hour — the idle auto-stop is your safety net, not a substitute for stopping pods you’re done with. Note that a stopped SECURE pod can’t always resume (its GPU may get taken by someone else); if resume fails, just redeploy with runpod / action: "create".

Desktop and phone — full parity

Everything above works from a panel control modal on the desktop and a mobile control sheet on your phone — the same feature set on both surfaces:

Desktop panel modal

Host banner, live status card, pod dropdown by name, and Connect / Start / Stop / Use-Local buttons plus a confirm-armed Deploy — right in the ComfyUI sidebar.

Mobile control sheet

The same host banner, status card, pod picker, and one-tap controls in the companion app — kick off a cloud render from your couch, watch the meter, stop the pod when it’s done.
The whole loop was validated end-to-end on both: deploy → connect → render on the pod → Use Local → render on your local rig → reconnect → render on the pod again → stop, with the host pill honest at every step.

How much does RunPod cost for ComfyUI?

You pay by the GPU-hour, only while the pod runs. A 24 GB card (RTX 4090 / A5000 class — plenty for most image work and krea2) runs roughly 0.300.70/hronRunPod;biggerBlackwellcardscostmore.Theconnectorkeepsthatnumberinfrontofyou:thestatuscardshows0.30–0.70/hr** on RunPod; bigger Blackwell cards cost more. The connector keeps that number in front of you: the status card shows **·hr live, and idle auto-stop ends billing when you walk away. A typical session — deploy, render a batch, stop — is cents to a couple of dollars, not a monthly bill.

Which RunPod GPU is best for ComfyUI?

For most workflows a 24 GB card (RTX 4090 or A5000) is the sweet spot — it fits SDXL, Flux, and krea2 comfortably at a low hourly rate. Reach for a 48 GB+ card (A6000, RTX PRO 6000 Blackwell, L40S) only for heavy video (WAN 2.2 batches) or large upscales. You don’t have to pick perfectly: action: "create" falls back across GPU types automatically, so if your first choice is out of capacity you still get a working pod.

How to run ComfyUI on RunPod

  1. Install the comfyui-mcp plugin and open the Agent Panel in ComfyUI.
  2. Set RUNPOD_API_KEY once via the panel’s API-Keys card — no CLI, no WSL fiddling. Secrets are stored server-side in ~/.comfyui-mcp/.env.
  3. (Optional) Set RUNPOD_IDLE_STOP_MINUTES to your comfort window for the idle auto-stop.
  4. Ask the agent to deploy: “Deploy a RunPod pod and connect to it.” Confirm the armed Deploy.
  5. Render. Load your workflow — the agent reproduces your nodes, LoRAs, and models on the pod — and generate. The host pill reads 🔵 RunPod.
  6. Flip back or stop. One tap of Use Local returns to your rig; Stop ends billing when you’re done.
RunPod serves ComfyUI on port 3000 by convention (nginx front, ComfyUI on 3001 inside), and the connector targets 3000 for you — nothing to configure.

The short version

If you’ve ever wanted to run ComfyUI in the cloud without abandoning your custom canvas, this is the path: one-tap deploy of a pod that runs your exact environment, an honest pill that tells you where every render lands, and idle auto-stop so a forgotten pod doesn’t drain your wallet. Set your RUNPOD_API_KEY once, then rent a GPU the same way you talk to your local one. Related reading: Cloud deployment for the pod image and persistence model, Remote / hosted connector for exposing comfyui-mcp itself to remote clients, and ComfyUI on your phone for the mobile companion.