Files

T

Frank e7f0d93c86 docs(vault): fleet-wide fact re-verification pass (67 pages)

The docs-fact census wave re-read the live hosts and re-keyed every page
it could: runtime/payload identities, ports, sizes, ledger figures, unit
state, and the retirement banners that drifted as the fleet moved. The
wave was interrupted mid-run, so this commit carries only what passed the
integrity gates: every touched page parses (front matter or H1+status
convention intact, balanced fences, no truncated tables, trailing
newline), the docs_completeness and link-integrity seams are green, and
bats is 384/384.

Numbers that this session proved on live hosts are keyed to the measured
value, not the page's earlier claim.

2026-10-18 13:15:43 -07:00

3.9 KiB

Raw Permalink Blame History

type, description, tags, timestamp

type

description

Valkey

Valkey is the cache and limiter store for SearXNG. It replaces Redis as the default in the official SearXNG deployment — the running build (2026.9.25+12f8b6515, /config 2026-10-18) reads a valkey: settings key and has no redis: key (searx/settings.yml at commit 12f8b6515, https://raw.githubusercontent.com/searxng/searxng/12f8b6515/searx/settings.yml).

Host: Dankclaw — Docs: https://valkey.io

Facts (from research)

Item	Value
Image	`docker.io/valkey/valkey:9-alpine` (`dankclaw/searxng/quadlet/searxng-valkey.container:19`; live container image reference `podman inspect searxng-valkey` 2026-10-18)
Port	6379 container-internal — the unit publishes no port (`dankclaw/searxng/quadlet/searxng-valkey.container` has no `PublishPort`; `ss -ltn 2026-10-18` shows nothing on 6379 and a TCP probe to `192.168.0.143:6379` is refused), so `shared/homepage/services.json` marks the card `wip: "closed"`
Role	SearXNG limiter + result cache

Why Valkey

Valkey is the Redis fork under the Linux Foundation umbrella, and the SearXNG project moved to it as the default cache: the pinned build's searx/settings.yml exposes valkey: { url: … } and has no redis: key (https://raw.githubusercontent.com/searxng/searxng/12f8b6515/searx/settings.yml). The searxng-valkey service name and the valkey/valkey:9-alpine image are this repo's choice (dankclaw/searxng/quadlet/searxng-valkey.container:16-19), matching the container name SearXNG's settings then point at. (unverified 2026-10-18: the claim that upstream's own docker-compose ships a container named searxng-valkey is not checkable from this repo)

Configuration

The valkey unit is searxng-valkey.container (see SearXNG for the trio). It joins the searxng network and is reachable by the name searxng-valkey (container name) and the alias valkey:

[Container]
ContainerName=searxng-valkey
Network=searxng.network
NetworkAlias=valkey
Image=docker.io/valkey/valkey:9-alpine
Volume=/opt/searxng/valkey:/data

SearXNG connects to it via settings.yml, which addresses the container name, not the alias — the alias is a second, working name for the same endpoint:

valkey:
  url: "valkey://searxng-valkey:6379/0"

Repo source shared/searxng/settings.yml:22-23; the deployed render /opt/searxng/config/settings.yml:23 is byte-identical on this key (2026-10-18).

It sets WantedBy=default.target and Restart=always (dankclaw/searxng/quadlet/searxng-valkey.container:25-28), the unit is installed at ~/.config/containers/systemd/searxng-valkey.container, and systemctl --user is-enabled reports generated / is-active active with Linger=yes (host check 2026-10-18), so it starts at boot.

Volumes

Container path	Host path
`/data`	`/opt/searxng/valkey` (`dankclaw/searxng/quadlet/searxng-valkey.container:20`; the live dir exists, owner uid 100998 — `ls -ld /opt/searxng/valkey` 2026-10-18)

Gotchas

The limiter relies on Valkey; without it SearXNG falls back to in-memory state and rate limiting is per-restart. (unverified 2026-10-18: upstream fallback behaviour not read; the pinned default is url: false, i.e. no cache configured)
The cache is reachable because both containers share one network: searxng-valkey joins searxng.network (searxng-valkey.container:17), and SearXNG itself has no network of its own — it reuses Gluetun's netns (searxng.container:18), and Gluetun is the member of systemd-searxng (10.89.2.0/24, podman network inspect systemd-searxng 2026-10-18). Keeping the cache off that network breaks SearXNG's limiter, not just the result cache.

3.9 KiB Raw Permalink Blame History