Building Your Own Blender Render Farm: A Step-by-Step Guide

A render farm splits work across several computers instead of rendering frames one after another on a single machine. If you have a few spare PCs or GPUs sitting around at home or in the office, you already have most of what you need. This guide covers the setup step by step, updated for Blender 4.4 (the latest stable version as of June 2025).

Whether it's worth doing depends on how often you render. The hardware is already paid for, so the marginal cost is electricity, but you become the person who maintains it. If you'd rather not, RenderDay is our own GPU cloud render farm and exists for exactly that case. The rest of this article is about building your own.

One thing to know first: Blender's old "Network Render" add-on from the 2.7x era is gone. It was never ported to 2.8+ and won't work in 4.4, so ignore any tutorial that tells you to enable it. The two current options are Flamenco, an open-source render manager developed with support from Blender Studio and used in their productions, and CrowdRender, a third-party add-on aimed at quick setup on a small network. Both work with Blender 4.4. We'll set up each one.

Requirements: hardware, software, and network

Before setting up the render farm, make sure you have the following in place:

• Multiple Computers: At least two computers (one will act as the controller/main machine, and one or more as render nodes). They don't have to be identical, but the more powerful each is, the better overall performance. Blender runs on all major 64-bit operating systems (Windows 10/11, Linux, macOS 11+ on Intel or Apple Silicon) - you can mix OSes in your farm if needed. Each computer should meet Blender 4.4's minimum requirements, and ideally the recommended specs for heavy rendering. For example, Blender's official guidance suggests a 64-bit, 8-core CPU, 32 GB of RAM, and a GPU with 8 GB VRAM for optimal performance. Older or less-powerful machines can still contribute, but expect that a node with a slow CPU or limited GPU might render its part more slowly.

• Modern GPUs (Optional but Recommended): If you plan to use GPU rendering with Cycles (highly recommended for speed), ensure your graphics cards are supported by Blender 4.4. Generally, NVIDIA GPUs from the GTX 400 series upward (including all RTX cards) and AMD GPUs from GCN 1st gen (Radeon HD 7000 series) upward are supported, as well as newer Intel GPUs. Each GPU should have sufficient VRAM (at least 2 GB, but 8+ GB is recommended for complex scenes). Using GPU-accelerated rendering on each node can dramatically improve render times, as Cycles can take advantage of CUDA, OptiX (NVIDIA), HIP (AMD), or oneAPI (Intel) on different hardware. Note: All nodes don't need identical GPUs; Blender will use whatever device is available on each (you can even mix GPU and CPU rendering across nodes). Just keep in mind that very old GPUs (or outdated drivers) may not be compatible with Blender 4.x's requirements - always update to the latest graphics drivers for best results.

• Blender 4.4 Installed: Install Blender 4.4 on every machine in the farm. Using the exact same Blender version on all nodes is crucial to avoid compatibility issues. Mismatched versions can lead to errors or subtle differences in rendered output. So, if you update Blender on one machine, update it on all of them. Blender can be run in "headless" mode on render nodes (no GUI) if you're comfortable with command-line, but for initial setup it's fine to use the standard installation.

• Network Connection: All the computers must be connected via a network. A local area network (LAN) is ideal. Wired Ethernet is preferred for reliability and speed - a Gigabit network switch or router is recommended. (100 Mbps is the bare minimum; 1 Gbps or higher will significantly speed up file transfers and communication between nodes.) While Wi-Fi can work for a small farm, it may introduce latency or dropouts if you're sending large files between machines. If your render nodes are in different physical locations (e.g. different offices or a mix of local and cloud machines), you might need to set up a VPN or port forwarding - but for a home/office LAN, it's usually plug-and-play. Make sure each machine can ping the others (i.e. they are on the same subnet and not blocked by network settings).

• Firewall Settings: On each node, configure firewalls to allow Blender or the render management software to communicate. By default, CrowdRender uses TCP ports in the range 9669-9694 on each machine. When you first connect nodes, Windows or macOS may prompt to allow Blender network access - be sure to approve this. If using Flamenco, the Manager and Workers communicate typically over a configurable port (default 8080 for the web interface, plus worker ports); ensure those are open or add exceptions as needed. Essentially, all farm machines should be able to send/receive data to each other for the render tasks.

