This document explains how to enable collaboration between multiple Flame Family workstations on a single local network. It also explains the roles the different components of the Flame ecosystem play and how to configure them for a smooth deployment.

The Flame Ecosystem

When you install Flame (or any Flame Family software) on a Linux or macOS station, several satellite components are also installed. These components can be categorized as Applications, Background Tasks, or Collaboration Services.

Applications

This category includes the Flame Family software and all the different tools and scripts that are used by the standalone application.

Background Tasks

This category consists of the background job manager (BackburnerManager), its servers (BackburnerServer), and the job-specific adapters (BackgroundReactor, Wire, MediaConverter, Burn, etc.). The main application uses these services to offload tasks that do not require user interaction, like rendering, caching, or transcoding.

Collaboration Services

This category consists of the services that make it possible for a remote Flame to work on a local project or enable your Flame to work on a remote project. Most of these services are part of the Flame distribution, but other services essential to collaboration are provided by the operating system.

Services installed as part of the Flame Family distribution:

• The Flame PostgreSQL server manages the project media caches. This component was introduced in 2026 as a replacement for the Stone+Wire database, offering greater flexibility, improved extensibility, and addressing some limitations of the volume-based storage management.
• The sw_stone daemon provides discoverability of project hosts over the network using the DNS-SD protocol.
• The wiretapgateway daemon provides specialized media browsing, decoding, and encoding.
• DLmpd is the multi-purpose daemon that provides remote system call optimizations and some more specialized services like remote archives and integrity checking.
• The ifffsWiretapServer daemon provides Flame project access to standalone tools and a means of interoperability with other applications.

Services provided by the operating system:

• The NFS server provides local file system access to remote hosts and is used for NFS export.
• The automount daemon automates the mounting of remote NFS file systems and is used for NFS import.
• Avahi on Linux, and mDNSResponder (aka Bonjour) on macOS, provide service discovery using DNS-SD across the local network subnet.
• Your choice of identity management: collaboration works best if you set up a central authority for user identification and authorization such as FreeIPA or Active Directory. How you set this up is specific to your facility and goes beyond the scope of this document.

Setting Up Collaboration

The Flame installer program configures the system so that basic collaborative workflows can work between multiple Flame Family products on the same network. Every facility has its own particularities and you may have to tweak the configuration to meet your needs. Moreover, on the macOS platform, the installer may fail to appropriately configure the operating system depending on your security settings. This section covers the different components involved in a successful collaborative environment. Each subsection provides a list of the network ports used. This may come in handy if you want to configure a firewall. Consult Network Ports for a consolidated list. For a step-by-step guide for setting-up collaboration between independent Flame Family workstations without shared storage, see Project Sharing.

Workstation Identification

/opt/Autodesk/cfg/network.cfg contains a unique workstation identifier and the multicast configuration that enables automatic discovery of the services using the Wiretap protocol (wiretapgateway, ifffsWiretapServer, BackburnerManager). If your workstation uses a single network interface, you should only have to worry about the following settings in this file:

[ Local ] → UUID: This token uniquely identifies your host - no two workstations on your network can have the same UUID. You can generate a UUID with this command to be executed in a shell terminal. Note it will only generate a UUID if one is not already assigned.

/opt/Autodesk/cfg/.current/network.cfg.uuid

Service Discovery

The different services Flame relies upon for collaboration broadcast their presence using either the Wiretap service discovery or the DNS-SD standard protocol. This section shows the different parameters controlling these mechanisms.

Wiretap services have their own discovery mechanism. Each service acts as a hub that registers all the other wiretap services on the local network subnet.

/opt/Autodesk/cfg/network.cfg holds the wiretap-specific service discovery parameters used by Backburner, ifffsWiretapServer, and wiretapgateway:

[ Self Discovery ] → Port (7555): The network port over which all wiretap services notify each other of their presence on the network. The default is 7555 and unless it conflicts with another service, you should not have to change it.

[ Self Discovery ] → Scope (224.0.0.1): The multicast address used to broadcast information on the network. The default is 224.0.0.1 and identifies the local subnet. This is appropriate for a small network. If you have systems on multiple subnets, you must change the multicast scope. For example, on AWS, multicast across the AWS Transit Gateway does not work using 224.0.0.1, and you have to change the scope for 239.0.0.1.

[ Self Discovery ] → TTL (1): If the multicast traffic remains on the local network (single VLAN), the default Time-To-Live (TTL) value of 1 is adequate. If multicast packets must transit on different networks, the value should be increased. The TTL should be set as small as possible.

