Nodes/ComfyUI-reboot/Reboot ComfyUI
ComfyUI Node

Reboot ComfyUI

The node that turns ComfyUI off and on again for you

By bobosola·Created 11 months ago·Updated 11 months ago· 1
Reboot ComfyUI
  • any
    server_urlhttp://127.0.0.1:8188
    wait_seconds5

    Reboot ComfyUI is exactly what the name says: a node you drop at the end of a workflow that restarts the whole ComfyUI server a few seconds later. It's the digital equivalent of "have you tried turning it off and on again?" - except it's a node, and it does the turning for you.

    This is a solution of last resort, and its author will happily tell you that. bobosola built it after fighting a memory leak on a Mac mini M4: his MLX Flux loaders (from the Mflux-ComfyUI pack) were blisteringly fast but refused to free ~36GB of unified memory when a workflow finished. He tried everything - Manager's Unload models, Free model & node cache, the EasyUse Clean VRAM node, Unload Model, Unload All Models - and none of it reclaimed the memory. Only a restart did. Since he drives ComfyUI as a headless image backend for Open WebUI, he wanted the restart to happen automatically after every generation. Hence this pack.

    How it works

    It's a tiny piece of Python riding on two assumptions: that your leak is genuinely unfixable from inside the process, and that a fresh server process will reclaim the memory. The node is an output node (OUTPUT_NODE = True), meaning it sits at the end of the graph and doesn't feed anything downstream. When it executes it spawns a background thread that counts down your wait_seconds, then fires a requests.get() at /api/manager/reboot - the exact same route ComfyUI Manager's Restart button hits. The thread is the clever bit: the workflow gets to finish and return cleanly before the server actually dies.

    The inputs that matter

    There are only three, and one of them is just a trigger:

    • any - any-type input. Wire it to the output of your final node so the reboot runs only after everything above it is done. If your last node has no output connector (like a Save Image in some setups), hang it off the nearest node that does.
    • wait_seconds (default 5) - how long to wait before pulling the plug. Since the node runs last in the graph, 5 seconds is usually fine; bump it if you have slow file writes or post-processing that outlives the node's execution.
    • server_url (default http://127.0.0.1:8188) - only matters if ComfyUI isn't on localhost:8188, e.g. you're calling it from another box. A stray trailing slash is stripped automatically.

    There are no outputs. That's the point - it's the last thing in the graph.

    Installing it

    ComfyUI Manager users: search for ComfyUI-reboot in the Manager and install, then restart ComfyUI (yes, you'll be restarting it right after installing the node that restarts it - the irony is not lost). Or, from a terminal:

    cd ComfyUI/custom_nodes
    git clone https://github.com/bobosola/ComfyUI-reboot.git
    

    Restart ComfyUI, then find Reboot ComfyUI under the utils section of the node menu (or double-click empty space and search "reboot"). Its only dependency is requests, which ComfyUI already ships - so there's nothing heavy to download and nothing to configure.

    Where people get burned

    • It needs ComfyUI Manager's reboot route. The node calls /api/manager/reboot, the same endpoint the Manager's Restart button uses. If you run a Manager-less ComfyUI, the request quietly 404s and nothing happens - check the console log. Nearly everyone has Manager installed, but it's worth knowing.
    • It restarts the server, not the workflow. Anything queued or mid-flight gets killed. Fine for a single-user box, genuinely disruptive if other people (or other apps) are queueing jobs against the same ComfyUI. Don't put it in a shared workflow.
    • It's a band-aid for a symptom. The MLX loader leak is the real bug; rebooting after every image is a workaround that costs you a few seconds of downtime and any cached model state. If your nodes unload properly, you don't need this node at all. For everyone on Apple silicon fighting Mflux memory leaks, though, it's the one tool that actually works.

    It's a one-trick pony, but it's the right trick for a genuinely infuriating problem - and at ~50 lines of code, it's easy to trust.

    Categoryutils

    Inputs (3)

    NameTypeDefaultDescription
    any*
    server_urlSTRINGhttp://127.0.0.1:8188
    wait_secondsINT5

    Outputs (0)

    No outputs