Back to tutorials
Tutorial

Run ComfyUI on a GPU VPS With Nginx and TLS

Run ComfyUI on a GPU VPS with Nginx and TLS: install, secure HTTPS, add systemd, and run private image generation safely.

By Anurag Singh
Updated on Oct 23, 2026
Category: Tutorial
Share article
Run ComfyUI on a GPU VPS With Nginx and TLS

ComfyUI is easier to manage when it isn’t exposed on an open port.

For private image generation, a team pipeline, or internal tools, you can run ComfyUI on a GPU VPS, put it behind Nginx, and secure it with TLS plus basic access controls.

This guide shows a production-style install on Ubuntu. You’ll use a non-root service user, a predictable install path, a systemd unit, and an Nginx reverse proxy with Let’s Encrypt.

The end result is ComfyUI at https://comfy.yourdomain.com, not a random high port.

What you’ll build (and what it’s not)

  • Build: ComfyUI running as a systemd service on a GPU server, reachable only through Nginx over HTTPS.
  • Includes: UFW rules, a dedicated Linux user, and optional HTTP Basic Auth (simple, effective).
  • Not included: Multi-user permissions inside ComfyUI, complex auth (OIDC), or Kubernetes. Keep it simple and operable.

Infrastructure and resource requirements

Yes, ComfyUI can run on CPU. In practice, it’s a slow way to spend money and time.

For anything beyond quick tests, use a GPU VPS or a dedicated server with an NVIDIA GPU.

  • OS: Ubuntu Server (LTS preferred)
  • CPU: 4+ vCPU (8 vCPU helps when you do multiple concurrent runs or heavy preprocessing)
  • RAM: 16 GB minimum; 32 GB is a safer baseline
  • Disk: 80–150 GB SSD/NVMe (models and outputs add up fast)
  • GPU VRAM: 12 GB works for many workflows; 16–24 GB gives you more headroom for larger models, higher resolution, and extra nodes

Quantization and “low VRAM” modes can help. You still need enough VRAM to avoid constant OOM errors.

If this supports a business workflow, plan capacity up front.

You don’t want to debug memory pressure every day.

Need a place to run it? Start with a HostMyCode VPS (GPU-capable where available), or move up to HostMyCode dedicated servers when you want steadier performance and higher GPU options.

Prerequisites (DNS, firewall, and a clean user)

Handle these first. They prevent most “works on localhost, breaks everywhere else” issues.

  1. DNS: Create an A/AAAA record (example: comfy.yourdomain.com) pointing to your server IP.
  2. Firewall: Only allow SSH and web ports. Don’t expose ComfyUI’s port directly.
  3. Service user: Run ComfyUI as a dedicated unprivileged user.

1) Update the server

sudo apt update
sudo apt -y upgrade
sudo reboot

2) Create a dedicated user

sudo adduser --disabled-password --gecos "" comfy
sudo usermod -aG sudo comfy

If you don’t want this user to have sudo, skip the second line.

Use your admin account for privileged steps instead.

3) UFW firewall rules

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

ComfyUI will bind to 127.0.0.1.

There’s no reason to open its port to the internet.

If you want a broader security baseline for your web stack, keep this nearby: Set up UFW on Ubuntu for a web server.

Install NVIDIA drivers (and confirm the GPU is usable)

GPU images vary by provider. Some come with drivers.

Many don’t.

Check what you have first, then install what you need.

1) Check if the system sees the GPU

lspci | grep -i nvidia || true

2) Install drivers (Ubuntu packages)

On Ubuntu, drivers from the Ubuntu repositories are usually the least painful option.

Use the version Ubuntu recommends for your hardware.

sudo ubuntu-drivers devices

Then install the recommended driver (example package name shown; yours may differ):

sudo apt -y install nvidia-driver-535
sudo reboot

3) Verify with nvidia-smi

nvidia-smi

You should see your GPU model and driver details.

If nvidia-smi fails, fix that before you touch ComfyUI.

Everything upstream depends on this working.

Install ComfyUI (Python venv + pinned folder layout)

This install keeps everything in /opt/comfyui and runs in a Python virtual environment.

It’s tidy, predictable, and easier to maintain.

1) Install dependencies

sudo apt -y install git python3 python3-venv python3-pip nginx

2) Clone ComfyUI

sudo mkdir -p /opt/comfyui
sudo chown -R comfy:comfy /opt/comfyui
sudo -u comfy bash -lc "cd /opt/comfyui && git clone https://github.com/comfyanonymous/ComfyUI.git ."

3) Create a virtual environment and install Python requirements

