Size a render farm for unpredictable, deadline-sensitive work by starting from the deadline, not from the average. Work out how long one video takes on your real hardware, decide the longest wait you can accept for the biggest burst you can reasonably imagine, and let those two facts tell you how many machines you need at the peak. Then build the farm in two layers: a steady base that handles ordinary days, and a way to add capacity quickly for the days that are not ordinary.
Averages are the trap in this problem. A farm sized for the average week will be comfortable on a quiet Tuesday and useless on the one afternoon that matters.
Start with the deadline, not the daily average
Think about a producer at a sports network who makes result graphics from a data feed. Most days a modest number of cards go out through the afternoon and nobody is watching the clock. Then a tournament reaches its final day. A large number of matches end close together, every one needs its card within a narrow window, and the viewers are online now, not later. The work that arrives in an hour on that day is more than the farm handles in a normal week.
If that producer sized the farm on the average, the final day produces a backlog that only clears long after anyone cares. Sizing on the average does not describe the job. The job is the worst afternoon.
So the first question is a business one, not a technical one. What is the latest a finished video can arrive and still be worth anything? For a result card, that may be minutes. For a personalized campaign that goes out overnight, it may be hours. For a weekly report, it may be a day. That window is your deadline, and every other number in the sizing follows from it.
The second question is the size of the peak. Look at your history and find the heaviest burst you have actually seen, not the typical busy day. Then ask what could make the next one larger. A bigger event, a new client, a launch, a data correction that forces everything to be rerendered. You are not trying to predict the future with precision. You are choosing a peak you can defend in a meeting.
Put those together and you have the requirement in a sentence: this many videos, within this long. Everything below is how to meet it.
The arithmetic, with your numbers
The calculation is short, and it is the same one our FAQ gives for estimating a batch. First, render one video, or a small batch, on a machine comparable to the ones you will use in production. The video should be like the rest of the set. Second, multiply the time for one by the number of videos. That gives the total time for sequential rendering on one machine. Third, divide by the number of machines you run in parallel. Our FAQ puts it this way: the production time is cut in half with two machines, in a third with three, and so on.
Now flip it around. You know the window and you know the peak count. Work backward. The total machine time the peak needs, divided by the window, gives the number of machines that must run at once. Then add headroom, because the formula assumes everything goes smoothly and nothing ever does.
Leave room for three things in particular. The first is variation. Your test video was a typical row, and the peak will contain heavy rows too. Run the pre-flight on a heavy row as well and use the slower time for planning. The second is failure. A machine will be busy, rebooting or broken at exactly the wrong moment, and a row will fail and need a second try. The third is everything that is not rendering, such as getting data in, moving footage, encoding and delivering the output. If delivery takes time after the render ends, the deadline has to include it.
We are deliberately not telling you how much headroom to add, because there is no honest universal figure. A deadline where lateness is an annoyance can run closer to the line than one where lateness is a lost event. Decide how much failure you can absorb and size to that.
One more point about the time you measure. Machines are not all equal, and a pre-flight on a fast desktop will flatter a farm made of older computers. Measure on the type of machine you will actually run. Where your fleet is mixed, measure each type, because the slowest one sets the pace for any row you cannot choose to send elsewhere.
How Templater spreads the work
It helps to know what the software does with the load, because the mechanics shape how you build the farm.
Our FAQ describes two ways to produce a very large number of videos, in a queue or in parallel. Templater is built to break a massive workload into manageable batches and queue the jobs sequentially, so it does not overload one system. Alternatively, several machines can run Templater Bot at the same time against the same data source, which divides the workload across devices and produces more videos per hour. The documentation covers how to set up your data source for multiple Bots.
For unpredictable work, Bot matters for another reason. Bot is the edition that checks for incoming data and starts renders on its own, and it can be driven from the command line. That is what lets a farm react to bursts without a person starting each batch. New rows appear in the data source and the machines pick them up. See the Templater page for the editions.
Inside a single machine, Projector can render several videos at once, up to the number of cores in the machine, which makes better use of a powerful workstation than rendering one video at a time. That raises the capacity of each node without adding another one. It is worth testing on your own hardware, because the gain depends on the template and the machine.
If you use QUE to manage the work, one limit deserves attention. QUE does not load balance jobs between satellites at this time. You can assign jobs to specific satellites yourself, so you are the scheduler. That is workable for a small known fleet and a burden for a big, changing one. It also means any satellite you assign work to must have the fonts, plugins and assets the job needs. QUE’s dashboard shows each job’s status and the utilization of rendering machines, which is how you see where the pressure is during a burst. The QUE page has the overview.
A farm in two layers
For unpredictable volume, the most economical design is usually a base and a burst.
The base is the machines you own, sized for the ordinary run of work plus a reasonable margin. They are always on, always warm, and fully configured. Because they are used constantly, their cost per video is low. Do not size the base for the worst day. Machines bought for a peak sit idle most of the year, and we covered why that is expensive in our comparison of on-premise and cloud approaches.
The burst is whatever you can add quickly when the peak arrives. There are a few ways to build it. You can run Templater on rented Windows Server machines in a cloud environment such as AWS, which our FAQ says is supported with no special Dataclay license. After Effects has to be installed on them and Adobe’s standard license does not permit After Effects on a server, so settle the Adobe license question before the day you need the machines. You can keep spare in-house machines, such as workstations that sit idle in the evening, ready to join. Or you can send overflow to a cloud platform that renders After Effects templates for you.
Whichever you choose, rehearse it. A burst layer you have never used will not work the first time at the worst moment. Build the machine image once, with the right After Effects, Templater, fonts and plugins, then test one real row on it, and keep that image current. The check that matters is whether a freshly added machine can render a row without anybody touching it.
Open-source options exist as well. Nexrender, for instance, describes a server that queues jobs over HTTP with workers that pick them up and render, so that several machines can act as a render farm, and it renders with Adobe’s aerender command-line tool. Teams comfortable running their own Node.js infrastructure sometimes prefer that route. Its page says nothing about spreadsheet connections, which matters if your data starts in one. Plainly, which renders on cloud-based After Effects infrastructure, says concurrency depends on the plan, so ask what the ceiling is before you rely on it for a burst. Both are worth reading about on their own pages.
What else limits the farm
More machines will not help if the bottleneck is somewhere else, and in a burst the bottleneck often moves.
Data can be one. If your source is a spreadsheet that a person edits by hand during an event, the rows arrive at the speed of a person. If it is fed by an API, they arrive faster than anyone can read them. Check that the data side can keep up with your peak and that rows are correct when they appear, because a flood of wrong rows is a flood of wrong videos.
Assets can be another. Several machines pulling the same large files from one shared drive will slow each other down. Per-row images fetched from a remote server may be limited by that server. Test with the number of machines you intend to use, not just one.
Licensing is a third. A Standard License works on one machine at a time. A Floating License can be used by any number of machines on a network with a licensing server, but only one system can use it at any one time, so it does not give you concurrent machines. Count the licenses you need for the number of machines rendering together, and read our licensing guide before the day arrives.
Last, remember delivery. If finished files have to be transcoded, uploaded and registered somewhere, those steps queue too. Projector can transcode as part of the render payload and send finished videos to supported platforms, which keeps that stage inside the same automated chain.
Not every job has the same deadline
A single farm usually serves more than one kind of work, and the kinds do not share a deadline. A result card that has to appear while the audience is watching and a back catalog of reformatted clips that needs to finish by Friday are both “video jobs,” and treating them as one pile is how the urgent one waits behind the bulk one.
The simplest protection is to separate lanes. Reserve some machines for the urgent, short-fuse work and let the rest chew through bulk jobs. You lose a little efficiency, because an urgent machine may sit idle while the bulk lane has a backlog. You gain a guarantee, which is worth more when the urgent work is the part people see. With QUE you assign jobs to specific satellites yourself, so a dedicated lane is a matter of which satellites you name. With several Bots watching one data source, you can keep the urgent work in its own data source and point only some machines at it.
Be strict about what counts as urgent. If everything is marked urgent, the lane is a second bulk queue with a worse name. Write down the short list of job types that earn it, and have someone senior hold the line.
Finally, plan for the rerender. In the worst moments a data correction lands after the batch is out, and the whole set must be redone. Decide ahead of time whether a rerender takes priority over new work. It is a business decision with a technical consequence, and it is far easier to make calmly in a meeting than on the afternoon it happens.
Test the farm before the day
You do not know the capacity of a farm until you have pushed it. Rehearse a peak. Take a realistic burst of rows, drop them into the data source all at once, and watch. See how long the whole set takes. See which machine idles while another struggles. See whether any row fails and why. Then look at the log and at the dashboard if you use QUE.
Fix what the rehearsal exposes, and run it again. A rehearsal done twice, a week before the big day, is worth more than any amount of careful planning on paper.
Also keep a human plan. Decide in advance who watches the farm during a burst, what they do if a machine drops out, and the point at which they add capacity instead of waiting. Automation handles the rows. A person still decides what to do when the plan stops matching the afternoon.
Bottom line
Size for the deadline and the worst burst you can defend, not for the average. Measure one real heavy row on the machines you will use, divide the total by the number of machines, and add headroom for variation, failure and delivery. Build a steady owned base for ordinary work and a rehearsed way to add machines for peaks. Check the data, the assets and the licenses before you add hardware, because the farm is only as fast as its slowest link. And run a rehearsal burst before the day that counts.
Farm sizing raises the same questions every time a team plans for a peak. Here are the ones that come up most.
Frequently Asked Questions
How many render machines do I need for my peak?
Work backward from the deadline. Time one real video, including a heavy row, on the type of machine you will run. Multiply by the number of videos in your peak to get the total machine time, then divide by the window you have to deliver. The result is the number of machines that must run at once. Add headroom for variation, failures and delivery. The right figure is yours, not a number we can print for you.
Why not size the farm for the average week?
Because the average hides the burst that matters. A farm sized for the average is comfortable on quiet days and falls behind on the day many jobs land together. Size for the longest wait you can accept at the heaviest burst you can defend, then cover ordinary days with a base and peaks with capacity you can add quickly.
Can several machines work on the same batch?
Yes. You can have multiple machines running Templater Bot in parallel against the same data source, which divides the workload and produces more videos per hour. Our documentation explains how to set up the data source for multiple Bots. If you render in parallel, the total production time falls in proportion to the number of machines.
Does QUE balance the load across machines automatically?
Not at this time. QUE does not load balance jobs between satellites. You can assign jobs to specific satellites yourself, and you must make sure each satellite has the fonts, plugins and assets the job needs. QUE’s dashboard shows each job’s status and the utilization of rendering machines, which helps you decide where to send the next job.
Can I add cloud machines just for peak days?
Yes. Templater can run on Windows Server machines in a cloud environment such as AWS, and Dataclay requires no special license for that. After Effects must be installed there, and Adobe’s standard license does not permit After Effects on a server, so speak to Adobe about the right license ahead of time. Build and test a machine image before the peak, not during it.
Do I need a license for every machine that renders at once?
A Standard License is activated on one machine at a time. A Floating License can be used by any number of devices on a network connected to a licensing server, but only one system can use it at a time. For machines rendering at the same time, count the licenses you need and read our licensing guide before the peak.
How should I rehearse a burst?
Drop a realistic spike of rows into the data source all at once and watch the whole chain, from data arrival to delivery. Note how long the set takes, which machines idle, which rows fail, and what the log says. Fix what you find and run it again. A rehearsal a week before the real peak is worth more than planning on paper.