• Shared Storage (for Flamenco or heavy projects): It's not strictly required to have a network-attached storage, but it can be very helpful. Flamenco in particular expects a shared folder that all machines can access (for uploading blend files and saving outputs). This could be a NAS device or simply a folder on one machine that's shared over the network (using SMB on Windows/Mac or NFS on Linux). If you use a shared drive, ensure it's mounted with the same path on all nodes (for example, each computer maps \\Server\BlenderFarm to the same drive letter or mount point). For CrowdRender, having a shared storage is optional - CrowdRender can automatically pack and send the scene data to each node - but a NAS can still help if your project has huge assets or simulation caches (so you don't duplicate that data on each node). We'll discuss asset handling more in the project preparation section.

• Render Management Software: You will need to choose a tool to coordinate rendering across the farm. As mentioned, the two main choices are CrowdRender (add-on) and Flamenco (manager & add-on). You should not attempt to use Blender's old Network Render add-on, as it no longer works in Blender 4.4. We cover setup for both CrowdRender and Flamenco below - you can pick the one that suits your needs (CrowdRender is a bit easier for small farms, while Flamenco is more scalable for larger setups or studio pipelines). It's possible to mix tools, but generally you'll stick to one system for your farm to avoid conflicts.

Once your hardware meets the specs and the network is configured, it's time to prepare your Blender project and then set up the render farm software.

Preparing your Blender project for distributed rendering

Before dispatching a job to the farm, set the project up so every node can reach all the data it needs:

• Pack or share external assets: When you render on multiple machines, each machine needs the same blend file and any linked resources (textures, simulations, proxies, etc.). The simplest way to ensure this is to pack all external data into the .blend file (Blender has an option: File → External Data → Pack All Into .blend). This embeds image textures and such into the file, so when the file is sent to a render node, everything it needs is self-contained. Note: Some data cannot be packed (for example, fluid or physics caches, or very large image sequences). For those, you have two options: either manually copy those cache folders to each render node (in the same directory path), or use a shared network folder so that all nodes read the cache from a common location. If you use a shared NAS as mentioned, ensure your Blender project's cache/output directories are pointed to that shared path. The key is that when a node tries to load an asset or write an output, the path is valid on that node.

• Keep output paths consistent: Decide where the rendered frames or image will be saved. If you're using CrowdRender, the add-on will by default transfer rendered frames back to the master machine and save them where the primary Blender instance (client) is set to save output. This means you can often just set an output folder on the master machine (even a local folder) and CrowdRender will gather everything there through the network. However, make sure the master has enough disk space for all the output frames - remember that image files (especially if OpenEXR or high resolution) can be large. For example, a single 1080p OpenEXR frame can be around 100 MB, so 200 frames would be ~20 GB. Plan your storage accordingly. If using Flamenco with a shared storage, you'll likely set the output directory to a folder on the shared drive so that all workers write to the same location. Double-check that this folder is accessible and has write permissions for all nodes.

• Bake your simulations: if the scene has physics (smoke, fluids, particles) or dynamic geometry, bake to cache files before rendering on the farm. Otherwise each node re-simulates independently and you get frames that don't match. Bake on your main machine, store the cache in a shared location or pack it, and verify each node can read it.

• Test load the .blend on a node or two: open the project on a couple of render nodes, especially any with a different OS or GPU. Does it open without missing textures? Does a single local frame render correctly? Five minutes here catches path problems and add-on dependencies that would otherwise surface halfway through a 400-frame job.

Setting up the render farm software

Option 1: the CrowdRender add-on (easy setup)

CrowdRender is a third-party add-on that runs inside Blender on each machine and coordinates splitting frames (or image tiles) between them. There's no separate server program to install, which is what makes it suitable for small to medium farms, roughly 2 to 20 machines on a LAN. Setup:

