vh
39da1d4a97
The board mixed tools with endpoints. A vLLM seat whose href is a /docs page
sat in the same band as ComfyUI; the MQTT broker and the RustDesk relay, which
have no page at all, sat in Apps; and `Service Networking` was thirteen members
spanning three AdGuards, five Dockges, two Traefiks and four headless agents.
Every group is now one of two kinds and they never mix. TOOLS are expanded and
sit at the top of their tab. ENDPOINTS — an API, a broker, a background agent,
an href that is /docs or /ping or nothing — carry `initiallyCollapsed: true`
and sit at the bottom. Collapsed is not hidden: the eyebrow and its rule still
render, so the tab still says the thing exists and one click expands it.
A second rule fell out of the same pass and now shapes the group boundaries: a
group's members should all carry a widget or none should. A stat strip makes a
card ~50px taller, so one widget card in a row of plain ones opens a void under
the plain ones. That is why AdGuard and Traefik get their own groups rather
than sharing one with Dockge, and it is most of why the old Service Networking
band looked broken. AdGuard (ANA) was the last short card in its row and now
carries the same query/blocked/latency strip as its two siblings — one
infra-ops AdGuard login authenticates against all three instances, verified
against each; it lives in that stack's .env on the host and is vaulted.
The sixteen GPU-backed model seats were deliberately NOT relabelled.
`homepage.group` is read at container creation, so clearer names for
`AI - Inference` and friends would have cost a recreate on six vLLM seats, four
eval seats and four TTS engines — multi-minute model reloads on endpoints peers
reach through the gateway. Order plus `initiallyCollapsed` buys the same
separation for nothing, so those names stay as they are on purpose.
28 containers that ARE cheap to bounce were relabelled, across five hosts, via
rerunnable elway playbooks. Their label steps are gated on the old value still
being present, so a second run reports skipped rather than churning. Two verify
steps were wrong on first contact and are fixed with the reason recorded: the
traefik check raced its own recreate, and asserting a model seat is "running"
cannot answer "did I bounce it" when a seat may be legitimately stopped —
container age can, and now does.
The canonical stacks/ tree was synced to the deployed labels afterwards, so
intent and reality agree again on all fourteen tracked stacks.
Also documents the real nature of the post-recreate blank dashboard, which cost
~25 minutes here and an hour on 2026-08-19. `initialSettings":{}` in the served
HTML is the catch branch of the page's data loader, not a warm-up and not a
cache — and the error can vanish entirely, because the logger is assigned inside
the same try and the catch only logs if the logger exists. Ruled out by
measurement this time: all four API routes return 200 with correct content while
the page serves {}, and the previous known-good settings.yaml reproduces it
identically. The README now carries the one-command test and the next lead.
Before/after, all four tabs: http://10.100.10.50:8090/b/homepage-relayout/
scriberr — self-hosted transcription + diarization (ana-ml2, GPU1)
Web UI for transcribing audio/video locally. WhisperX (Whisper + pyannote speaker diarization) with NVIDIA Parakeet/Canary also selectable; SQLite for state; optional summarisation and transcript chat against any OpenAI-compatible endpoint.
- Host:
ana-ml2(10.250.50.54) — GPU1 - URL: http://10.250.50.54:8080
- Upstream: https://github.com/rishikanthc/Scriberr
The image is built locally, and that is not incidental
ana-ml2's RTX PRO 6000 Blackwell cards are sm_120. Upstream's published images do not cover that:
| image | built for | usable here |
|---|---|---|
ghcr.io/rishikanthc/scriberr |
CPU | yes, but no GPU |
ghcr.io/rishikanthc/scriberr-cuda |
sm_61 … sm_89 (Pascal→Ada) | no — no sm_120 kernels |
ghcr.io/rishikanthc/scriberr-cuda-blackwell |
sm_120 | does not exist — documented in the upstream README but never published; GHCR returns no tags (checked 2026-08-23) |
The sm_120 path upstream actually ships is Dockerfile.cuda.12.9
(CUDA 12.9.1 + cuDNN, PYTORCH_CUDA_VERSION=cu128), built from source. So we
build it. Do not "simplify" the compose back to the published scriberr-cuda
image — it will fail on these cards or quietly fall back to CPU.
Rebuilding
ssh ana-ml2
cd /tank/scriberr/src/Scriberr
git pull
docker build -f Dockerfile.cuda.12.9 -t scriberr:local-blackwell .
cd /opt/docker/compose/scriberr && docker compose up -d
Source checkout lives on /tank, not the root pool — see storage below.
Deploy
# from this workstation
scripts/deploy-stack.sh ana-ml2 scriberr
Then on the host, the usual:
cd /opt/docker/compose/scriberr
docker compose config # dry parse first
docker compose up -d scriberr # target the service, not the whole stack
Storage — deliberately on /tank
/var/lib/docker on ana-ml2 sits on zroot at ~87% used. Whisper, pyannote
and NeMo weights are multi-GB and land in the whisperx-env volume, so both
mounts are bind-mounted onto /tank (4+ TB) instead of named volumes:
| host path | container path | holds |
|---|---|---|
/tank/scriberr/data |
/app/data |
SQLite DB, uploads, transcripts |
/tank/scriberr/whisperx-env |
/app/whisperx-env |
Python env + model weights |
/tank/scriberr/src/Scriberr |
— | build checkout |
Both are owned by uid/gid 1000 to match PUID/PGID.
First run takes a while
On first start the container builds a Python environment and downloads several
GB of model weights before the port answers — upstream says "several minutes".
The healthcheck therefore has a 600 s start_period; the container will
show starting, not unhealthy, during that window. Watch it with:
docker logs -f scriberr
Subsequent starts are fast because the env volume persists.
The PUID trap — read this before "fixing" the uid
This stack runs as uid/gid 10001, not the fleet-usual 1000, and the
/tank/scriberr dirs are chowned to match. That is deliberate.
Dockerfile.cuda.12.9 creates appuser at uid 10001 — Ubuntu 24.04's base
image already owns uid 1000 as ubuntu, so upstream moved their app user out of
the way. It then chowns /app to 10001. But the entrypoint's PUID remapping
only chowns /app/data and /app/whisperx-env — not /app itself. So
running with PUID=1000 leaves the app unable to open its SQLite database and
it crash-loops with:
Failed to connect to database: unable to open database file: out of memory (14)
That message is a red herring twice over: error 14 is SQLITE_CANTOPEN, not an
OOM, and the machine has 566 GB of RAM. Diagnosis notes from 2026-08-23:
- SQLite itself writes fine to
/tankas uid 1000 — the mount is not at fault. - The app fails on a plain Docker named volume too — storage is not at fault.
- The published CPU image runs fine at
PUID=1000, because inDockerfile(the non-CUDA one)appuseris uid 1000. Only the CUDA 12.9 variant moved it. - Same image at
PUID=10001starts clean. That is the whole difference.
If you ever want host files owned by 1000 instead, the fix is to patch
Dockerfile.cuda.12.9 to userdel ubuntu and recreate appuser at 1000, then
rebuild — a local patch to carry, which is why it was not done.
Gotchas
SECURE_COOKIESmust stayfalsewhile served over plain HTTP. At the production default oftruethe session cookie is markedSecure, the browser drops it, and login appears to succeed then bounces you straight back to the login page with nothing useful in the logs.ALLOWED_ORIGINSmust list the real origin. Upstream defaults tolocalhostonly; reaching the UI by host IP fails CORS until it is set.- Never add
NVIDIA_VISIBLE_DEVICES=all. Upstream's compose sets it, but here it would override thedevice_idsreservation and expose both cards — GPU0 belongs to thegenseat. - This stack is a guest on GPU1, which it shares with the
secseat. If VRAM gets tight, this is the thing that should yield.
Optional: summarisation via the LiteLLM gateway
Scriberr speaks the OpenAI API, so point it at the fleet gateway instead of a paid vendor. In the UI under the AI provider settings:
- base URL:
http://10.250.50.70:4000/v1 - model:
summarizer(orgen/gen-reasoning) - key: the shared all-agents gateway key
⚠ That key also reaches paid passthrough models (GLM, Kimi) on a shared tab. Keep the configured model on a free local seat.