All apps · 0 apps
YA-WAMF
Docker app from Jellman86's Repository
Overview
Readme
View on GitHubUnraid
Install YA-WAMF on Unraid from a Docker template, so the container, ports, and paths are filled in for you and the web UI is one click away.
Outcome
YA-WAMF runs as a single Unraid Docker container, its config and data on
persistent appdata paths, reachable at http://<your-unraid-ip>:9852/.
Prerequisites
- A reachable Frigate instance publishing events over MQTT — YA-WAMF is driven by Frigate events and does nothing useful without them. See Frigate and MQTT Broker.
- Somewhere to store appdata (the default is
/mnt/user/appdata/ya-wamf).
YA-WAMF's UI and API are administrative surfaces. If you expose them outside your LAN, put them behind an authenticated reverse proxy — see Reverse Proxy and Authentication & Access.
Install with the template
Community Applications
In Apps, search for YA-WAMF, confirm that the repository is
ghcr.io/jellman86/yawamf-monalithic, and select Install. The listing provides
the template, app icon and project/support links.
Manual template import
If the listing is unavailable, save the published template locally. The Docker → Add Container → Template control selects local templates; it does not accept a remote URL. From the Unraid terminal:
install -d /boot/config/plugins/dockerMan/templates-user
template=/boot/config/plugins/dockerMan/templates-user/my-YA-WAMF.xml
test ! -e "$template" &&
curl -fL --output /tmp/yawamf-template.xml \
https://raw.githubusercontent.com/Jellman86/YetAnother-WhosAtMyFeeder/main/unraid/yawamf.xml &&
install -m 0644 /tmp/yawamf-template.xml "$template"
Use this command for a new installation. For an existing installation, keep its saved template and edit that container so your paths, ports and device settings are retained.
- Go to Docker → Add Container.
- In Template, select YA-WAMF under User templates.
- Review these fields:
- WebUI Port: host port for the UI (default
9852; the container listens on8080). - Config:
/configmapped to/mnt/user/appdata/ya-wamf/config(settings, credentials and the default media-cache directory). - Data:
/datamapped to/mnt/user/appdata/ya-wamf/data(SQLite history, species catalogue, models, manual uploads and migration backups). Keep both mounts on fast storage.
- WebUI Port: host port for the UI (default
- Click Apply.
The template runs as user ID (UID) 99 / group ID (GID) 100 (nobody:users) via --user 99:100.
Unraid creates missing mapped directories with this ownership. Existing
directories must already permit this user to write; importing a template does
not repair their permissions. If needed, stop YA-WAMF and correct ownership on
only its Config and Data directories. The image does not honour
PUID/PGID variables.
Expected result
Unraid pulls ghcr.io/jellman86/yawamf-monalithic:latest and starts the full
compatibility container. First startup can take several minutes while the
database and species catalogue are prepared. Open WebUI or
http://<your-unraid-ip>:9852/, then complete the first-run wizard.
In Frigate & MQTT connection, enter the Frigate API URL and MQTT broker
address, port and credentials, then test both connections. Use LAN addresses,
for example http://192.168.1.10:5000, or hostnames reachable from the container.
The default Docker bridge network does not resolve container names such as
frigate or mqtt; those names require a shared user-defined network. For a
Frigate API that requires authentication, provide its URL and token together
(see Frigate). Later changes belong in
Settings → Connection.
The current template leaves connection settings in the app. Older installs
may still have FRIGATE__FRIGATE_URL in their saved Unraid template; it overrides
the saved Frigate URL on restart. To move an existing install to in-app settings,
first note that URL, remove the variable from the container's edit form, apply
the change, and save the URL in Settings → Connection. Keep intentional
environment overrides if you manage configuration externally.
Authentication is disabled initially. Set an admin password during setup or under Settings → Security before exposing the service beyond a trusted network. See Authentication & Access.
Optional: hardware acceleration
The template deliberately starts with the full compatibility image and does not pin an inference provider. Four separate controls are involved:
| Control | Where to set it in Unraid | What it means |
|---|---|---|
| Image family | Repository tag | Which inference runtimes are installed |
| Device/runtime access | Advanced container settings | Which host accelerator the container can see |
| Selected provider | Settings → Detection inside YA-WAMF | The user's preferred provider, normally Auto |
| Active provider | YA-WAMF runtime diagnostics | What actually ran after model, packaging, and hardware checks |
The available stable Repository tags are:
| Repository tag | Packaged providers | Intended host |
|---|---|---|
latest |
CPU, CUDA, Intel CPU/GPU/NPU | Compatibility and initial setup |
latest-cpu |
CPU | Hosts without an accelerator |
latest-intel |
CPU and Intel OpenVINO | Intel GPU or NPU hosts |
latest-cuda |
CPU and NVIDIA CUDA | NVIDIA hosts |
Start with latest. Once the installation is healthy, edit only the tag portion
of Repository if you want a smaller image; keep the same /config and /data
paths. Pinned releases use the same suffix, such as v2.21.1-intel.
Do not add YAWAMF_IMAGE_FLAVOR to the template. It is read-only identity baked
into each image, and overriding it does not install a runtime. Also avoid adding
CLASSIFICATION__INFERENCE_PROVIDER for an ordinary interactive installation:
that environment variable overrides the in-app value on every container start,
so a provider changed in Settings would appear to save but revert after a
restart. Use it only when you intentionally manage immutable settings outside
the application.
See Hardware Acceleration for the complete provider contract, diagnostics, and rollback path.
Intel GPU or NPU
To run inference on an Intel GPU or NPU, add the device yourself (the template
does not add one, so it never passes an empty --device to Docker). In the
container's edit view, switch to Advanced view, click Add another Path,
Port, Variable, Label or Device, and add:
- Config Type Device, Value
/dev/dri— Intel integrated GPU (intel_gpu), or - Config Type Device, Value
/dev/accel/accel0— Intel Core Ultra "AI Boost" NPU (intel_npu).
Add only the device you actually have. Run the model compatibility check, then pick a validated provider under
Settings → Detection → Inference Provider, or keep Auto. GPU/NPU access can also require
supplementary host groups. Look up the numeric group owning the render or
accelerator device, then append --group-add <gid>
to Extra Parameters, preserving --user 99:100. See
Hardware Acceleration for the full detail and fallback
behaviour.
NVIDIA CUDA
- Install Unraid's
NVIDIA Driver plugin
and confirm
nvidia-smiworks in an Unraid terminal. Keep the GPU available to the host rather than binding it exclusively to VFIO. - Keep the full
latestRepository tag for compatibility testing, or change it tolatest-cudafor the smaller CUDA image. - Follow the NVIDIA Driver plugin's current container-runtime instructions for
your Unraid release. The established Docker-runtime path is to enable
Advanced view, append
--runtime=nvidiato Extra Parameters, keeping the existing--user 99:100, and add:NVIDIA_VISIBLE_DEVICESwith the GPU UUID shown by the plugin (orallwhen deliberately exposing every GPU), andNVIDIA_DRIVER_CAPABILITIES=compute,utility. Newer Unraid/NVIDIA toolkit releases may offer CDI device selection instead; use one exposure method, not both.
- Start the container, leave the in-app provider on Auto initially, and
check Settings → Detection → Runtime diagnostics. It must show a
fullorcudaimage, CUDA under Packaged, the GPU as available, and CUDA as Active during supported-model inference.
The NVIDIA runtime variables expose hardware; they do not select YA-WAMF's inference provider. If CUDA cannot initialize or the active model does not support it, YA-WAMF retains the provider preference and falls back to CPU with a diagnostic reason.
Update and verify
Back up the mapped Config and Data directories consistently before updating, then update the existing container through Unraid so its mappings and device access are retained. Wait for the container to become healthy, confirm recent photographs and history, then check Settings → Detection → Runtime diagnostics. New model assets need an application build with their integration; a rolling model-catalogue release does not update an older application. See the upgrade guide for retention-switch migration and rollback precautions.
If it fails
- Blank page or connection refused: the container may still be starting or applying model changes — wait a moment and retry. Check the container log in Unraid.
- No detections: confirm the Frigate URL is reachable from the container and that Frigate is publishing to MQTT. See Diagnostics.
For all settings once you are in, see the Configuration Guide.
Media gallery
Requirements
Categories
Related apps
Explore more like this
Explore allDetails
ghcr.io/jellman86/yawamf-monalithic:latestRuntime arguments
- Web UI
http://[IP]:[PORT:8080]/- Network
bridge- Shell
sh- Privileged
- false
- Extra Params
--user 99:100
Template configuration
Host port for the YA-WAMF web interface (container listens on 8080).
- Target
- 8080
- Default
- 9852
- Value
- 9852
Persistent application configuration (config.json, keys).
- Target
- /config
- Default
- /mnt/user/appdata/ya-wamf/config
- Value
- /mnt/user/appdata/ya-wamf/config
Detections database (SQLite) and cached media. Can grow with retention; keep on fast storage.
- Target
- /data
- Default
- /mnt/user/appdata/ya-wamf/data
- Value
- /mnt/user/appdata/ya-wamf/data
Container timezone, e.g. Europe/London. Leave blank for UTC.
- Target
- TZ