Flame 2026.2 Project Server / Shared Storage Architecture Question + UI Freezes

Sysadmins
1

Flame 2026.2 Project Server / Shared Storage Architecture Question + UI Freezes

I’m looking for a sanity check on our Flame 2026.2 Project Server deployment, as we’re experiencing intermittent UI freezes and I’m trying to determine whether our storage architecture could be a contributing factor.

Environment

  • Flame 2026.2.x
  • Dedicated Project Server VM
  • Multiple Linux Flame workstations
  • Shared network storage (GPFS backend)
  • All Flame workstations access the storage directly
  • Project Server accesses the same storage via NFS
  • All systems see the storage at the same paths

Current Setup

All project data, setups and media caches are stored on shared network storage.

The Flame workstations access this storage directly, while the Project Server accesses the same storage via NFS. However, the mount paths are identical on every machine.

For example:

/mmfs1/projects/…

exists on every workstation and on the Project Server.

The Project Server is only hosting:

  • PostgreSQL
  • Stone & Wire services
  • Backburner Manager

Project Homes and Media Caches are not stored locally on the Project Server.

Project Configuration

According to the Flame 2026 documentation, project sharing should work provided the Project Home and Media Cache paths are reachable and identical across all participating systems.

The Autodesk examples show:

Project Home

/mnt/HOSTNAME/projects/

/mnt/HOSTNAME/media

In our environment we use our existing storage structure, for example:

Project Home

/mmfs1/projects//…/flame/projects/

Media Cache

/mmfs1/projects//…/flame/media/

The paths are accessible from:

  • All Flame workstations
  • The Project Server

and are identical on every system.

Questions

  1. Is this considered a supported and sensible Project Server architecture for Flame 2026.2?

    In other words:

    PostgreSQL = local to Project Server

    Project Home = shared storage

    Media Cache = shared storage

    Setups = shared storage

  2. Is there any known issue with the Project Server accessing the storage via NFS while the Flame workstations access the same storage directly, assuming the paths remain identical everywhere?

  3. Has anyone experienced intermittent UI freezes or pauses with a similar Project Server setup and, if so, what was the root cause?

The freezes are not always associated with playback, rendering or heavy media operations. They can occur during normal project navigation and general UI use, which is why I’m trying to understand whether the architecture itself could be a factor or whether I should be looking elsewhere.

One of my current theories is that the freezes may be related to project metadata operations rather than media throughput. The behaviour feels more like Flame is waiting on a database transaction, autosave activity, or another metadata-related operation to complete rather than struggling with media playback or storage bandwidth.

Given that PostgreSQL is hosted on the Project Server while the project data resides on shared storage, I’m particularly interested to hear from anyone who has experienced delays, lockups or UI pauses caused by database connectivity, autosave processes, project catalog updates, or metadata synchronisation issues in a similar environment.

Any feedback from facilities running Flame 2026.2 with a Project Server and shared storage would be greatly appreciated.

2

yes, I had to go away from any sort of centralized storage for matchboxes / onnx tools e.t.c and i am now rsyncing these to users machines that seems to have helped a lot.

the other stuff, we had many many corrupted projects and general slowness issues especially in 2026, we are cautiously using 2027 but its all over much slower

on 2025 it wasnt a problem.

we are waiting fo a proper implementation of postgresDB without the file-based stuff as the current implementation is half baked and problematic to me at least..

3

:infinity:

4

Thanks, that’s really interesting feedback.

Just to clarify, when you mention moving Matchboxes and ONNX tools away from centralised storage and rsyncing them locally, were those resources actually being hosted from shared storage rather than each workstation’s local /opt/Autodesk installation?

In our environment, the Autodesk installation itself (including Matchboxes and ONNX models, as far as I’m aware) remains local to each workstation, with only the Project Home, Media Cache and project data residing on shared storage.

Unfortunately we’re having to adopt Flame 2026+ as we’ve recently invested in new HP Z8 G5 systems with RTX PRO 6000 Blackwell GPUs. As I understand it, Blackwell support is only available in Flame 2026 and newer, so staying on 2025 wasn’t really an option for us, even though that would certainly have made my life a lot easier!

Did you ever manage to identify a specific root cause for the corruption and slowness issues you were seeing, or was it more of a general problem with the 2026 project architecture?