Install ComfyUI-Manager and custom nodes on a remote GPU

The safe way to run ComfyUI-Manager on a remote GPU is to install it as the pip package ComfyUI now expects, start ComfyUI with --enable-manager, and keep ComfyUI on 127.0.0.1 behind an SSH tunnel. The Manager gives its full feature set only to servers that listen on the local machine, so the tunnel is what makes it useful as well as safe. Install custom nodes from the Comfy Registry at pinned versions, and keep that list in a file: stopping a QuantaCloud instance deletes its disk, and every node on it.

Check whether the Manager is already there#

The quickest check is the Manager button in ComfyUI's top bar. Where it comes from depends on how ComfyUI was installed:

On your own install, the startup log also names the Manager's config.ini when the Manager loads. If the button is missing, the package is not installed or ComfyUI started without --enable-manager.

Install ComfyUI-Manager#

The Manager is a pip package now, not a folder you clone into custom_nodes. ComfyUI v0.37.0 pins version 4.2.2 in its manager_requirements.txt, and the Manager's own README warns against cloning the current version into custom_nodes. With comfy-cli there is nothing to do. On a manual install, run this in ComfyUI's folder with its virtual environment active:

cd ~/ComfyUI && source .venv/bin/activate
pip install -r manager_requirements.txt
python main.py --enable-manager

--enable-manager-legacy-ui brings back the older Manager dialog, and --disable-manager-ui hides the dialog while keeping the Manager's background work. Running ComfyUI on a cloud GPU covers both install routes on the Bare Metal template.

Security levels, and why the tunnel matters#

The Manager sorts every action by risk and checks two things before it runs one: its security_level, which defaults to normal, and whether ComfyUI listens on an address outside 127.x. At the default level, this is what it allows:

The one thing I always check on a remote server is where ComfyUI listens. ComfyUI has no authentication, so a server on a public address lets anyone install nodes, and the Manager treats it accordingly. Keep ComfyUI on its default 127.0.0.1, reach it with ssh -N -L 8188:127.0.0.1:8188 ubuntu@<instance-ip>, and the Manager treats you as local. Connecting to a cloud GPU covers the tunnel and SSH config.

The settings live in ComfyUI/user/__manager/config.ini, under [default], and a change takes effect when ComfyUI restarts:

[default]
security_level = normal
network_mode = public
allow_git_url_install = False
allow_pip_install = False

My rule: leave security_level at normal, and switch allow_git_url_install on only when a node you have read is not in the registry. Inside a Docker container ComfyUI has to listen on 0.0.0.0, so the Manager sees a non-local server even when Docker publishes the port on 127.0.0.1 only. There, network_mode = personal_cloud restores the middle+ actions, and it is reasonable only because, with Docker 28.0.0 or newer, nothing outside the VM can reach a port published on 127.0.0.1. ComfyUI in Docker shows that setup.

Install custom nodes without regret#

A custom node is Python code that runs with ComfyUI's permissions: it can read your files, your tokens and your outputs. Comfy Org's own security update from January 2025 names two cases where that went wrong, the ComfyUI_LLMVISION node and the ultralytics package. The Comfy Registry is the safer source: it scans nodes for malicious behaviour, it can ban a node quickly, and a published version can never be changed. The rule I follow is to install registry releases from publishers I can identify, read the code and the requirements.txt of anything else, and pin every version.

There are three ways in, and each can pin a version:

The comfy-cli route takes the node's Comfy Registry ID, shown on its page at registry.comfy.org, which can differ from the GitHub repository name, and passes it to the Manager's own command-line tool. Restart ComfyUI after a command-line install, with comfy stop and comfy launch --background, because nodes load only at startup.

A manual install is the one that can hurt your PyTorch. The example adds the Ollama nodes from ComfyUI with Ollama. A node's requirements.txt can ask for a different torch version, and pip will replace the build you installed from the cu130 index. Pin the installed versions as a constraint first, so pip refuses instead of swapping them:

cd ~/ComfyUI && source .venv/bin/activate
git clone https://github.com/stavsap/comfyui-ollama.git custom_nodes/comfyui-ollama
git -C custom_nodes/comfyui-ollama checkout 6db7560576e5a59488708e6be13e07b5aba2432a
pip freeze | grep -E '^(torch|torchvision|torchaudio)==' > /tmp/torch-pins.txt
pip install -r custom_nodes/comfyui-ollama/requirements.txt -c /tmp/torch-pins.txt

