How to Set Up a Blender Flamenco Render Farm: Manager and Worker Settings

What you’ll learn in this guide

Blender Flamenco provides a workflow for distributing render jobs among Manager and Worker components. This guide walks through the roles of the Manager and Worker configuration files, how to set a shared storage path, and which types of jobs Workers can take on. It also covers what the Blender render command does and what to check during configuration.

The Manager handles jobs, while Workers execute tasks. Job and task statuses are tracked separately; for example, a job can be marked complete once all its tasks finish successfully. Flamenco commands include Blender rendering, converting an image sequence to video with FFmpeg, and file-management operations.

Requirements and configuration files

The official guides do not specify a particular Blender version, installation package, account requirement, or license fee. For that reason, this guide does not assume any specific software version or hardware requirements. The examples assume you have a Flamenco environment where you can edit Manager and Worker configurations and set up shared storage.

The Manager reads its settings from flamenco-manager.yaml. This file is located next to the flamenco-manager executable. When the Manager is started for the first time, the setup wizard opens if the file is missing. A Worker reads its main settings from flamenco-worker.yaml in its working directory. Multiple Workers can share this main file, but each Worker has its own credentials and task-update database.

Configure the Manager and Worker

1. Create the Manager file. Use the setup wizard on first launch. If you need to create the file manually, the example below shows the basic settings:

_meta:
  version: 3
manager_name: Flamenco Manager
database: flamenco-manager.sqlite
listen: ":8080"
autodiscoverable: true
local_manager_storage_path: ./flamenco-manager-storage
shared_storage_path: /path/to/storage
shaman:
  enabled: true
  garbageCollect:
    period: 24h
    maxAge: 744h

manager_name sets the Manager’s name, while database specifies the path to the SQLite database file. The listen setting defines the IP address and port on which the Manager accepts connections. The official documentation says this address is used by the web interface, API, and Shaman for file transfers, and that it is the only port required for the Manager. autodiscoverable determines whether Workers on the same network can discover the Manager automatically.

Use local_manager_storage_path for local Manager files and shared_storage_path for jobs and outputs that the Manager and Workers need to access. Replace /path/to/storage in the example with the shared location used in your environment. The Shaman storage system is optional; the example enables it and shows the file-cleanup intervals.

1. Set the Worker connection and task scope. In the Worker’s shared configuration file, you can specify the Manager address and the types of tasks it can accept:

manager_url: http://flamenco.local:8080/
task_types: [blender, ffmpeg, file-management, misc]
restart_exit_code: 47

If manager_url is empty or removed, the Worker will try to discover the Manager over the network. task_types limits which tasks can be assigned to the Worker. The list in the example includes the types used by the default job compiler scripts; if your own job compiler scripts produce different types, check that they match this setting. A nonzero restart_exit_code marks the Worker as restartable.

1. Keep Worker-specific files separate. Each Worker has a credentials file named flamenco-worker-credentials.yaml and a flamenco-worker.sqlite database that queues task updates when the Manager is unreachable. These are separate from the main configuration file and are not intended to be edited manually. The default locations listed in the guide are $HOME/.local/share/flamenco on Linux, C:\Users\UserName\AppData\Local\Blender Foundation\Flamenco on Windows, and $HOME/Library/Application Support/Flamenco on macOS.

2. Track a Blender job. Blender render tasks are executed with the blender-render command. It uses the Blender executable, the .blend file to open, and additional arguments supplied by the job compiler script. If the executable is set to blender, the Worker searches for the program; on Windows, it can also use the .blend file association. During rendering, images are sent by the Worker so they can be shown as previews on the Manager side.

Jobs and tasks are tracked with different statuses. Queued tasks can be assigned to eligible Workers; once all tasks succeed, the job is marked complete. If a task also fails after being retried on different Workers, the job may be marked as failed. Requeuing a completed job queues all its tasks again, while requeuing a job with unfinished tasks queues only those tasks.

Impact on architecture, interiors, and archviz workflows

Architecture firms and visualization teams using Blender can distribute render tasks by adding multiple Workers to the same workflow. Limiting task types for each Worker helps determine whether a machine handles Blender rendering, file management, or jobs such as FFmpeg. The documented options also include an FFmpeg command that converts an image sequence into a video for animation output.

File access and compatibility are especially important during setup. The .blend files and render outputs must be in shared storage accessible to the Manager and Workers. The task_types settings must also match the tasks produced by the job compiler scripts. The guide notes that repeated task failures may indicate that a job is too demanding for a Worker’s hardware, so tracking job failure statuses can be useful. Since the documentation does not specify hardware requirements, Blender version compatibility, or license costs, verify these separately for your environment.

Common issues

• Using the wrong storage path: The Manager’s local storage directory and shared storage serve different purposes. Set the shared location for job files and render outputs.

• Worker can’t pick up tasks: Check manager_url and task_types, as well as the task types produced by the job compiler scripts.

• Sharing Worker-specific files: Credentials and the task-update database are specific to each Worker; don’t confuse them with the main configuration file.

• Leaving an old record when resetting: To reset a Worker, shut it down, delete the relevant local files, and remove the old Worker record in the Manager web interface; then restart the Worker.

• Adding optional settings unnecessarily: MQTT configuration is not required. If you don’t know what it is for, it’s recommended that you leave it out of the configuration.

Next steps

Start by checking the basic configuration with one Manager and one Worker. Then confirm that job files are accessible from shared storage and that the Worker can accept the expected task types. If you need to convert an image sequence to video outside Blender, review the settings for the frames-to-video command. Linux users can also consider the optional oom_score_adjust setting; it is Linux-specific, accepts values from 0 to 1000, and was added in Flamenco v3.5.

Sources and license

This guide was adapted into Turkish from Flamenco’s official, openly licensed documentation on Manager configuration, Worker configuration, jobs, tasks, and commands.