Containerized ComfyUI with ROCm 10 on the Minisforum N5 Pro Running TrueNAS

If you have a Minisforum N5 Pro running TrueNAS, there’s a good chance you’ve got a surprisingly capable AI accelerator sitting in your rack that you’re not doing much with.

The N5 Pro’s AMD Ryzen AI 9 HX PRO 370 includes a Radeon 890M integrated GPU. AMD identifies the 890M as an RDNA 3.5 gfx1150 GPU, and ROCm 10 now provides native support for it. After spending some quality time figuring out the right combination of TrueNAS, Docker, ROCm, PyTorch, and the 890M, I’ve got an updated ComfyUI setup with ROCm 10 support that takes only minutes to get up and running - outside a 20 GB download.

  %%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#dbe247',
    'primaryTextColor': '#222222',
    'primaryBorderColor': '#222222',
    'lineColor': '#222222',
    'secondaryColor': '#dbe247',
    'tertiaryColor': '#dbe247'
  }
}}%%
flowchart LR
    N5["Minisforum N5 Pro"]
    
    subgraph HOST["TrueNAS SCALE"]
        K["Linux Kernel<br/>amdgpu + KFD"]
        D["Docker"]
    end
    
    subgraph CONTAINER["ComfyUI Container"]
        R["ROCm 10.0"]
        P["PyTorch 2.13/Python 3.13"]
        C["ComfyUI"]
    end
    
    GPU["Radeon 890M<br/>gfx1150"]

    N5 --> HOST
    K --> GPU
    K --> D
    D --> CONTAINER
    R --> P
    P --> C
    GPU <--> R

The system has an integrated GPU; 890M doesn’t have a discrete pool of VRAM like a Radeon or NVIDIA card sitting in a PCIe slot. ROCm exposes a large portion of the system’s shared memory to the GPU. On my system, ComfyUI reports approximately 30 GB of GPU-visible memory and that’s considerably more interesting than the phrase “integrated graphics” might suggest.

First things first: update TrueNAS

If you’re running an older 25.10 release, update TrueNAS before continuing. I originally tested this on TrueNAS 25.10.3, which shipped with Linux 6.12.33. TrueNAS 25.10.7 updates the kernel to 6.12.105, and that’s important.

With the older kernel, ROCm could see and correctly identify the GPU, initialize PyTorch, and report the expected GPU memory, but the first CPU-to-GPU tensor transfer failed:

1
2

CUDA error: invalid argument
hipErrorInvalidValue

After updating TrueNAS, the same ROCm 10 container successfully transferred tensors to the GPU and ComfyUI could actually generate images. If you’re sitting there wondering why ROCm can see your 890M but ComfyUI won’t actually do anything: Update TrueNAS first. As of this post, TrueNAS 25.10.7 is the current 25.10 maintenance release.

Let Docker do the heavy lifting

I built the environment around AMD’s ROCm/PyTorch container rather than trying to install the entire ROCm stack directly into TrueNAS. Nobody should have a TrueNAS installation with manually installed GPU libraries floating around the place. Instead, the host provides the GPU device interfaces and the ROCm/PyTorch userspace lives inside the container.

1
2
3

devices:
  - /dev/kfd:/dev/kfd
  - /dev/dri:/dev/dri

Keep TrueNAS clean; make a mess of everything else. The result is a clean separation of duties between the system and Docker host.

The Docker image

The base image is: rocm/pytorch:rocm10.0_ubuntu24.04_py3.13_pytorch_release_2.13.0 From there, the Dockerfile installs the basic tooling, clones ComfyUI, installs its requirements, and leaves the models and configuration outside the image.

The complete Dockerfile and Compose configuration are available here: comfyui-rocm-n5pro The repository’s main branch contains the ROCm 10 configuration. I’ve also preserved the previous ROCm 7.x implementation in a separate branch for reference and fallback purposes.

Don’t use a GFX override

You’ll find various guides for AMD APUs recommending something along the lines of HSA_OVERRIDE_GFX_VERSION=11.5.0.

Don’t automatically do that here. The Radeon 890M is natively recognized as gfx1150. ROCm 10 has native support for that architecture. AMD’s current ROCm documentation explicitly lists the Radeon 890M among the supported AMD APUs and identifies it as gfx1150, so there’s no reason to pretend the GPU is something else when the current ROCm stack knows exactly what it is.

Docker Compose

The Compose configuration exposes the GPU and maps ComfyUI to port 8188:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

