Deadline Worker Registration

This is the node that bridges the two halves of the pack: Deadline the render manager on one side, your distributed ComfyUI farm on the other. When Thinkbox Deadline launches a task, the worker process that spins up needs to tell the ComfyUI master "I exist, I'm this machine, here's where to reach me" - and that's the entire job of this node. The README puts it plainly: for Deadline worker bootstrap workflows, this plugin provides DeadlineWorkerRegistration; the Deadline worker job uses it to register the worker process with the master automatically.

What it looks like. No required inputs. There's one optional trigger input of any type, with the author's tooltip "Connect any input to trigger registration" - wire anything into it to make sure the node actually runs in the pruned worker workflow. One status STRING output, and it's an output node, so you'll see the result text in the UI. Its description is exactly what it does: "Registers Deadline worker with ComfyUI-Distributed master."

How it works. When the node runs inside a Deadline task, it reads the environment Deadline already set: DEADLINE_JOB_ID, DEADLINE_TASK_ID, DEADLINE_SLAVE_NAME, plus the master address and - critically - COMFY_DISTRIBUTED_REGISTRATION_TOKEN. It builds a worker ID in the shape deadline-{hostname}-{job_short}-{task_id}-p{port}, figures out which IP can reach the master, and POSTs a registration to the master's /deadline/register_worker endpoint with the token. On success it starts a background heartbeat thread that pings the master every 30 seconds so the worker stays marked alive. Each Deadline worker process registers independently - that's how multi-GPU machines with several workers per host each get their own slot. If the plugin isn't in Deadline distributed mode, registration is skipped and it just reports that.

Where it goes in your setup. Not in your normal generation workflow. It belongs in the Deadline bootstrap workflow - the job-level graph Deadline runs to spin a worker up - so the worker announces itself before it picks up real work. The token it needs is injected into the submitted Deadline job metadata (COMFY_DISTRIBUTED_REGISTRATION_TOKEN), which is also the first thing to check when registration fails. The README's troubleshooting line is the one you'll actually use: if a Deadline worker can't register, check that the worker can reach the master host, and check that the submitted Deadline job actually contains the registration token.

This is a genuinely niche node - it only makes sense if you're running Thinkbox/AWS Deadline 10 with deadlinecommand on the master and a studio-style farm behind it. If you're just running a couple of hand-configured workers from the Distributed panel, you never touch it. But if you're the person wiring ComfyUI into a real render farm, it's the piece that makes Deadline-launched workers count as first-class citizens instead of manual afterthoughts.