Save Video to PC ⚡

Save Video to PC is the least-documented node in this pack's save family, and it has two surprises before you even wire it up. First: it doesn't take a VIDEO input. Second: it doesn't save anything by itself. It takes a file path - a string pointing at an already-rendered file on disk - and streams that file over HTTP to a receiver profile, waiting for the receiver to confirm the write before it reports success.

That's what separates it from the pack's SaveVideoToFolder, which writes to local disk. This is the "ship the finished file to another box" node, built on the exact same receiver_config.json machinery as SaveImageToPC. A separate "comfy-media-receiver" server has to be running and reachable, because the receiver owns all the routing - its save_key profiles decide folder and filename. Nothing in this repository ships that receiver. The config template's default "Home PC" profile points at the author's private Tailscale address and won't reach anything you own until you edit it, and none of this appears in the README. It's personal infrastructure that got published. Proceed accordingly.

When it works, the flow is genuinely neat. Put the source path in file_path - you'll usually pull it from something like SaveVideoToFolder's saved_path output, or type it in. The node sniffs the media type from the extension (mp4/webm/mkv/mov → video, png/jpg/webp → image, mp3/wav/flac → audio, anything else → plain "file"), so it will happily ship any completed file, not just video. filename overrides the name the receiver sees; save_key picks the receiver-side save profile. The node blocks until the receiver confirms, then returns the saved_path STRING.

The one feature worth calling out is delete_after_success. It defaults to false. Flip it on and the source file is deleted only after the receiver returns its ok - never before, and not if the upload fails. That's the right shape for an "archive it on the other machine, then free the GPU box's disk" workflow, and it's the sort of safety detail you want from a node that's allowed to unlink your renders.

Failures are loud and specific. Wrong path → "file not found." Receiver down → a RuntimeError naming the profile and URL. There's no quiet-does-nothing failure mode, which is the one thing saving you from silent data loss.

The key inputs, once more, since they're easy to misread:

• file_path - absolute path to the finished file on the ComfyUI machine.
• receiver_profile - which configured receiver (dropdown, from the config file).
• save_key - the receiver-side profile that decides where the file lands.
• delete_after_success - the delete-only-after-confirmation flag described above.

The optional model_name, workflow_name, prompt, seed, job_id, and extra_metadata fields are identity metadata sent along for the receiver to name and file things - the receiver, not you, picks the destination.

Install is pack-standard: ComfyUI Manager → search ComfyUI-Get-Random-File → Install → restart, or git clone https://github.com/ChrisColeTech/ComfyUI-Get-Random-File into custom_nodes. No models to download; requests is the only real dependency behind the HTTP.

Honest take: for most people who find this node in a shared workflow, the correct move is to replace it with SaveVideoToFolder and save locally. SaveVideoToPC only earns its place if you genuinely run a receiver endpoint somewhere - which, for nearly everyone reading this, is a hobby project you probably don't want to operate. It's well-built for what it does. It's just built for a workflow almost nobody has.