ComfyUI ships with a full-featured REST and WebSocket API on port 8188 that already supports programmatic workflow submission, progress tracking, and image retrieval -- no wrapper required. To make this accessible externally and securely, the recommended stack is a Cloudflare Tunnel for exposure, a lightweight authentication proxy (Nginx, FastAPI, or n8n webhook), and either ComfyUI's native API directly or one of several mature open-source wrappers that add production features like webhook delivery, S3 uploads, and stateless scaling. Below is a comprehensive breakdown of every option, with specific repos, tools, and architecture recommendations.
ComfyUI's native API is surprisingly complete
ComfyUI's server (built on Python's aiohttp) exposes the exact same API its web GUI uses. Every operation -- queuing a workflow, tracking progress, fetching outputs -- is available over HTTP and WebSocket at http://127.0.0.1:8188.
Core workflow endpoints:
| Endpoint | Method | Purpose |
|---|---|---|
/prompt | POST | Submit a workflow JSON to the execution queue; returns prompt_id |
/history/{prompt_id} | GET | Retrieve execution results and output metadata |
/view | GET | Download a generated image by filename/subfolder/type |
/upload/image | POST | Upload an input image (for img2img workflows) |
/queue | GET/POST | View or manage the execution queue |
/interrupt | POST | Stop the current generation |
/system_stats | GET | GPU info, VRAM usage, Python version |
/object_info | GET | Full catalog of all available nodes |
The WebSocket endpoint at ws://127.0.0.1:8188/ws?clientId={uuid} provides real-time progress updates during generation, including per-step KSampler progress (value/max), node execution status, and binary preview frames. The basic workflow for programmatic use is straightforward: export your workflow in "API format" from ComfyUI's dev mode, POST it to /prompt with {"prompt": , then either listen on the WebSocket or poll /history/{prompt_id} until results appear, and finally fetch images via /view. Custom nodes can even register their own HTTP routes on the server, making ComfyUI's API extensible by design.
The key limitation is that ComfyUI's native API is stateful -- it stores outputs as files on disk, returns file references rather than inline data, and has zero built-in authentication. This is where wrapper projects and security layers become essential.
Open-source wrappers add production-grade features
Several mature projects wrap ComfyUI's API into something more suitable for production deployment. The most notable, ranked by maturity and adoption:
SaladTechnologies/comfyui-api (~377 stars, MIT license) is the most feature-complete wrapper. It's a Node.js/Fastify server distributed as a single binary that launches ComfyUI as a child process. It adds synchronous responses with base64-encoded outputs inline, webhook delivery for async workflows, S3/Azure Blob upload support, Swagger docs at /docs, health/ready probes, image format conversion (PNG/JPEG/WebP), dynamic model loading from URLs with local caching, and configurable warmup workflows. Designed for SaladCloud but works anywhere -- it's genuinely production-ready at github.com/SaladTechnologies/comfyui-api.
ai-dock/comfyui-api-wrapper takes a Python/FastAPI approach with a three-stage pipeline architecture (preprocess → generation → postprocess queues), configurable worker pools per stage, Redis support for multi-instance deployments, and webhook delivery. This is the strongest option if you want a Python-native production wrapper at github.com/ai-dock/comfyui-api-wrapper.
ComfyDeploy (~1.3k stars) at github.com/BennyKok/comfyui-deploy is a full deployment platform -- essentially "Vercel for ComfyUI." It provides versioned workflow deployment, persistent REST API endpoints with production/staging environments, a web dashboard, and integrations with RunPod and Modal for GPU infrastructure. It's self-hostable or available as a managed service at comfydeploy.com.
For lighter-weight Python scripting, comfy_api_simplified (pip install comfy-api-simplified) provides a clean three-line interface -- connect, load workflow, queue and wait for images. ComfyScript (now with an official comfyorg fork) enables Pythonic workflow construction and can connect to a remote ComfyUI server or run in-process. comfy-catapult offers async Python scheduling with Pydantic schemas and ships a companion FastAPI demo server. And two repos named ComfyUI-FastAPI (by alexisrolland and TemryL respectively) offer either a minimal FastAPI boilerplate or an auto-generator that creates FastAPI code directly from workflows in the ComfyUI UI.
n8n works well as a workflow and API layer
n8n does not include a built-in ComfyUI node, but the community has filled this gap comprehensively. The n8n-nodes-comfyui package by mason276752 (143 stars, github.com/mason276752/n8n-nodes-comfyui) is the primary community node, installable via n8n's community nodes panel. It supports executing workflows, automatic image/video retrieval, output format conversion, optional API key authentication, and configurable timeouts up to 30 minutes. Internally, it uses WebSocket connections to monitor progress -- something n8n's built-in HTTP Request node cannot do.
Using n8n as an API gateway for ComfyUI is a practical approach. The architecture uses n8n's Webhook node as the entry point, accepting POST requests with bearer token authentication (configured via n8n's Header Auth credential), then either passes the request to the community ComfyUI node or uses a manual polling loop with HTTP Request nodes. The manual approach follows this flow: Webhook trigger → Code node (build ComfyUI payload with random seed) → HTTP Request POST to /prompt → polling loop (HTTP Request GET /history/{prompt_id} → IF status === "success" → Wait 10s → loop back) → HTTP Request GET /view to retrieve the image → Respond to Webhook with binary image data.
n8n's Webhook node supports four authentication methods for incoming requests: HTTP Header Auth (set Authorization header with Bearer ), Basic Auth, JWT Auth, and None. For the API gateway pattern, Header Auth with a bearer token is the simplest secure option. The n8n community has published templates for this exact pattern, including Template #3970 ("Secure API endpoint with bearer token authentication and field validation") which validates tokens and returns proper HTTP status codes.
Key practical considerations for n8n + ComfyUI: launch ComfyUI with --listen to allow remote connections; when running both in Docker, use Docker networking instead of localhost; generate random seeds in the Code node to avoid identical outputs; set N8N_PAYLOAD_SIZE_MAX appropriately for image data; and ensure EXECUTIONS_TIMEOUT is high enough for generation workflows. For long generations, use the "Respond to Webhook" node early to acknowledge receipt, then continue processing asynchronously.
Cloudflare Tunnel is the clear winner for external access
For exposing a local ComfyUI instance to the internet, Cloudflare Tunnel is the recommended choice by a significant margin. It offers free unlimited bandwidth (critical for image APIs), never exposes your IP address, includes built-in DDoS protection and WAF, and integrates directly with Cloudflare Access for authentication -- all at no cost for personal use.
Setup is minimal: install cloudflared, then run cloudflared tunnel --url http://localhost:8188 for an instant temporary URL, or create a named tunnel mapped to a custom subdomain for persistent access. Because the tunnel uses outbound-only connections, no firewall rules or port forwarding are needed.
ngrok is simpler to set up (single command) but its free tier imposes a 1 GB monthly bandwidth cap and 2-hour session timeouts -- dealbreakers for an image generation API where a few hundred images could exhaust the quota. Paid plans start at ~$8-10/month with only 5 GB bandwidth. Tailscale (with its Funnel feature) excels for sharing within a known team via its WireGuard-based mesh VPN, but is less mature than Cloudflare for public API exposure and lacks built-in WAF/DDoS protection. frp (100k+ GitHub stars) is the best self-hosted alternative if you have a VPS -- it offers full control with no bandwidth limits but requires managing your own relay server.
| Solution | Free bandwidth | Persistent URL | Built-in auth | Best for |
|---|---|---|---|---|
| Cloudflare Tunnel | Unlimited | Yes (with domain) | Cloudflare Access | Production API exposure |
| ngrok | 1 GB/month | No (free tier) | No (free tier) | Quick demos only |
| Tailscale Funnel | Unlimited | Yes (*.ts.net) | ACL-based | Team-internal access |
| frp | Unlimited | Yes (self-hosted) | Configurable | Full self-hosted control |
Security requires an external authentication layer
ComfyUI has zero built-in authentication. Security research by Snyk Labs found over 1,000 exposed ComfyUI instances online, with only ~64 having any login protection. Without auth, anyone reaching the server can submit arbitrary workflows, install custom nodes (which can execute arbitrary code), and access all generated outputs. This makes an external security layer non-negotiable.
The most elegant approach pairs Cloudflare Tunnel with Cloudflare Access. Create a self-hosted application in the Zero Trust dashboard, map it to your tunnel hostname, and configure Service Tokens for machine-to-machine API access. Clients include CF-Access-Client-Id and CF-Access-Client-Secret headers -- no code changes to ComfyUI required. The free tier supports up to 50 users.
For a reverse proxy approach, Nginx can validate API keys using a map directive that checks the X-API-Key header against a whitelist, returning 401 for unauthorized requests and proxying valid ones to ComfyUI. Critical configuration: enable WebSocket support (proxy_http_version 1.1, Upgrade/Connection headers) and increase proxy_read_timeout for long-running generations. Caddy offers the same with simpler config and automatic HTTPS.
A custom FastAPI middleware gives the most control. A minimal implementation validates an X-API-Key or Authorization: Bearer header against a set of valid keys, then proxies requests to ComfyUI on localhost:8188. This approach lets you add rate limiting, request sanitization (validating workflow JSON before forwarding), logging, and custom response formatting in a single lightweight service.
Two ComfyUI custom nodes address authentication directly: ComfyUI-Login (github.com/liusida/ComfyUI-Login) adds password-based login and API token auth via Bearer headers, and comfyui-basic-auth (github.com/fofr/comfyui-basic-auth) adds HTTP Basic Auth middleware via environment variables.
Other workflow tools and the broader ecosystem
Flowise can integrate with ComfyUI via the Model Context Protocol (MCP). A community-built MCP server (github.com/raphiki/ComfyUI-MCP-Server) bridges Flowise to ComfyUI using SSE transport, with workflows self-describing via embedded metadata. Flowise's native MCP support allows dropping an MCP Tool node that auto-discovers available ComfyUI workflows. LangFlow has no native ComfyUI connector but can use the same MCP approach or a custom Python component calling ComfyUI's HTTP API.
For cloud-hosted alternatives that eliminate the need for local GPU infrastructure entirely: RunPod Serverless offers official worker-comfyui Docker images with async queue-based APIs and scale-to-zero pricing. Modal provides infrastructure-as-code deployment with ComfyDeploy integration. Replicate wraps ComfyUI via its Cog packaging tool (github.com/replicate/cog-comfyui). BentoML's comfy-pack adds dedicated input/output nodes and a /generate endpoint with one-click cloud deployment.
Visionatrix (github.com/Visionatrix/Visionatrix) deserves special mention as a production-oriented fork that separates ComfyUI's server and worker components -- enabling a lightweight API server on cheap CPU hardware to distribute work to multiple GPU workers. This split architecture has been tested with a 1-core VPS coordinating three parallel GPU workers.
Recommended architecture for the local ComfyUI + external API use case
The optimal stack for most users combines these layers:
- ComfyUI running on localhost:8188 with
-listen 127.0.0.1(default, never bind to 0.0.0.0) - Authentication proxy -- either a FastAPI wrapper on port 3000 with API key validation, or Nginx with header-based auth, or n8n's webhook node with Header Auth
- Cloudflare Tunnel pointing to the proxy (not directly to ComfyUI), providing HTTPS, DDoS protection, and optionally Cloudflare Access for additional auth
- Async queue pattern -- accept requests immediately (return
prompt_idwith 202 Accepted), process via ComfyUI's internal queue, deliver results via polling endpoint or webhook callback
For the simplest possible setup with n8n, the architecture is: external client → Cloudflare Tunnel → n8n webhook (with bearer token auth) → n8n-nodes-comfyui community node → ComfyUI on localhost:8188. This requires minimal code and gives you a visual workflow editor for the API logic.
For maximum production robustness, use SaladTechnologies/comfyui-api or ai-dock/comfyui-api-wrapper as the API layer -- they handle async execution, webhook delivery, output storage, health probes, and auto-restart out of the box. Place a Cloudflare Tunnel with Access service tokens in front, and you have a secure, scalable image generation API with no custom code required.
Conclusion
The ecosystem for exposing ComfyUI as an API is mature and offers solutions at every complexity level. ComfyUI's native API is already capable enough for direct programmatic use -- the five endpoints (/prompt, /history/{id}, /view, /upload/image, /ws) cover the full generation lifecycle. The critical gap is authentication, which ComfyUI completely lacks. For a quick, low-code path, n8n's community ComfyUI node paired with webhook auth and a Cloudflare Tunnel provides a working external API in under an hour. For production workloads, SaladTechnologies/comfyui-api or ai-dock's FastAPI wrapper adds the stateless execution, webhook delivery, and output storage that production systems need. The key architectural insight is to never expose ComfyUI directly -- always place an authenticated proxy or wrapper in front, tunnel through Cloudflare for free unlimited bandwidth and IP protection, and use async patterns (polling or webhooks) to handle the inherently long-running nature of image generation.