[ Dynamic Ports ] → LowerBound & UpperBound (49152-65535): Defines the range used for dynamically allocated network ports. It is sometimes necessary for a program to allocate an arbitrary port rather than a predetermined port. The wiretap services will pick such ports in the range defined here. Reducing the range increases the risk of port conflicts since no two programs can accept connections on the same port. A bigger range increases the attack surface of your system and, if you are configuring a firewall, forces you to open these ports if they must be accessible to remote hosts. The default range is the one defined by the operating systems. If your systems are running in an isolated local network, the default values are usually safe to use.

^* The range in this table differs from the defaults in the network.cfg file because it accounts for other services using dynamic ports that do not yet obey these settings. The upper bound is also constrained by the Linux setting, 60999, which is lower than the config file upper bound.

To be usable for multicasting, the network interface must have the MULTICAST flag enabled at the OS level. This can be validated and changed using the ifconfig or ip link commands. Enabling the 'MULTICAST' flag on the 'loopback' interface is recommended to help ensure discoverability of local services.

DNS-SD is the service discovery protocol used by Flame's PostgreSQL database (stone) and the Multi-Purpose Daemon (dlmpd). DNS-SD also uses multicast to broadcast service availability but, unlike the wiretap protocol, it has a per-host dedicated daemon for managing available services and responding to queries. This daemon is not part of Flame and is managed by the operating system. Refer to Linux' avahi documentation and macOS' mDNSResponder documentation for more details. Flame does provide the dl_services_map and dl_services_monitor tools to query or monitor its services with DNS-SD.

Service Discovery Without Multicast

Wiretap and DNS-SD rely on multicast to discover Flame Family-related services running on the local and remote hosts. Some network configurations or policies can prevent the use of multicast to discover them. In these circumstances, you can use /opt/Autodesk/cfg/services.cfg to manually expose these services.

The /opt/Autodesk/cfg/services_snapshot.sh script can be used to create a services.cfg that contains information from local services. To update the local /optAutodesk/cfg/services.cfg, you can run the command /opt/Autodesk/cfg/services_snapshot.sh without any arguments. This will scan the local services on their default ports and create the file.

To update this file with remote services, add to the command the IP or hostname of the host to scan for services. For example: /opt/Autodesk/cfg/services_snapshot.sh -h 192.168.0.14. The script will attempt to contact known services on host 192.168.0.14 and will add those that are reached to the local services.cfg file.

The script scans for Autodesk Flame network services on their default ports. If you have customized some if these port numbers, call the script for each port to scan with the -p argument. For example: /opt/Autodesk/cfg/services_snapshot.sh -h 192.168.0.14 -p 7654. The script will scan for all known services on port 7654. If one responds, it will be added to the local services.cfg file.

See /opt/Autodesk/cfg/services.cfg.samples for more details and examples.

I/O Priority Service

Real-time I/O tasks, such as playback, require minimal interruptions to storage access. The I/O Priority service ensures background tasks do not consume bandwidth needed by foreground applications during critical moments. The concept is straightforward: When a foreground application like Flame performs a real-time I/O task, it signals on the designated network port. Lower-priority applications connect to this port and pause their I/O operations until the foreground task is complete. This service used to be provided by the sw_probed daemon. As of version 2026, it is provided by the Flame Family main applications themselves.

ifffsWiretapServer Configuration

/opt/Autodesk/wiretap/cfg/wiretapd.cfg defines the two ports used to communicate with the ifffsWiretapServer.

[ Server ] → NodePort(7549): This port gives external tools (non-Flame) access to the projects on the host. Lustre and the MediaConverter Backburner adapter are two heavy users.

[ Server ] → FramePort(7550): This port is used to establish a media transfer connection with the daemon. Requests on the NodePort are small and frequent and must be responsive. The FramePort prevents large media requests from impacting the response time on the NodePort.

DLmpd Configuration

This daemon does not have a configuration file of its own but it will honor the environment variables set in /opt/Autodesk/cfg/env.cfg. One could, for instance, override the default port (7700) of this daemon by defining the CSF_TEST_PORT environment variable and assigning it the desired port number. Clients expect to connect to the daemon on the default port, so CSF_TEST_PORT must be defined with the same value as the server for all clients. This is rarely necessary, no popular service has been known to conflict with DLmpd.

NFS Configuration

Starting with version 2026, you can store your Flame project and its media anywhere, provided that all participating workstations or servers in a collaborative workgroup can access them through identical paths. On a system sharing storage with the workgroup, /etc/exports is used to declare shared folders and their NFS export options. The syntax is similar for macOS and Linux but the available options differ. Each folder can be exported to a restricted set of hosts with appropriate options. Refer to the exports(5) man page for details applicable to your environment. The project home folder must be exported with the sync option to ensure integrity of the project catalog files. This is normally the default. A media storage path will typically be exported with the async option to improve performance. For collaboration to work, it must include at least the entries listed in the following table. Multiple entries can be grouped by exporting only a common parent:

