Planning your fleet
Three arrangements that work: one machine, a handful on a home network, and a facility on a wired VLAN. The software is the same in all three.
There is no separate edition for small setups. You add machines and it gets faster. What changes as you scale is not the software but the things around it — where the media lives, how the network is arranged, and how much you care who can join.
One machine#
Run the master and one worker on the same computer. This is a complete, supported configuration, not a degraded one.
You still get chunked parallel encoding: the source is split, and the worker processes chunks using the cores available to it. The gain over a single FFmpeg process comes from parallelism the encoder cannot extract on its own, particularly on codecs that do not scale well across many threads.
The other benefit is that nothing is copied. A worker on the same machine reads the source directly off disk, so there is no transfer cost at all.
Setting up one machine first means that when you add a second, you are debugging one new thing — the network — rather than everything at once. The configuration you end up with does not change.
A few machines on a home or small-office network#
The common arrangement: a desktop that stays on runs the master, and two or three other machines run workers. An old workstation, a partner's desktop overnight, a machine that used to be the render box.
- Put the master on the machine that is on most often, not the fastest one. A worker that disappears costs you one chunk; a master that disappears takes the queue with it.
- Connect everything by ethernet. This is not advice — the master refuses workers on Wi-Fi by default, and you have to deliberately override it. See Allowing non-wired workers.
- Workers find the master by themselves on a flat network. If your machines are on different subnets or a managed switch blocks discovery, point each worker at the master directly.
A machine that sleeps is worse than a machine that is off. Sleeping mid-chunk means the master waits on a worker that will not answer until the timeout elapses and the chunk is reassigned. Disable sleep on anything you intend to contribute.
A facility#
At facility scale the software is unchanged; three operational decisions become real.
Set an enrollment token on the master and give it to each worker. Without one, any machine that can reach the port may register and wait for approval. On a network with contractors, freelancers and personal laptops, that is a queue of unknown machines rather than a security incident — but close it anyway.
Approval is the human gate before a machine encodes. Whoever holds the administrator account owns it. At scale it is worth having one named person do it rather than leaving it to whoever notices.
At a handful of machines, transfer cost is tolerable. Across dozens it dominates. See below.
Workers with GPUs are handled without configuration — hardware encoders are detected during registration and the scheduler accounts for how many simultaneous sessions a card supports. NVIDIA, Intel Quick Sync and Apple VideoToolbox are all probed. A mixed fleet of GPU and CPU machines is normal and works.
Storage is the real decision#
This determines your throughput ceiling more than processor count does.
| Arrangement | What happens | Suits |
|---|---|---|
| Shared volume, same path everywhere | Workers read the source directly. Nothing is copied over the network. | Any fleet past two or three machines |
| No shared storage | The master serves each worker the bytes its chunk needs and takes the encoded result back. | Small fleets, mixed machines, anything temporary |
The second arrangement is fully supported and is what makes a five-minute setup possible. It is also the thing that stops scaling first: every chunk crosses the network twice, and the master becomes the bottleneck long before the workers do.
The path has to resolve to the same file everywhere. A drive mapped to Z: on one machine and mounted at /mnt/media on another is two paths, not one. Use a form every machine agrees on.
What actually limits throughput#
Adding machines stops helping at some point. In roughly the order you will hit them:
- The tail chunk. A job is not finished until its slowest chunk is. One machine much slower than the rest sets the finish time no matter how many fast ones you add.
- Chunk count. A short source does not divide into enough chunks to occupy a large fleet. Twelve seconds per chunk means a two-minute clip is about ten units of work — six machines will not beat three on it.
- Transfer, when storage is not shared. High-bitrate sources can take longer to move than to encode.
- Assembly. Joining, muxing and verifying happen on the master, single-threaded relative to the fleet. On long sources this is real time that more workers do not reduce.
The practical consequence: distribution pays off most on long sources and expensive codecs. On a thirty-second clip in a cheap codec, the coordination costs more than it saves.
Growing the fleet#
Add machines one at a time and watch the chunk map on a real job after each. You are looking for chunks spread across every worker you expect. A machine that never takes a chunk is either unapproved or lacks a capability the preset needs, and both are visible on the Workers page.
Keep every machine on the same release. A worker on a different version may report capabilities the master does not understand, and mixed FFmpeg builds across a fleet undermine the guarantee that every chunk of a job was encoded identically.