Structural repair: - 13 pages were the same document twice (each exactly 2x its HEAD size), a second frontmatter block whose closing fence had been glued onto a body line by a frontmatter rewrite that re-read its own output. Un-doubled by cutting at the second frontmatter and keeping the copy whose body is a superset; the orphan census reports 0 lost tokens against HEAD. - log.md: one entry per date, bare `## YYYY-MM-DD` headings, newest first — 66 dated headings merged into 34, titles demoted to bold leads, every content line verified present. The file had been descending at the head and ascending at the tail. Ownership moves: - New `LLM/frank-medium.md` is the locator for the retired Dankserver endpoint: era windows quoted from each era page's own banner, no numbers restated, and the two unresolved date conflicts recorded instead of silently resolved. `frank-archon.md` links to it instead of restating the pre-rename window. - The four Pipeline-Parallelism stubs (frontmatter only, no body) are gone; `Multi-Node Runtimes.md` owns runtime construction, launch, mixed-vendor verdicts and cross-split spec decode, and the four links that pointed at the stubs were repointed at it or at the drafter page. - Authentik's three stub pages fold into `Authentik.md`, with the process detail and the outpost reference split out so the parent stays under the length hint. Verified corrections (host census + live probe, 2026-10-19): - The MXFP4 checkpoint two pages called the "on-disk rollback" is gone: /home/dank/models/ holds StillDeadcode, rad and tpl.jinja. Stated once, on the era page that owns that payload; the swap page now links to it. - frank-medium-radiance-mxfp4: the 4.24/7 accept rate belongs to the DFlash2 arm measured on the FP8 target, not to the MXFP4 era; the 3-family soak run census is kept once (155 requests) instead of twice (~120 and 155). - Fleet shapes re-confirmed against the live endpoints before touching any page: 3x200000 fp8 KV, 2x200704, 2x262144. Index rows are regenerated, not hand-carved. Net -1,849 vault lines.
2.2 KiB
type, title, description, tags, timestamp
| type | title | description | tags | timestamp | |||
|---|---|---|---|---|---|---|---|
| reference | Redis (RomM Cache / Queue) | The Redis cache and task queue for RomM: quadlet unit, network alias topology, and the backup path. |
|
2026-09-03T00:00:00Z |
Redis (RomM Cache / Queue)
Redis 7 provides the caching and task-queue backend for RomM on Dankserver.
RomM requires Redis (or Valkey) for its task queue; this deployment runs
stock redis:7-alpine — no Valkey here, unlike the SearXNG cache on
Dankclaw (Valkey).
Host: Dankserver — container name romm-redis, unit romm-redis.service
(user-manager quadlet from dankserver/romm/quadlet/romm-redis.container).
Facts (verified from the live unit)
| Item | Value |
|---|---|
| Image | docker.io/library/redis:7-alpine |
| Port | 6379 — internal only; no PublishPort, so it is unreachable from the host network by construction |
| Network | dankserver_appnet with alias=redis — that alias is what makes REDIS_HOST=redis in the RomM unit resolve |
| Data volume | /home/dank/Containers/romm/redis:/data |
| Auth | None — safe precisely because the container is not published anywhere; only appnet members can reach it |
Unit shape (as deployed)
[Container]
ContainerName=romm-redis
Image=docker.io/library/redis:7-alpine
Network=dankserver_appnet:alias=redis
Volume=/home/dank/Containers/romm/redis:/data
HealthCmd=redis-cli ping
HealthInterval=10s
HealthTimeout=5s
HealthRetries=3
[Service]
Restart=always
RestartSec=5
[Install]
WantedBy=default.target
No EnvironmentFile — there is nothing secret in this unit; the auth-less
posture is enforced by network topology (alias-only reachability), not by a
password. If a future client ever needs Redis from outside the appnet, add
PublishPort and a requirepass in the same change — never just the port.
Backup
sudo rsync -a /home/dank/Containers/romm/redis /mnt/backup/romm-redis/
Redis here is cache + queue state; losing it costs queued jobs and cache warm, not the library (the database lives in MariaDB).