ComfyUI Node

Start Process

StartProcess is your workflow's escape hatch

By sebagallo·Created 9 months ago·Updated 9 months ago· 1
Start Process
  • trigger
  • trigger
  • pid
  • status
process_keymy_process
command
args
cwd
buffer_size1024
trigger_phrase
print_outputfalse
post_start_wait_ms500
trigger_timeout10.00

ComfyUI is a graph, but sometimes the thing you need isn't a node. It's an ffmpeg command, a data-prep script, a downloader, or a little helper server that has to be up before you render anything. StartProcess from the comfyui-sg-process-manager pack is the escape hatch: it launches a real subprocess from inside your workflow and hands you back its PID, so the rest of the graph can know it happened and a later node can shut it down.

This is a genuinely small pack from a single maintainer (v1.1.0, no community buzz to speak of), and StartProcess is its flagship. It's pure standard-library Python - no torch, no models, no downloads - which is rare and nice in a world of heavy custom-node installs. The cost of that simplicity: it does one thing, and you wire the rest yourself.

What it's for

The canonical use is sequencing and orchestration. Say you're building an automation pipeline: a node runs a script that fetches and preps your input files, then a server you need for inference has to be running before the sampler fires. You drop StartProcess in front of it with the command that starts the server, then queue your generation. The process is registered globally under a process_key for the whole ComfyUI session, so any other node - including ones in completely different workflows - can find and kill it later. That global-by-key design is the pack's whole thesis, and StartProcess is where it starts.

How it works

Under the hood it's a subprocess.Popen with stdout and stderr piped into a background reader thread that appends to a small ring buffer. That buffer is what makes the neat features possible: trigger_phrase waits for a line of output before the node reports success, and print_output streams the subprocess's stdout straight to the ComfyUI console. If a trigger phrase is set and never appears, the node force-kills the process after trigger_timeout seconds - the phrase is a gate, not a suggestion.

One thing to internalize: while StartProcess waits (for the phrase, or the post_start_wait_ms sleep, default 500ms), it blocks your whole queue. That's by design - "wait for the server to be up, then continue" - but don't expect it to return instantly.

The inputs and outputs that matter

  • trigger (any type): the passthrough that fires the node. Nothing happens until this input is fed, and whatever comes in is echoed back out. It's your sequencing signal.
  • process_key (default "my_process"): the name your process is stored under. This is what Kill Process and List Processes use, so make it unique and memorable. One process per key - a second Start Process with the same key fails with "Process with this key is already running."
  • command and args: the executable and its arguments. args is multiline and split on whitespace, so watch out: --output "my file.mp4" becomes three args and breaks. No quoting here.
  • cwd: working directory for the process. Leave blank to inherit ComfyUI's.
  • trigger_phrase / trigger_timeout: wait for that text in output before continuing (default 10s timeout).
  • print_output, buffer_size, post_start_wait_ms: console streaming, ring-buffer size (1024 bytes default - old output beyond that gets dropped), and a sleep after start.

Outputs are trigger (passthrough), pid (INT, the process ID, or 0 on failure), and status (STRING - "Process started successfully" or the actual error).

Install

Via ComfyUI Manager (search "comfyui-sg-process-manager"), or the manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/sebagallo/comfyui-sg-process-manager.git

Then restart ComfyUI. No requirements.txt to worry about, no model files to fetch - the package declares zero dependencies.

The honest gotcha

This node's entire job is running commands on your machine with your user's permissions, and custom nodes are arbitrary Python with full OS access on import. That makes this pack exactly as trustworthy as the workflow you load it from. Don't grab a random shared workflow that auto-installs this and fires off arbitrary commands - know what you're running. With that one rule respected, it's a handy little tool.

CategoryProcess Management

Inputs (10)

NameTypeDefaultDescription
trigger*
process_keySTRINGmy_process
commandSTRING
argsoptSTRING
cwdoptSTRING
buffer_sizeoptINT10241–1048576
trigger_phraseoptSTRING
print_outputoptBOOLEANfalse
post_start_wait_msoptINT5000–30000
trigger_timeoutoptFLOAT10.000.1–300

Outputs (3)

NameTypeDescription
trigger*
pidINT
statusSTRING