sudo -u comfy bash -lc "cd /opt/comfyui && python3 -m venv .venv"
sudo -u comfy bash -lc "cd /opt/comfyui && . .venv/bin/activate && pip install --upgrade pip wheel"
sudo -u comfy bash -lc "cd /opt/comfyui && . .venv/bin/activate && pip install -r requirements.txt"

4) Install a GPU-enabled PyTorch build (critical)

ComfyUI relies on PyTorch. On a GPU server, you want a CUDA-enabled build, not CPU-only.

The exact install command depends on your driver/CUDA compatibility.

Use PyTorch’s official selector to get the correct pip line.

After installing PyTorch, confirm CUDA works inside your venv:

sudo -u comfy bash -lc "cd /opt/comfyui && . .venv/bin/activate && python -c 'import torch; print(torch.__version__); print(torch.cuda.is_available())'"

If it prints False, stop and fix PyTorch before moving on.

ComfyUI may start, but generation will be unusably slow (or fail outright).

Run ComfyUI on localhost only (test before systemd)

Do a manual start once.

It’s the fastest way to catch missing dependencies and obvious config mistakes.

sudo -u comfy bash -lc "cd /opt/comfyui && . .venv/bin/activate && python main.py --listen 127.0.0.1 --port 8188"

From the server, hit the local endpoint:

curl -I http://127.0.0.1:8188/

You should get an HTTP response.

Keep it running if you want to test Nginx right away, or stop it with Ctrl+C.

Create a systemd service for ComfyUI

systemd makes this operable.

You get automatic restarts, clean logging, and reliable startup on reboot.

1) Create the unit file

sudo nano /etc/systemd/system/comfyui.service

Paste this (adjust paths/port if needed):

[Unit]
Description=ComfyUI service
After=network.target

[Service]
Type=simple
User=comfy
Group=comfy
WorkingDirectory=/opt/comfyui
Environment=PATH=/opt/comfyui/.venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ExecStart=/opt/comfyui/.venv/bin/python /opt/comfyui/main.py --listen 127.0.0.1 --port 8188
Restart=on-failure
RestartSec=3

# Basic hardening
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

2) Enable and start

sudo systemctl daemon-reload
sudo systemctl enable --now comfyui
sudo systemctl status comfyui --no-pager

3) Follow logs

sudo journalctl -u comfyui -f

If ComfyUI crashes, start with the traceback here.

Most issues come from missing Python packages, the wrong PyTorch build, or not enough VRAM for the model you’re loading.

Put ComfyUI behind Nginx (reverse proxy)

Nginx handles the public edge: HTTPS, HTTP/2, and simple access controls.

ComfyUI stays on localhost where it belongs.

1) Create an Nginx site config

sudo nano /etc/nginx/sites-available/comfyui

Config (replace domain):

server {
    listen 80;
    server_name comfy.yourdomain.com;

    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:8188;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Websocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

2) Enable the site and test Nginx

sudo ln -s /etc/nginx/sites-available/comfyui /etc/nginx/sites-enabled/comfyui
sudo nginx -t
sudo systemctl reload nginx

You should now be able to reach http://comfy.yourdomain.com (still without TLS).

If it doesn’t load, check these basics:

  • DNS is pointing to the correct IP
  • UFW allows port 80
  • ComfyUI is running on 127.0.0.1:8188: ss -lntp | grep 8188

Add TLS with Let’s Encrypt (Certbot) and force HTTPS

This is the standard Nginx + Let’s Encrypt flow.

For deeper troubleshooting (DNS mistakes, ACME challenges, renewal failures, mixed content), keep this guide handy: TLS setup guide tutorial (2026).

1) Install Certbot for Nginx

sudo apt -y install certbot python3-certbot-nginx

2) Issue the certificate

sudo certbot --nginx -d comfy.yourdomain.com

3) Confirm auto-renewal

sudo certbot renew --dry-run

Certbot will typically update your Nginx config to redirect HTTP to HTTPS.

Confirm by visiting https://comfy.yourdomain.com.

Lock it down: Basic Auth + sensible Nginx limits

ComfyUI can burn GPU time fast.

Don’t leave it open unless you’re prepared to handle abuse.

For many private deployments, HTTP Basic Auth is a good baseline.

It blocks drive-by scans and accidental exposure.

1) Create a password file

sudo apt -y install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd comfyadmin

2) Add Basic Auth to the TLS server block

After Certbot runs, your config should include a server block on 443.

Edit the active file (often still /etc/nginx/sites-available/comfyui) and add inside location /:

auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;

Reload Nginx:

sudo nginx -t
sudo systemctl reload nginx

3) Optional: add light rate limiting

Rate limiting won’t stop someone who already has valid credentials.