1. Download and Install CrowdRender: Visit the official CrowdRender website and download the latest version of the add-on (as a .zip file). There is a free version available for the public (at time of writing, v0.6.x supports Blender 3.x and 4.x). You'll need to install this add-on on every machine that will participate in the render farm. On each computer, open Blender and go to Edit → Preferences → Add-ons, click "Install…", and select the CrowdRender .zip. After installation, check the box to enable the add-on. You should do this in Blender 4.4 on all nodes (the main controller and all render clients). Remember, all nodes must run the same version of Blender and the add-on for compatibility.

2. Set Up Each Node in CrowdRender: Once enabled, CrowdRender adds a panel (typically in the 3D View's sidebar or the Render Properties tab - check the documentation for the exact location in Blender 4.4's UI, as it might appear under a Render section). On each render node (except the main one), you'll want to set it to "listening" mode so it can accept connections. Usually, simply having Blender open with the add-on enabled is enough - the add-on will start a background process waiting for incoming render jobs. Ensure you know each node's hostname or IP address on the network.

3. Connect Nodes to Master: On your main machine (the one from which you'll control the render and have your scene open), use the CrowdRender UI to add new render nodes. In the CrowdRender panel, there should be an option to add a node and input its address (IP or network name). Enter the details for one of your other machines and connect. If the connection is successful, the new node will appear in the list with a status (e.g. "Connected") and show its resources (like number of CPU threads, GPU info, etc.). Repeat this for each render node you have, adding them to the master's list. CrowdRender will also list a "This Machine" or "Local" node, which is the master itself - you can include it in renders as well if you want the master PC to also render alongside the others.

   • Troubleshooting connection: If a node fails to connect, verify that Blender is running on that node, the CrowdRender add-on is enabled there, and no firewall is blocking Blender. You might need to ensure Blender is allowed through the OS firewall on each node (as mentioned earlier, CrowdRender uses TCP ports 9669-9694 - the first connection typically uses 9669). Also double-check you typed the correct IP. You can test connectivity by pinging or using the node's IP in a web browser with the CrowdRender port (though it might not give a webpage, just seeing if the port is open).

4. Configure Node Settings (Optional): CrowdRender usually auto-detects the node's capabilities. However, you can customize some settings. For example, you can specify whether each node should use its GPU or CPU for rendering (it will use whatever Blender is set to on that node - so ensure each Blender instance's Preferences → System → Cycles Compute Device is set appropriately, e.g. GPU Compute if available). If a node has multiple GPUs, it will use all by default unless you limit it. You can also set a node to only handle certain frame ranges or tile sizes, but those are advanced tweaks - by default, the add-on manages load distribution automatically.

That's the farm assembled: all nodes connected to the master Blender. From here the add-on handles data transfer, sending the .blend and its packed resources to each node, starting the render, and collecting results back. Next, actually running a job.

Option 2: Flamenco (advanced setup)

Flamenco is an open-source render farm manager developed by the Blender Studio team. It takes more work to set up because it uses a manager and worker model like professional render management systems, but that's also what you're paying for: a dedicated render queue, a web interface, multiple projects, and sane behavior with a larger number of nodes. Setup:

1. Obtain Flamenco Manager and Worker: Download Flamenco from the official site . Flamenco consists of a Manager (server) and a Worker agent. The Manager coordinates the jobs, and each Worker runs on a render node to execute tasks. Choose one machine to be the "Manager node" - this can be a spare PC or even the same as your main workstation (though for heavy use, a separate manager is better). The Manager will run a lightweight web service to which all Workers and your Blender add-on connect. Extract the Flamenco Manager package on the manager machine. Flamenco is cross-platform (runs on Windows, Linux, macOS), so your manager and workers can be on any OS mix.

2. Run the Flamenco Manager: The exact steps may vary with Flamenco versions, but typically you'll have a configuration file (YAML or similar) to edit with settings like the server port, database path (Flamenco uses SQLite by default), and a path for shared storage. After configuring, launch the Flamenco Manager service. It will start a web interface (often accessible at http://<ManagerIP>:8080 by default). If you prefer not to self-host, note that Blender Cloud subscribers have the option to use Flamenco in the cloud - Blender Studio provides a hosted Flamenco Manager on their cloud, which your local machines can connect to. In that case, you'd log in via your Blender ID and skip running a local server. But for a fully local farm, running the Manager on your network is the way to go.

