Why self-host ComfyUI on a VPS
ComfyUI organizes image generation into node graphs: each step (model loading, prompt encoding, sampling, VAE) is a linkable, reusable block, which makes workflows reproducible and shareable in JSON format. Unlike an online generation service, self-hosting gives you control over the checkpoint models, the LoRAs, the ControlNets and the extensions, without censorship or quota. On a GPU VPS, you get a studio available 24/7 that an entire creative team can use remotely, and whose API lets you industrialize generation from your own scripts or pipelines.
Concrete benefits of self-hosting
- Reproducible node-based workflows, exportable as JSON and shareable within the team
- Free library of checkpoints, LoRAs and ControlNets with no quota or censorship
- HTTP API to automate generation from your scripts and pipelines
- Remote GPU accessible 24/7 without tying up a local workstation
- Installation of custom nodes (community extensions) without restriction
- Cost control: a GPU VPS by the hour or the month rather than paying per image
Hardware and software prerequisites
ComfyUI leverages a GPU for reasonable generation times. Aim for a VPS with an NVIDIA GPU with at least 8 GB of VRAM for SDXL (12 to 16 GB recommended for recent models like Flux), accompanied by 4 vCPUs, 16 GB of system RAM and 50 GB of disk or more, since checkpoints each weigh several gigabytes. CPU execution remains possible but very slow, to be reserved for testing. On the software side: NVIDIA drivers and the NVIDIA Container Toolkit for Docker, Docker and Docker Compose, and a domain pointing to the VPS to expose the interface.
ComfyUI versus AUTOMATIC1111 (Stable Diffusion WebUI)
| Criterion | ComfyUI | AUTOMATIC1111 |
|---|---|---|
| Approach | Visual node-based workflows | Classic tabbed interface |
| Reproducibility | Excellent (workflow exported as JSON) | Limited to the entered parameters |
| VRAM consumption | Optimized, handles small GPUs better | More demanding at equal configuration |
| Learning curve | Steeper (graph logic) | More approachable for beginners |
| API automation | Native and granular | API present but less flexible |
| Recent models (Flux, SD3) | Fast, reference-grade support | Often later support |
| Custom nodes / extensions | Very rich node ecosystem | Large extension catalog |
| Ideal use case | Advanced pipelines and automation | Fast interactive generation |
Deploying ComfyUI with a GPU
Prepare the GPU VPS
On a VPS with an NVIDIA GPU, install the drivers then the NVIDIA Container Toolkit so that Docker can access the GPU. Validate with docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi.
Run ComfyUI in a container
Start a ComfyUI image with GPU access and persistent volumes: docker run -d --gpus all -p 127.0.0.1:8188:8188 -v /opt/comfyui/models:/app/models -v /opt/comfyui/output:/app/output --name comfyui <image-comfyui>. Restricting to 127.0.0.1 avoids direct exposure.
Install the models
Drop your checkpoints into /opt/comfyui/models/checkpoints and your LoRAs into the corresponding folder. On the next interface refresh, ComfyUI automatically detects the new models.
Load a first workflow
Open the interface, load the default text-to-image workflow, select a checkpoint and launch a test generation to confirm that the GPU is indeed used (check with nvidia-smi).
Reverse proxy, SSL and authentication
ComfyUI has no native authentication. You absolutely must place Caddy or Nginx in front of port 8188 with Let's Encrypt HTTPS and basic auth, otherwise your GPU is open to everyone. Increase the proxy timeouts since generations can be long.
Lock down and expose
Close port 8188 at the firewall, then publish https://comfy.yourdomain.com. For automation, use the /prompt API to submit JSON workflows from your scripts.
To industrialize generation, leverage the API: submit your workflows via POST to /prompt and retrieve the results through the /ws WebSocket that notifies the end of each task. Combine this with the --lowvram flag at launch if your VPS has an 8 GB GPU: ComfyUI intelligently offloads the models to system RAM to avoid CUDA memory errors on large models.