It does cut down brute-force noise and scanner traffic.

In /etc/nginx/nginx.conf inside the http block:

limit_req_zone $binary_remote_addr zone=comfy_limit:10m rate=10r/s;

Then in your location /:

limit_req zone=comfy_limit burst=20 nodelay;

If you want a careful, production-safe approach (and common pitfalls), see: Nginx rate limiting tutorial (2026).

Model storage and disk hygiene (don’t fill your VPS)

ComfyUI workflows pull big files: checkpoints, VAEs, LoRAs, and outputs.

If you ignore storage, you’ll eventually hit a full disk mid-run.

  • Keep models on fast storage: NVMe makes a visible difference in load times.
  • Separate outputs from system files: consider a dedicated mount at /srv/comfy-outputs if you generate a lot.
  • Watch disk usage weekly: cached files, old outputs, and duplicate models accumulate quietly.

Quick diagnostics:

df -h
sudo du -sh /opt/comfyui/* 2>/dev/null | sort -h
sudo du -sh /opt/comfyui/models/* 2>/dev/null | sort -h

If you’re already close to full, use this runbook-style guide: Disk space troubleshooting tutorial (2026).

Operational checks: performance, VRAM, and stability

After it’s online, confirm two things.

First, ComfyUI is actually using the GPU. Second, VRAM isn’t your bottleneck.

1) Watch GPU utilization during a generation

watch -n 1 nvidia-smi

If utilization stays near 0% while you generate, ComfyUI is probably running on CPU.

Re-check PyTorch CUDA availability inside the venv.

2) Know what “VRAM pressure” looks like

  • Generation fails with out-of-memory errors.
  • It runs, but slows dramatically on larger resolutions.
  • Concurrent sessions make failures repeatable.

Fixes are usually straightforward, not magical.

Lower resolution, reduce batch size, use smaller models, or choose a GPU VPS with more VRAM.

Backups: what you should (and shouldn’t) back up

Backups get expensive fast if you blindly include model weights.

Decide what’s worth keeping.

  • Back up: ComfyUI custom workflows, prompts/templates, custom nodes config, and anything you can’t recreate quickly.
  • Optional: outputs, if they are business assets.
  • Usually skip: re-downloadable base models, unless you have strict offline requirements.

Common problems and quick fixes

  • 502 Bad Gateway from Nginx: ComfyUI isn’t running or is listening on the wrong address. Check systemctl status comfyui and ss -lntp | grep 8188.
  • TLS issues / Certbot fails: DNS isn’t correct or port 80 is blocked. Confirm the A record and that UFW allows 80.
  • ComfyUI loads but generation is very slow: You’re on CPU. Verify torch.cuda.is_available() inside the venv.
  • “No space left on device”: model downloads and outputs filled the disk. Audit /opt/comfyui/models and outputs.

Summary: a safe way to run private image generation

You now have ComfyUI running as a managed service instead of a terminal session.

Nginx handles inbound traffic, TLS terminates cleanly, and ComfyUI stays bound to localhost.

If you’re wiring this into a website workflow, keep the host patched.

Keep an eye on disk usage, and treat model storage like production data.

If you’d rather offload routine patching and baseline security work, a managed VPS hosting plan can help.

If you want private image generation without sharing prompts or outputs with third parties, run ComfyUI on your own server. Start with a GPU-ready HostMyCode VPS, and use HostMyCode migrations if you’re moving workloads or domains and want a clean cutover.

FAQ

Should I expose ComfyUI directly on port 8188?

No. Bind ComfyUI to 127.0.0.1 and expose it through Nginx on 443.

You get TLS, cleaner access controls, and fewer accidental exposures.

Is HTTP Basic Auth enough to secure ComfyUI?

It’s a solid baseline for private/internal use, especially combined with HTTPS and rate limiting.

If you need per-user access, audit logs, or SSO, you’ll want stronger authentication in front of it.

How do I monitor uptime for ComfyUI?

Use systemd health (restarts, status) plus an external uptime check against your HTTPS endpoint.

If you want a simple self-hosted monitor, see Self-host Uptime Kuma on a VPS with Nginx HTTPS.

Can I run RAG or a vector database on the same server?

You can, but be careful with RAM and disk I/O.

If you’re adding a vector store like Qdrant, isolate resources and monitor memory pressure. This tutorial may help: Run Qdrant on a VPS with Docker and Nginx TLS.

What’s the quickest way to confirm I’m using the GPU?

Run watch -n 1 nvidia-smi during a generation and confirm utilization changes.

Also verify in Python that torch.cuda.is_available() returns True.

Run ComfyUI on a GPU VPS With Nginx and TLS | HostMyCode