A render farm out of your idle laptops

A desktop app that turns the spare computers in your house into a shared queue for Blender renders and video encodes.

The idea

A small desktop app you install on every computer you own. One instance acts as the coordinator and holds a job queue; the others register themselves as workers over the local network. You drop in a Blender scene or a folder of video files, pick an output, and the coordinator splits the work into frame ranges or per-file chunks and hands them out. Workers pull their chunk, run Blender or ffmpeg locally, push the result back, and the coordinator stitches the pieces. No accounts, no cloud, no per-minute billing — just the machines already sitting in the house.

Why build this

Anyone who renders or encodes locally knows the shape of this problem: one machine pinned at 100% for four hours while a laptop, an old desktop, and a work machine sit idle on the same wifi. The commercial answer is a cloud render service, which works but turns a fixed cost you already paid into a variable one, and means uploading assets you may not want to upload. The existing self-hosted options are built for studios — Flamenco and Deadline assume a managed network, shared storage, and someone to run them.

The gap is the three-machine household. Apple Silicon and recent Ryzen laptops are genuinely fast at encoding, consumer GPUs render Cycles well, and both Blender and ffmpeg have clean headless CLIs that take a frame range or a segment and write a file. The hard part was never the rendering — it's discovery, file movement, and not having to think about any of it.

Stack sketch

Tauri 2 with a Rust core — small binaries, and the worker needs to be a long-lived background process, not a browser tab.
Discovery via mDNS (mdns-sd), so workers find the coordinator with no configuration beyond being on the same network.
Job queue in SQLite on the coordinator, with chunks as rows and a lease timestamp per chunk so a worker that sleeps or closes its lid simply loses its lease.
Asset transfer over plain HTTP from the coordinator, content-addressed by BLAKE3 hash, so a worker that already has the scene file skips the download.
blender -b scene.blend -s 100 -e 120 -a and ffmpeg -ss/-to for the actual work, invoked as subprocesses. Parse their stdout for progress.
Stitching with ffmpeg concat for video, and leaving image sequences as-is.
Signed pairing: the coordinator shows a six-digit code, the worker enters it once, and they exchange keys. Enough to stop a guest device joining by accident.

Scope for v1

In: Blender frame-range splitting, ffmpeg per-file and per-segment encoding, mDNS discovery, lease-based chunk retry, a single-window UI showing the queue and which machine is on which chunk.
In: pausing a worker, and a "only while plugged in and idle for 10 minutes" toggle.
Out: GPU scheduling beyond "this machine has a GPU, prefer it for Cycles".
Out: shared network storage, cross-subnet or internet workers, and any kind of multi-user permissions.
Out: After Effects, Houdini, and anything whose CLI needs a licence check per invocation.

Where it could go

The obvious next step is other long-running local jobs with the same shape: Whisper transcription over a podcast back catalogue, photogrammetry, batch image upscaling, local LLM evaluation runs. Each is a CLI that takes a slice of input and writes a slice of output, which is the only contract the scheduler needs. A plugin format — a TOML file declaring the command template and how to split the input — would let people add tools without touching the Rust.

The second path is making an idle machine genuinely useful without being annoying: wake-on-LAN to pull a sleeping desktop into a queue, thermal and battery awareness, and a nightly window where the farm runs flat out and stops before you sit down in the morning. Past that there's a small-studio version with a web dashboard and job history, which is where a paid tier would sit, but the free local app has to be good on its own first.

Watch out for

Version skew will bite you before anything else: a chunk rendered by Blender 4.2 and a chunk rendered by 4.5 can differ subtly in denoising output, and the seam shows up mid-shot. Record the exact binary version per chunk and refuse to stitch a job whose chunks disagree.