The Manager has the same guard built in: list requirements in user/__manager/pip_auto_fix.list, in the same format as requirements.txt, and it restores those versions at startup or when a node install changes them.

Reinstall your nodes on every launch#

The honest answer is that your node set is code, and it needs the same treatment as your models: a file in Git and one command on each launch. Stopping a QuantaCloud instance terminates it and deletes its disk, custom nodes included, and there are no volumes or snapshots to bring them back. comfy-cli gives you three ways to rebuild the set.

A snapshot is the most complete. It records the ComfyUI commit, every node's registry version or git commit, and the pip packages. Save one before you stop:

comfy node save-snapshot --output ~/comfy-nodes.json

Then fetch it from your own machine with scp ubuntu@<instance-ip>:comfy-nodes.json ., as moving files to and from a GPU server shows.

On the next instance, after comfy install, copy the file back and restore it:

comfy node restore-snapshot ~/comfy-nodes.json

Restoring puts the nodes back at the recorded versions and disables registry nodes that are not in the file. It does not change the ComfyUI version, so install the same release first.

A node list is the easiest to read and review. Keep one registry ID and version per line in nodes.txt:

comfyui-ollama@2.1.0
comfyui-custom-scripts@1.2.5

comfy node install --exit-on-fail $(grep -v '^#' nodes.txt)

A workflow file works as its own list. Every node in a saved workflow records its registry ID under cnr_id and its version or commit under ver, and comfy-cli installs what a workflow needs:

comfy node install-deps --workflow=my_workflow.json

On a manual install, the Manager's cm-cli does the same jobs from ComfyUI's virtual environment, with COMFYUI_PATH pointing at the ComfyUI folder: COMFYUI_PATH=~/ComfyUI cm-cli save-snapshot --output ~/comfy-nodes.json, and restore-snapshot on the next instance.

On the ComfyUI template

The ComfyUI template runs ComfyUI inside a Docker container, so installs happen in that container and disappear with it. If the template has the Manager, install registry releases from the Manager dialog: they are middle-risk actions, which the Manager allows even when ComfyUI listens beyond localhost.

For a node set you rebuild often, or one that needs updates and git installs, I would run my own ComfyUI on the Bare Metal template, where the snapshot routine above works end to end.

When a node breaks#

The startup log says which node failed, so read it first. ComfyUI prints Cannot import ... module for custom nodes: with the Python error, and in the list under Import times for custom nodes: it marks the broken one (IMPORT FAILED). A missing module in that error means the node's requirements did not install: install them with the torch constraint above, then restart.

A workflow opens with missing nodes. Use the Manager's Install Missing Custom Nodes, or comfy node install-deps --workflow= with the workflow file.

The log refuses an action and asks for a security_level of normal or below and a network_mode of personal_cloud. You asked for a middle+ action while ComfyUI listens on a non-local address. Move ComfyUI back to 127.0.0.1 and use the tunnel, or, inside a container that nothing outside the VM can reach, set network_mode = personal_cloud.

ComfyUI stopped starting after an update. Start it with --disable-all-custom-nodes to confirm a node is the cause, then let comfy node bisect start narrow it down. --whitelist-custom-nodes loads the folders you name even while the others stay off.

PyTorch changed after a node install: pip show torch reports a version you did not install, or ComfyUI no longer finds the GPU. A requirements file replaced your build. Reinstall it from the cu130 index with pip install --upgrade torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130, which pip would otherwise skip as already satisfied, and use the constraint next time.

Frequently asked questions#

Does ComfyUI include ComfyUI-Manager?

Not in a manual install. ComfyUI's README installs it separately with pip install -r manager_requirements.txt and turns it on with --enable-manager. comfy-cli and Comfy Desktop set it up for you.

Where is the ComfyUI-Manager config.ini?

In ComfyUI/user/__manager/config.ini, or under __manager in the directory you pass to --user-directory. The startup log prints the exact path.

Should I set security_level to weak on my server?

No. Keep normal and reach ComfyUI through the tunnel, which gives you every everyday action without opening installs to anyone who finds the port.

Do custom nodes survive stopping the instance?

No. Stop deletes the instance and its disk. Keep a snapshot, a node list or the workflow files, and rebuild with one command on the next launch.

My rule for ComfyUI-Manager on a remote GPU: install it with pip, keep ComfyUI on 127.0.0.1 behind the tunnel, install registry releases at pinned versions, and save a snapshot before every stop. Models need the same routine, and loading models on a new instance has the script for them. The ComfyUI page launches the template, and the Bare Metal template is the one to use when your node set has to be exact.