Docker

Docker

The image ships with every external tool already installed, MKVToolNix, MediaInfo and an FFmpeg 9 stable GPL build, and sets LANG=C.UTF-8. This is the least fiddly way to run RemuxForge on a server or NAS.

Only the WebUI is containerised. REMUXFORGE_PORT=5000 and REMUXFORGE_DATA_DIR=/data are baked into the image as defaults.

Basic run

docker run -d \
  --name remuxforge \
  -p 5000:5000 \
  -e REMUXFORGE_DATA_DIR=/data \
  -v /path/to/config:/data:rw \
  -v /path/to/media:/media:rw \
  draknodd/remuxforge:latest

Open http://localhost:5000.

Docker Compose

services:
  remuxforge:
    image: draknodd/remuxforge:latest
    container_name: remuxforge
    restart: unless-stopped
    user: "1000:1000"
    ports:
      - "5000:5000"
    environment:
      - REMUXFORGE_PORT=5000
      - REMUXFORGE_DATA_DIR=/data
    volumes:
      - /path/to/config:/data:rw
      - /path/to/media:/media:rw

Path mapping

The file browser in the WebUI, and every path you type into a configuration field, is resolved inside the container. Host paths do not exist there.

With the mount above, -v /mnt/tank/media:/media:

On your host	Type this in RemuxForge
/mnt/tank/media/Series.ENG	/media/Series.ENG
/mnt/tank/media/Series.ITA	/media/Series.ITA
/mnt/tank/media/out	/media/out

If a scan reports zero files on a path that exists on the host, this is the usual cause. Use the [ .. ] browse button rather than typing paths: it lists only what the container can see, so the error is visible immediately.

Source and destination in Remux mode, and input and output in Metadata mode, must both be reachable inside the container. A single -v /mnt/tank:/media covers both with one mount and allows files to be moved between them.

File ownership and permissions

RemuxForge writes output files, and by default the container runs as root, so outputs end up owned by root on the host.

Set user: to your own UID/GID so new files are owned by you:

id -u   # e.g. 1000
id -g   # e.g. 1000

user: "1000:1000"

That user must have read/write access to every mounted path. Including /data, which is written on first launch. If the container exits immediately or the log complains it cannot save settings, /data ownership is the first thing to check:

sudo chown -R 1000:1000 /path/to/config

Remux mode's Overwrite source and Metadata mode's Overwrite need write access to the media mount, not just read. Mount it :rw if you intend to use them; mount it :ro if you want a hard guarantee that originals cannot be touched.

Environment variables

Variable	Description	Default in the image
REMUXFORGE_PORT	WebUI HTTP port inside the container	5000
REMUXFORGE_DATA_DIR	Parent directory for .remux-forge	/data
REMUXFORGE_LOG_FILE	Write a log file to this path	disabled

To publish on a different host port, remap rather than changing the internal port: -p 8080:5000.

Point REMUXFORGE_LOG_FILE inside a mounted volume (for example /data/remuxforge.log) if you want the log to survive container restarts.

GPU acceleration for analysis

GPU acceleration has two independent mechanisms:

Control	Work moved to the GPU
Hardware Acceleration	FFmpeg video decoding during analysis
Analysis ▸ Vision backend = Vulkan	geometry SIFT/RANSAC, Deep-analysis dHash computation and Speed-correction visual matching

Encoding profiles always use the software encoders (libx264, libx265, libsvtav1). GPU settings have no effect on a plain remux.

The image contains the Vulkan loader and Mesa ICDs. The host must still expose a compatible GPU and its driver to the Linux container. Visual compute uses the CPU by default and Vulkan is enabled only after the settings dialog successfully probes the device.

NVIDIA: install the NVIDIA Container Toolkit on the host, then:

docker run -d \
  --name remuxforge \
  --gpus all \
  -e NVIDIA_DRIVER_CAPABILITIES=compute,utility,video,graphics \
  -p 5000:5000 \
  -e REMUXFORGE_DATA_DIR=/data \
  -v /path/to/config:/data:rw \
  -v /path/to/media:/media:rw \
  draknodd/remuxforge:latest

graphics is required for Vulkan; video is required for ffmpeg hardware decode.

Intel / AMD (VAAPI and Mesa Vulkan): pass the render device through:

docker run -d \
  --name remuxforge \
  --device /dev/dri:/dev/dri \
  -p 5000:5000 \
  -e REMUXFORGE_DATA_DIR=/data \
  -v /path/to/config:/data:rw \
  -v /path/to/media:/media:rw \
  draknodd/remuxforge:latest

After the container starts, configure the mechanisms independently:

• enable Settings ▸ Advanced settings ▸ Analysis ▸ Hardware Acceleration and select a probed FFmpeg method for GPU decode;
• select Settings ▸ Advanced settings ▸ Analysis ▸ Vision backend ▸ Vulkan for GPU visual compute.

Passing the device through is not enough on its own. Selecting Vulkan performs an immediate runtime/device probe and keeps CPU selected if the probe fails.

GPU passthrough described here targets Docker Engine on a Linux host. Docker Desktop on macOS does not expose the host Metal GPU as a Vulkan device to this Linux container; use the native macOS build with MoltenVK for Vulkan visual compute.

Verifying the image

docker exec remuxforge mkvmerge --version
docker exec remuxforge ffmpeg -version
docker exec remuxforge mediainfo --version

All three should answer. Then confirm in the app under Settings ▸ Tool paths that everything reads [OK].

Updating

docker compose pull
docker compose up -d

Your settings and presets live in the /data volume and survive the replacement.

Next

• WebUI Basics: the interface, menus and keyboard shortcuts
• Troubleshooting: scan finds nothing, permission denied on output