How to build a Blender render farm
· By Richard
In this article I'll go over a few different ways you can setup a render farm for Blender yourself. Starting very basic, and going more advanced step by step.
But before that, why would you even want to build a render farm?
As you might know, one of the most common problems with 3D rendering is how long it takes.
There are plenty of solutions that aim to speed up rendering. They typically fall into one of two categories:
1. Optimizing efficiency
2. Adding more compute power
Render farms are a category 2 solution.
What is a render farm?
If you're reading this article, you're probably interested in building a render farm, so you know what it is. But it's good to have a common defenition before we dive in.
I consider a render farm: multiple computers that work together on rendering a project.
A single computer is not really a render farm in my book. But I consider two computers rendering one animation a (tiny) render farm. So if you have two computers at home, you can setup a render farm.
A "project" in this context can be anything you need to finish rendering, like a frame, an animation, or even multiple animations.
But let's consider the exmple of one animation, with multiple frames that can all be rendered independently. This means we can render frame 50 for example, without rendering frames 1-49 first. Most Blender animations behave like this. Only simulations tend to be different, but if you bake the simulations, frames can be rendered independently.
Now, let's look at some different strategies we can make our computers render together. The first two strategies you can do at home, the last two are a bit more technical.
Strategy 1: Even / Odd rendering
Let's say you have a 200 frame animation to render, and you have access to two computers with similar performance. Similar performance is important for this strategy to be efficient.
Instead of just rendering all the frames on a single computer, you can let one computer render the even frames (2, 4, 6, 8, ...) and the other computer the uneven frames (1, 3, 5, 7, ...).
The original frame range of the animation is:
start frame: 1
end frame: 200
frame step: 1
This renders 200 frames (1, 2, 3, ... 198, 199, 200).
But now you want to change the range as follows:
On computer A:
start frame: 1
end frame: 200
frame step: 2
This renders the 100 odd frames (1, 3, 5, ... 195, 197, 199)
On computer B:
start frame: 2
end frame: 200 (no change)
frame step: 2
This renders the 100 even frames (2, 4, 6, ... 196, 198, 200).
File management
File management for this strategy is pretty simple.
Before you can start rendering you have to copy your .blend file to both computers. After rendering you have to put all your frames together into the same folder. This can be done manually, but if your two computers are on the same network, you can definitely use a network drive for this that both computers can access to make things easier.
The benefit of this strategy is that it's not strictly required for the two computers to be linked up through a network, you could manually move the files to the right place and everything still works.
Command line
If you want to automate this more, you can kick off rendering from the command line with the following options:
On computer A:
blender -b <yourfile.blend> -s 1 -e 200 -j 2 -a
On computer B:
blender -b <yourfile.blend> -s 2 -e 200 -j 2 -a
You might expect the step setting to be set with -s but -s is already used for the
start frame, so we use -j (for jump). -e is for the end frame. And the -a
option means render the animation as opposed to only a single frame.
More than 2 computers
Even / odd works for two computers, what if you have 3 or more? Then you just increase the frame step.
If you have 5 computers, you can set the frame step to 5 such that each computer only renders 1 out of 5 frames. The first computer's start frame should be 1, the second computer should start at 2, the 3rd computer starts at frame 3, etc.
Workload balance
What you typically want to optimize for when running a render farm, is balancing workload evenly across computers.
One of the big flaws with this method, is that the computers need to render at the same speed for this to be efficient. All computers render the same amount of frames. So if one computer is a bit faster, it will finish its frames before the other(s) and it will just sit there doing nothing for the final part, waiting for the slower computers to finish. We don't want our computers doing nothing because that means we could have rendered faster if we keep all computers busy with work.
It would be better to give the faster computers a bit more work so that all computers are rendering 100% of the time. With this strategy that gets a bit complicated. So this is what we will fix with the next strategy.
Strategy 2: Touch and don't overwrite
In the previous strategy we gave our computers some work to do upfront, and let them run with it until they're done. We did not really let the computers communicate with each other about how fast they were rendering, which frames were already rendered etc. The only way to make this work well is to use computers that all render at about the same speed.
If we have computers with varying performace that we want to use as a render farm, we will use the "touch and don't overwrite" strategy. Blender has some really nice features that make this very easy.
File management
The prerequisite for this strategy is that all computers need to have access to some sort of shared storage. This can be a drive on a local network, but it can also be a shared Dropbox folder, or any other cloud storage that has an automatic syncing feature.
This makes it easier for the computers to all open the same .blend file, which is nice. But more importantly, we need it to have the computers all store their rendered frames in the same location.
Setup
This time, we will leave the frame range settings alone, and let all computers render the same range. But to prevent multiple computers from rendering the same frames, we use the following two options:
Turn off "Overwrite"
Turn on "Placeholders"
The Overwrite option is used when you render an animation (multiple frames). When it's turned on, Blender will render every single frame in your frame range, regardless of whether it already exists (so it overwrites existing frames). But when it's turned off, before rendering any frame, Blender checks if the output file already exists, and if it does, it skips the frame and moves on to the next.
So turning off this Overwrite option will prevent multiple computers from rendering the same frames. However, rendering a single frame takes a while, so when multiple computers are kicked off to render a frame range, they will all start rendering the first frame, because it doesn't exist yet. Ending up rendering the same frames. This problem is solved with the next option: Placeholders.
If Placeholders is checked, Blender will create an empty dummy file with the same name as the final frame, before it starts rendering it. This happens in a fraction of a second, so even if multiple computers are instructed to render the same frame range, one computer will typically be the first to create this dummy file, and then the other computers (if they can access the same shared drive) will be able to detect this file, and skip that particular frame, moving on to the next one. When the frame is rendered, the dummy file is replaced with the real image file.
Since this dummy file is 0 bytes, it syncs very fast across devices, even if you use cloud storage like Dropbox. It is technically still possible for two computers to render the same frame if they start exactly at the same time, but it's quite rare in my experience.
This is how I rendered a bunch of animations at an abandoned UCLA computer lab during a summer break (before I had Blendergrid).
Command line
For this strategy, command line rendering looks the same on every computer:
blender -b <yourfile.blend> -a
We only need the -a flag to tell Blender to render the entire animation. I'm assuming "Overwrite" is unchecked and "Placeholder" is checked in the .blend file itself here. If that's not the case, you can enforce it through the command line as well:
blender -b <yourfile.blend> -a
Workload balance
The main benefit of this strategy compared to the even/odd strategy is it automatically balances the workload across all your computers. It doesn't really matter how many computers you add to the farm. It also doesn't matter if during rendering you add more or remove computers. There is a form of communication which lets the computers collaborate, they will know which frames are rendered or are being rendered, and each computer starts rendering a different frame.
Strategy 3: Datacenters
This is probably what most people consider "real" render farms: A bunch of servers in a datacenter specifically made for rendering. These servers are not like laptops or desktops that you use for personal work, they don't have screens and keyboards attached to them, you access them over a network connection and give them some commands.
So this is were command line rendering comes in. The command line options for rendering with Blender are useful, but these are typically intended for a single computer. When we want to render with multiple computers it's useful to have cluster management software on top of this that orchestrates the blender commands.
Most cluster management software has the concept of a job queue. A job could be: render a certain frame. Then you would specify these jobs and put them in the queue.
Every server in the datacenter can pick a job from the queue, execute it, and store the result (the rendered frame) in some central place. Leaving you with all computers rendering together and making progress on the animation.
Technically this is a lot more advanced, and there are a lot of options in terms of management software for the render farm. In the early days at Blendergrid we used "Sun Grid Engine" to distribute frame rendering over a cluster of servers. Later we built our own custom software on top of Docker Swarm to manage everything.
Strategy 4: Cloud Computing
In case you don't have access to your own datacenter, there is the option of cloud computing, where you rent servers by the hour from a cloud provider.
There are many cloud providers out there, some of the most popular ones are:
Amazon Web Services
Google Cloud
Microsoft Azure
But there are many more.
What you then get is some server that you can log into through SSH typically. This allows you to run commands on the server, so in order to render on these servers, you also need to run Blender with its command line options.
Closing thoughts
If you keep things simple, it's very doable setting up a render farm at home or at the office with a bunch of computers that you have access to. (strategies 1 and 2)
For more than a few dozen computers, switching over to a more advanced setup (strategies 3 and 4) is usually what you want to be doing.
At Blendergrid we've built a cluster of render farms in the cloud. We're running in 35 datacenters across the globe at the time of writing this (2026). So if you need the power, but you don't want to set it up yourself, consider giving our farm a try by uploading your .blend file here.