Skip to content
ComfyUI WorldBETA
Sign in
Reference only

Shared ComfyUI server for a studio: decide access control and custom-node policy before exposing it

ComfyUI's cited sources document listen addresses, TLS and Manager security levels but describe no built-in login, so a shared server needs authentication supplied by your own network layer. This guide covers access policy, custom-node risk, storage separation, backups and the Cloud trade-off, with limits stated.

Updated 2026-10-05Published revision: 3Source baseline: not recorded

Purpose and scope

This guide helps a studio decide who can reach a shared ComfyUI server, who may install custom nodes, where data lives and when a managed service fits better. It is not a verified hardened setup.

Source-supported context

The ComfyUI argument parser defaults --listen to 127.0.0.1; passing --listen with no value listens on all IPv4 and IPv6 addresses, and --port defaults to 8188. It also offers TLS flags, a CORS flag (--enable-cors-header, which allows all origins if given without a value), --multi-user (help text: "Enables per-user storage") and directory options. Source 1 The README documents TLS with those two flags, calls its self-signed certificate example "not appropriate for shared/production use". Source 2 Neither cli_args.py nor the README describes a built-in login or user-permission system, so ComfyUI should not be assumed to authenticate anyone; any authentication has to be supplied and verified by your own network layer. No official reverse-proxy or VPN guidance was found in the cited sources.

The registry standards prohibit eval and exec in custom nodes because they can enable arbitrary code execution and remote code execution. Source 3 The Comfy security update of 3 January 2025 announced planned Registry restrictions on eval/exec, runtime pip installs and code obfuscation, with timelines, and AI and static-analysis scanning of nodes; current enforcement was not checked. Source 4 ComfyUI-Manager's README defines security_level strong, normal, normal- and weak; normal- disallows its "high" risk features when --listen is set to an address not starting with 127. In that README, installs via Git URL, pip install and unregistered custom nodes are no longer governed by security_level but by separate install flags, and some checks apply only to loopback listeners. Source 5

Comfy's support pages say Cloud runs on Comfy-managed infrastructure, not every local custom node is available, and users cannot currently install custom nodes there; Creator and Pro plans can import models. Source 6 Source 7 The Cloud guide lists pre-installed nodes and models and team workspaces. Source 8

Before you start

1. Name the owner, administrators and users.

2. List the networks involved.

3. Record ComfyUI and Manager versions.

Steps and checks

The sequence below is an editorial procedure based on the cited context, not a diagnosis already confirmed for your environment.

Step 1. List who only submits workflows, who edits them and who may install custom nodes; treat the last group as server administrators because node code runs as Python on the host.

Step 2. Choose the listen address deliberately: the parser default is 127.0.0.1 and a bare --listen means all addresses. Prefer loopback or a private interface; if you place a VPN or reverse proxy in front, that setup is your own responsibility (the cited sources give no guidance and none is endorsed), so record which component authenticates users and test it yourself.

Step 3. Choose the TLS arrangement (--tls-keyfile and --tls-certfile, or proxy) and give --enable-cors-header a named origin rather than leaving it without a value, which allows all origins.

Step 4. Set a custom-node policy first: record Manager's security_level, its install flags (see its README) and the --listen value, and keep installs administrator-only.

Step 5. Separate storage by purpose: shared models, project inputs and outputs, and user or workflow data, using the directory options and extra_model_paths.yaml.

Step 6. Define backup scope (workflows, retained outputs, config files, environment record), separate unique data from redownloadable weights and rehearse a restore.

Step 7. Write the Cloud decision as constraints (managed infrastructure, no user-installed nodes, model import by plan) and check current terms.

Completion check

You can state in writing who authenticates users, the listen and TLS setup, who installs nodes, where data lives, what the backup covers and why Cloud was or was not chosen.

Limitations and cautions

No official reverse-proxy, VPN or authentication guidance was found in the cited sources, so none is endorsed. Manager behaviour and Registry enforcement may change. Nothing shows --multi-user isolates users. Cloud plans are volatile.

Original sources

Prepared 2026-10-06 from the sources above. No GPU run, quality measurement or runtime guarantee is supplied.

Was this page helpful?

Anonymous. Only a yes/no counter is stored; no account, IP address or device details.

Sources & references

Editorial research from the cited public sources, dated 2026-10-06. This site did not run or test the workflow described.

01ComfyUI command-line arguments (cli_args.py)Source checked: 2026-10-0602ComfyUI READMESource checked: 2026-10-0603ComfyUI Registry security standardsSource checked: 2026-10-0604ComfyUI 2025 Jan security updateSource checked: 2026-10-0605ComfyUI-Manager READMESource checked: 2026-10-0606Comfy Cloud vs ComfyUI LocalSource checked: 2026-10-0607Custom nodes on Comfy CloudSource checked: 2026-10-0608Comfy Cloud overviewSource checked: 2026-10-06

Report an issue · 2521cdfc-9ffd-5c8f-86b2-b6b1f491227c

Keep exploring

Related reading

Pages linked to this one by the editors.