services:
  comfyui:
    container_name: comfyui

    image: comfy-rocm10:0.1

    devices:
      - /dev/kfd:/dev/kfd
      - /dev/dri:/dev/dri

    environment:
      HIP_VISIBLE_DEVICES: '0'
      HSA_ENABLE_SDMA: '0'
      MODEL_DOWNLOAD: none
      ROC_ENABLE_PRE_VEGA: '0'

    group_add:
      - video

    healthcheck:
      interval: 30s
      retries: 3
      start_period: 30s
      test:
        - CMD
        - curl
        - '-f'
        - http://localhost:8188/
      timeout: 10s

    ports:
      - '8188:8188'

    restart: unless-stopped

    security_opt:
      - seccomp:unconfined

    shm_size: 16g

    volumes:
      - /mnt/Storage/apps/comfyui/user:/workspace/ComfyUI/user
      - /mnt/Storage/apps/comfyui/models:/workspace/ComfyUI/models
      - /mnt/Storage/apps/comfyui/output:/workspace/ComfyUI/output
      - /mnt/Storage/apps/comfyui/input:/workspace/ComfyUI/input
      - /mnt/Storage/apps/comfyui/custom_nodes:/workspace/ComfyUI/custom_nodes

The rest of the configuration - including the persistent volume mappings - is in the repository. Once your setup is running as expected, you can use the same YAML to set up a custom application in the TrueNAS UI. For now, just get things up and running via a Shell session.

Getting up and running

Clone the repository:

1
2

git clone https://github.com/Foundry81/comfyui-rocm-n5pro.git
cd comfyui-rocm-n5pro

Then:

1

docker compose build

Or, for a completely clean build:

1

docker compose build --no-cache

Be patient - the ROCm/PyTorch base image is very large. The first build downloads roughly 20 GB of ROCm/PyTorch layers so the image may take a while to build.

Once the image is built:

1

docker compose up -d

Then:

1

docker compose logs -f

ComfyUI should eventually report something along the lines of:

1
2
3

AMD arch: gfx1150
ROCm version: ...
Device: cuda:0 AMD Radeon 890M Graphics

The HIP runtime version reported by ComfyUI isn’t necessarily the same thing as the ROCm version in the base image, so don’t panic if those numbers don’t look identical.

Test the GPU before blaming ComfyUI

This is probably the most useful troubleshooting trick in the entire project. Before debugging workflows, models, LoRAs, custom nodes, attention implementations, or anything else, test whether PyTorch can actually move memory to the GPU.

  %%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#dbe247',
    'primaryTextColor': '#222222',
    'primaryBorderColor': '#222222',
    'lineColor': '#222222',
    'secondaryColor': '#dbe247',
    'tertiaryColor': '#dbe247'
  }
}}%%
flowchart LR
    A["ComfyUI workflow"] --> B["PyTorch"]
    B --> C["ROCm / HIP"]
    C --> D["amdgpu / KFD"]
    D --> E["Radeon 890M"]

    T["CPU → GPU tensor test"] -.-> C

    X["If this fails,<br/>don't debug ComfyUI yet"] -.-> T

Run:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

docker compose run --rm \
  --entrypoint /opt/venv/bin/python \
  comfyui -c "
import torch

print('Torch:', torch.__version__)
print('HIP:', torch.version.hip)
print('Device:', torch.cuda.get_device_name(0))

x = torch.randn((1024, 1024), dtype=torch.float32)
print('CPU tensor created')

y = x.to('cuda')
torch.cuda.synchronize()

print('CPU -> GPU transfer: SUCCESS')
print('GPU tensor:', y.device)
print('GPU memory:', torch.cuda.memory_allocated() / 1024**2, 'MB')
"

You want to see:

1
2
3
4

Torch: 2.13.0+rocm10.0.0
Device: AMD Radeon 890M Graphics
CPU tensor created
CPU -> GPU transfer: SUCCESS

If that works, you’ve established that the basic ROCm → PyTorch → GPU memory path is functional, and it’s time to start troubleshooting ComfyUI. If it doesn’t work, don’t waste your time rebuilding ComfyUI workflows. The problem is below ComfyUI.

Models and LoRAs

The container keeps the important ComfyUI directories on the TrueNAS file system.

Your checkpoints, VAEs, LoRAs, ControlNets, custom nodes, inputs, outputs, and ComfyUI user configuration all survive container rebuilds. The Compose file maps these directories outside the containers so the Docker image can remain disposable. This comes in handy if you’re swapping out ROCm versions and tuning your setup, allowing you to throw away containers without potentially losing several hundred gigabytes of models.

Low-power local AI FTW

The N5 Pro isn’t going to replace a high-end discrete GPU for serious AI workloads, but a compact AMD APU with a large shared memory pool, sitting in a TrueNAS box you already own, can make for a surprisingly capable local image-generation setup without making your power bill enemy number one.

Subjectively, the new ROCm 10 environment feels better than my previous ROCm 7.x setup. I didn’t run any before/after tests or have any metrics to support that statement - the work wasn’t about performance. An up-to-date system was more important than achieving performance gains. I am seeing a decrease in iteration/second times of ~10it/s instead of ~14it/s though, and that’s a nice bonus.

If you have an N5 Pro sitting around running TrueNAS, this is the configuration I’d start with. The complete Dockerfile and Compose configuration are available in the GitHub repository:

https://github.com/Foundry81/comfyui-rocm-n5pro

Go make your NAS generate some stupid pictures.