For example, a Flame workstation named flame1 storing its projects under /mnt/<host name>/projects/<project name> and its projects' media under /mnt/<host name>/media/<project name> could have the following /etc/exports:

/mnt/flame1/projects -rw
/mnt/flame1/media -rw,async

In this case, the setups path resides under /mnt/flame1/projects. It does not need to be explicitly exported.

Use the ServiceMonitor's "NFS imports/exports" diagnostic to verify the suitability of your exported mount points.

After modifying /etc/exports, make sure to apply your changes by running

NFS requires the following ports to be opened in the firewall:

Automount Configuration

/etc/auto.master (Linux) and /etc/auto_master (macOS) define the mount points and mappings to physical directories that automount will manage. For example, when creating a project on a remote server, Flame will use /hosts/<host name>/var/opt/Autodesk/flame/projects/<project name> as the project home. In addition to /var/opt/Autodesk/flame/projects being exported by the remote server, this assumes the -hosts mapping is applied to /hosts in the master automount configuration. The following entries must therefore be present:

^**: resvport is required to mount from a linux server on macOS.

After modifying /etc/auto.master or /etc/auto_master, make sure to apply your changes by running

Flame's PostgreSQL Configuration

A Flame project has two main components: a set of catalog files and a media database. As of 2026, the latter is managed using a PostgreSQL database. Depending on the level of security required at your facility, Flame supports two authentication modes: one is called trust authentication, the second is called certificate (or cert for short) authentication. trust is the simplest to deploy while cert offers stricter security and encrypted communication. Choosing the authentication that best suits your needs must be done before creating your database.

trust authentication: All connections to the database are made with a common, generic user. Communication with the server is not encrypted.

cert authentication: Each Flame user must have credentials in the database. Connections with the server are made with these credentials and communication with the server is encrypted. In this mode, all users store their own ssl key and ssl certificate in their home directory. Background jobs executing with their credentials, such as Burn rendering jobs, must have access to their key and certificate to connect with the project database. This is best accomplished if users have network accessible home directories. Be warned that network home directories are unreliable or prevent users from logging in on macOS since version 13 (Ventura) when System Integrity Protection (SIP) is enabled.

Database Deployment Options

A Flame installation comes with everything necessary to run a local database server but no database is created by default. You may opt to run a database server locally or deploy a central server that your Flame workstations will share. Flame's project selection menu shows all available servers in the host drop-down.

Refer to PostgreSQL Database for more details on this topic, and Database Creation for detailed, step-by-step instructions to create a database.

Host-based Access Control

The PostgreSQL server determines host access to the database using either the ~flame_db/flame_cert_hba.conf or ~flame_db/flame_trust_hba.conf file, based on the chosen authentication mode. The default trust configuration will allow any host. The default cert configuration will only allow hosts on the local subnet. You will need to modify the configuration if you have Flame Family clients on different subnets.

To edit the configuration, assuming environment variable EDITOR points to your editor of choice (for example, vi):

trust authentication:

sudo -u flame_db $EDITOR ~flame_db/flame_trust_hba.conf

cert authentication:

sudo -u flame_db $EDITOR ~flame_db/flame_cert_hba.conf

You must restart the server to apply changes to the configuration:

sudo -u flame_db -i /opt/Autodesk/bin/igniter --stop --start

Server Connection Limit

The PostgreSQL server allows 100 connections by default. If you run numerous clients, you may need to increase this limit. As a rule of thumb:

number of connections = 7 + (number of concurrent clients * 10)

A client is any Flame Family application that needs to open a project such as Flame, Flare, Flame Assist, Background Reactor, Burn, flame_archive, etc.

The limit's upper bound depends on the maximum number of files that can be opened. The connections share this limit with other open files. The upper bound is thus less than the maximum number of open files. Run ulimit -a | grep "open files" to see this limit e.g.

$ ulimit -a | grep "open files"
open files                          (-n) 8192

In this case, the upper bound for the maximum number of connections would be approximately 7000, leaving 1192 file descriptors available for other uses, which is a reasonable amount.

To change the limit, edit the ~flame_db/17/data/postgresql.conf file and change the max_connections setting:

sudo -u flame_db $EDITOR ~flame_db/17/data/postgresql.conf

For example:

max_connections = 300

You must restart the server to apply changes to the configuration:

sudo -u flame_db -i /opt/Autodesk/bin/igniter --stop --start