3. Set Up Shared Storage: As mentioned, Flamenco expects a shared storage location. Ensure you have a folder that all Worker machines and the Manager can access. In Flamenco's config, set this as the "shared storage" path. For example, you might have a NAS mounted as Z:\Flamenco\ on all Windows nodes, or /mnt/flamenco on Linux nodes. The Manager will use this to place blend files and collect results. According to Flamenco's design, when you submit a job, the Manager receives it and moves the blend file and any needed files into the shared storage, then instructs Workers to render. So verify the Manager can read/write to that folder, and Workers can too (test by manually creating a file from each machine to ensure permissions).

4. Start Flamenco Workers on Each Node: On every render node (each machine that will do the rendering), download and install the Flamenco Worker application. Configure each Worker with the Manager's address (e.g. the IP/hostname of the Manager machine and port 8080, plus an authentication token if set). Run the Worker - it should connect to the Manager and register itself (often you'll see it appear in the Flamenco web interface as an idle worker). Keep the Worker running on each node; it will typically run in a console or as a service in the background. Workers regularly poll the Manager for tasks.

5. Install Flamenco Add-on in Blender: On your main Blender workstation, install the Flamenco add-on (it might be provided in the Flamenco download or accessible via the Manager's web interface, e.g. a flamenco3-addon.zip link). Enable it in Blender's Add-ons preferences (it's usually listed under the System category as "Flamenco"). In the Flamenco add-on settings, point it to your Flamenco Manager's URL (for a local manager, something like http://<ManagerIP>:8080). Click the "Refresh" or "Connect" button - Blender should then connect to the Manager and retrieve the configuration (like available job types and the storage path). If it doesn't connect, double-check the URL or any firewall that might block access.

The farm is now running: the Manager coordinates, Workers sit online waiting for jobs, and your Blender is linked through the add-on. Flamenco also supports custom job types, which you can script for tasks other than rendering, though this guide sticks to the standard render job.

Distributed rendering: running a job on the farm

The procedure differs depending on which tool you set up, so here's each.

Rendering with CrowdRender

CrowdRender hooks into Blender's normal render process, so there's not much new to learn:

1. Open your scene on the master machine: On your main PC (the one where you set up the CrowdRender connections), load up the Blender project you want to render. Double-check that all external data is packed or accessible (as per the preparation steps). Ensure CrowdRender is still enabled and your render nodes are showing as connected in the add-on panel.

2. Select render nodes: In the CrowdRender panel, you'll see all the connected machines (including "This Machine"). You can toggle which ones are active for the upcoming render. For example, you might choose to exclude the master from rendering if you want to keep it free for other tasks (then only the slave nodes will render), or include it to add its power. Make sure all desired nodes are checked/active. CrowdRender handles balancing automatically, but note that if one node is significantly slower, it could become the slow point for single-frame renders (because for a still image, the slowest tile determines when the whole image is done). For animations, it's less of an issue as each node will render different frames - faster nodes just get through more frames.

3. Start the render: use Blender as you normally would, Render → Render Animation (Ctrl+F12) or Render → Render Image (F12). CrowdRender intercepts the render and distributes it:

   • For animations: frames get allocated across machines. A 100-frame animation with 5 nodes might go out as 20 frames each, or get distributed on the fly as nodes finish. Each node renders its frames and sends the images back to the master, which assembles them as if it had rendered them locally. Total time scales close to linearly with the number of machines, minus network transfer overhead.
   • For a single still: CrowdRender splits the image into tiles and sends each to a different node, then merges them back in your session. A 1920×1080 image might go out as 4 tiles to 4 nodes. One caveat: denoising and some compositing operations don't merge cleanly across tile boundaries, so you can end up with visible seams. Disable denoising for the tiled render and denoise the final image afterward, or increase tile overlap if your version supports it.

4. Monitor progress: As the distributed render runs, you can watch progress in Blender's status bar or render window. CrowdRender also provides a status in its panel (e.g., showing which frame each node is on, or how tiles are progressing). If a node finishes its task, it may automatically take on another frame (for animations) until all frames are done. If any node disconnects or errors out, those frames will typically be requeued to another node or the master, so your render completes - albeit slower if a node dropped. You'll see messages if a node wasn't reachable, etc., which you can troubleshoot after.

5. Retrieve output: the frames land in the output directory you set, on the master if you left it at the default, and CrowdRender transfers them back automatically. Open a few frames from different nodes and compare: lighting and shading should be identical, since each node runs Blender's own renderer on the same data. If they aren't, a node has a different Blender version or a missing asset.

Day to day, that's the whole workflow: connect nodes, hit render.

Rendering with Flamenco

With Flamenco you submit a job to the Manager, which dispatches it to Workers. Less immediate than CrowdRender's one-click approach, but you get a queue and a web interface to manage it.

1. Open the project and connect the Flamenco add-on: Open your Blender scene on your workstation (which has the Flamenco add-on enabled and connected to the Manager as set up earlier). In the Properties editor, go to the Scene tab (or look for a Flamenco panel - the UI may vary, but often Flamenco provides a panel in the render settings or a separate sidebar). Make sure the add-on is showing as connected (it might display the Manager URL and a status). If not, go into Preferences and reconnect as described before.

2. Configure the render job in Blender: Flamenco uses the concept of "Job Types." Typically, for a straightforward render, you'll use the built-in Simple Blender Render job type (this is provided by Flamenco by default). In the Flamenco panel, there should be a dropdown or list to select the job type. Click a "Fetch job types" or refresh button if needed to retrieve the list from the Manager. Choose Simple Blender Render. This job type basically tells the workers to open the .blend and render frames.

   • After selecting the job type, you'll need to specify some parameters: namely the frame range to render, chunk size, and output path. For example, you can set Frame Start and End (or if you only want a single frame, set start=end to that frame). Chunk size determines how many frames each task will contain - for instance, a chunk size of 1 means each task is one frame (ideal when you have many workers so they can evenly divide frames). A larger chunk (e.g. 5) means each task will render 5 frames sequentially on one worker before moving to the next task. Smaller chunks give better load balancing for many nodes, whereas larger chunks reduce overhead if you have very few nodes. For most cases, chunk = 1 or 2 is fine. Also verify the Output path - by default it may use whatever is set in the Blender scene output. If using a shared storage, ensure the output directory is within that shared folder (so workers can write to it). If you're rendering a single image using Flamenco, the approach might differ - you could still use Simple Blender Render for one frame, or use a specialized tile rendering job type if available (Flamenco can be scripted for tile rendering, but that's beyond scope; by default, it might just have each worker render the whole image which isn't useful unless you use only one worker for that job).

3. Submit the job: Double-check everything (correct frame range, output path, etc.), then hit the Submit to Flamenco button in the add-on UI. Blender will package the job and send it to the Flamenco Manager. What happens next is largely automatic: the Manager receives the instructions and the Blender file. The Flamenco add-on/Manager will upload the .blend file to the shared storage for the workers to access. It will then queue tasks for the frame range. Almost immediately, your Worker nodes will pick up those tasks (the Manager assigns them to free workers). Each Worker Blender (running in background on those machines) will load the scene and render its assigned frames.

4. Monitor the render: You can monitor progress in a couple of ways. The Flamenco Manager has a web interface (if you open the Manager's URL in a browser, you should see a dashboard). There you can see the job, a list of tasks (frames) and which worker is rendering each, and their status (running, completed, etc.) in real-time. The Blender Flamenco add-on may also update with progress (for example, it might list how many frames done, or you might need to hit refresh). Additionally, each Worker running will log output to its console - if you peek at a Worker's window you can see Blender's usual render log lines for frames. Flamenco will also handle if a worker fails or a task errors: it can requeue failed frames to another worker. Keep an eye out for any error messages in the Flamenco interface - if, say, a worker couldn't access a file, those will be reported.

5. Completion and retrieval: Once all frames are rendered, the job will be marked as completed in Flamenco. Your output frames will be available in the designated output folder (on the shared storage or wherever you pointed it). If you were rendering to a multi-user network location, you can now collect those frames for editing. If you used a single-machine output path, note that since each worker wrote directly to it (via the share), the files should all be there. Verify that all expected frames are present. It's a good idea to open a few frames (from different workers) to ensure they rendered correctly and consistently - with Flamenco, since all nodes are running the same Blender version and reading the same data, the results should be identical to a single-machine render. If any frames are missing or incomplete, you can always requeue just those frames as a new Flamenco job (one of the benefits of a render manager is that you can easily rerun specific tasks).

6. Managing multiple jobs: you can queue several. Submit another scene or camera angle while the first job renders, and the Manager either runs them in parallel if workers are free or queues them behind the current work. Prioritizing and cancelling happen in the web interface. Queuing more than your worker count can handle doesn't make anything faster, it just makes the order explicit.

Flamenco is the same system Blender Studio uses internally, so it handles complex scenes and long frame counts without complaint. For a two-machine home farm it's probably more than you need, but it's the right answer once you're managing a real queue.

Tips for optimizing your render farm

• Keep software in sync: As emphasized, always keep all nodes on the same Blender version and update the CrowdRender or Flamenco software together. When Blender releases updates (e.g., 5.1, etc.), check that your render farm tools support it before upgrading everything. (CrowdRender often announces support for new Blender versions quickly, and Flamenco being official will track Blender updates as well.)

• Balance CPU and GPU usage: If some nodes don't have a strong GPU, consider using them for CPU rendering tasks (for example, they can still contribute to animations by rendering frames on CPU). CrowdRender allows mixing devices - each node will use whatever Blender is set to. You could dedicate GPU-equipped machines to do the heavy lifting and leave CPU-only machines to handle lighter frames or assist if GPUs are busy. In Flamenco, you might register some workers as "GPU" and others as "CPU" and manually assign jobs or frame chunks accordingly (or run separate jobs for CPU if needed).

• Network throughput: the network becomes a bottleneck when you're constantly moving large files. CrowdRender sends scene data once up front, then only small updates if you tweak the scene, and compresses frame data on the way back. If renders stall at the end of each frame waiting on transfers, enable image compression or reduce tile size so each transfer is smaller. A Gigabit network handles a few hundred MB per second, which is usually fine unless your frames are 4K multi-layer EXRs.

• Monitoring and temperature: render nodes crash from thermal problems and GPU driver timeouts under sustained load more often than from anything Blender does. Check cooling, clear dust, and log temperatures and GPU utilization so you catch a failing node before it eats a job. Enabling Blender's Auto Save for renders, or splitting long sequences into chunks, limits what you lose when one does crash.

• Security and permissions: on a home LAN you're fine. If your farm spans networks or includes rented cloud machines, link them over a VPN (WireGuard works well) rather than exposing Flamenco's ports or an open Blender instance to the internet. Use real passwords on shared storage, and in a studio, restrict who can submit jobs.

• Cost vs. benefit: a local farm costs you electricity and hardware wear. Nodes at 100% draw serious wattage, so the running cost isn't zero, but for regular rendering it still beats paying per frame. The calculus flips for occasional large jobs, where a cloud burst avoids buying hardware that then sits idle.

• Scalability: both tools grow past a handful of machines. Adding a PC means installing the same setup and joining it to the farm. CrowdRender's peer-to-peer design is comfortable with a dozen or so nodes; Flamenco runs professional pipelines with dozens to hundreds of workers.

• Testing and benchmarks: run a known scene through the farm before you trust it with real work. Render a few frames of Blender's Classroom demo with and without the farm and compare. It surfaces misconfigured nodes while the stakes are low.

Conclusion

You should now have a working farm: CrowdRender if you wanted something running this afternoon, Flamenco if you wanted a queue you can manage. Each node contributes to the output, either by rendering separate frames of an animation or tiles of a single image.

Animations are the case where this pays off most, because frames are independent and the speedup is close to linear in the number of machines. That holds for both Cycles and EEVEE. Single stills benefit less, and tiled rendering brings its own seam problems with denoising, as noted above.

Two things worth repeating, because they cause most of the failures people hit: every node needs the same Blender version, and every node needs to actually reach the assets. Nearly every "why does this frame look different" problem traces back to one of those two.

And if a deadline outgrows what you have, the cloud is a complement rather than a replacement. Our own service, RenderDay, exists for that case: render previews and tests locally, send the final high-res frames out when the clock is against you.