add docker compose stacks for home automation, media, observability, and LLM

[track-prepped-68-Corolla]

$(cat <<'EOF'

Summary

• containers/homeAutomation.yaml — Home Assistant (host-network for mDNS/UPnP) + Mosquitto MQTT broker + Zigbee2MQTT; Zigbee adapter device configurable via ${ZIGBEE_DEVICE:-/dev/ttyUSB0}
• containers/media.yaml — Gluetun VPN gateway with qBittorrent, aria2, and AriaNg routed through it (network_mode: service:gluetun); Jellyfin + Sonarr + Radarr + Prowlarr + Bazarr on a separate media-net bridge; *arr apps reach qBittorrent at gluetun:8080
• containers/observability.yaml — Prometheus + Grafana + Loki + Alloy (log shipper) + Node Exporter + cAdvisor; named volumes for persistent data
• containers/llm.yaml — Hermes gateway + dashboard (nousresearch/hermes-agent:latest, host-network per upstream recommendation) + AnythingLLM; optional Teams/Google Chat/API server env vars commented in

All stacks follow existing containers/ conventions: no version: key, restart: unless-stopped, ports bound to 127.0.0.1, secrets via ${ENV_VAR} for Komodo injection, bind mounts under /opt/containers/<stack>/.

Test plan

• In Komodo: add each stack → source: Git → repo track-prepped-68-corolla/ft-home, branch testing, compose path containers/<file>.yaml
• Deploy each stack; confirm all services reach healthy state in Komodo dashboard
• Verify port bindings are reachable on localhost (e.g. HA at :8123, Grafana at :3000, Hermes dashboard at :9119)

https://claude.ai/code/session_01E7mMYhNQQqLWpS4AoATTAb
EOF
)

---

Generated by Claude Code

Summary by CodeRabbit

• New Features
  • Home automation suite for device control, Zigbee bridge, and local MQTT broker with web UIs
  • Local AI/LLM services including an agent, dashboard, and a model-serving endpoint
  • Media management stack with media servers, download tools, web UIs, and optional VPN gateway
  • Observability suite with dashboards, metrics, tracing, and host monitoring tools

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 166e195e-abf4-4cd0-ba89-be006d2889ef

📥 Commits

Reviewing files that changed from the base of the PR and between 20702f9 and f52d481.

📒 Files selected for processing (1)

• containers/config/mosquitto/mosquitto.conf

---

📝 Walkthrough

Walkthrough

Adds four Docker Compose stacks: home automation (Home Assistant, Mosquitto, Zigbee2MQTT, plus Mosquitto config), LLM services (Hermes agent + dashboard, AnythingLLM), media (Gluetun VPN with qBittorrent/Aria2/Ariang and media servers), and observability (Prometheus, Tempo, otelcol, Grafana, Loki, Alloy, exporters).

Changes

Home Automation Stack

Layer / File(s)	Summary
Home automation services and network containers/homeAutomation.yaml, containers/config/mosquitto/mosquitto.conf	Home Assistant with host networking and privileged mode; Mosquitto broker with localhost MQTT/WebSocket listeners, healthcheck, and config/data/log mounts; Mosquitto configuration file (listeners, persistence, logging); Zigbee2MQTT with serial-device mapping and dependency on Mosquitto; declares ha-net.

LLM Services Stack

Layer / File(s)	Summary
Hermes agent and dashboard containers/llm.yaml	Hermes agent with host networking, /opt/data persistent storage, UID/GID env defaults, gateway run startup and localhost healthcheck; Hermes Dashboard uses same image, depends on Hermes, and binds to localhost with --no-open.
AnythingLLM and network containers/llm.yaml	AnythingLLM attached to llm-net, exposes 3001 on localhost only, mounts server storage, sets STORAGE_DIR and TZ; declares llm-net.

Media Stack

Layer / File(s)	Summary
VPN gateway and torrent/download clients containers/media.yaml	Gluetun VPN gateway with NET_ADMIN/TUN, VPN env configuration, and localhost-published ports; qBittorrent and Aria2 run via network_mode: "service:gluetun" with config/download volumes and health gating; Ariang depends on Aria2.
Media server applications containers/media.yaml	Jellyfin (with /dev/dri), Sonarr, Radarr, Prowlarr, Bazarr on media-net with localhost-only web UIs, persistent config and media mounts, and PUID/PGID/TZ envs.
Media network containers/media.yaml	media-net bridge network declaration.

Observability Stack

Layer / File(s)	Summary
Observability services and infrastructure containers/observability.yaml	Prometheus, Tempo, otelcol, Grafana (provisioned admin password), Loki, Grafana Alloy, node-exporter, and cAdvisor on monitoring-net with host-mounted configs, named data volumes, healthchecks, and depends_on ordering.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐳 Four stacks compose a tidy sea,
MQTT hums while dashboards sip tea,
Torrents tunnel through a private lane,
Metrics flow to Grafana's pane,
Containers sing in ordered harmony.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'add docker compose stacks for home automation, media, observability, and LLM' directly and comprehensively summarizes the main change—four new Docker Compose configuration files are being added to the containers/ directory.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/docker-compose-stacks-m68q1

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 11

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@containers/homeAutomation.yaml`:
- Around line 6-7: Host networking and privileged mode in the Home Assistant
container breaks the stack's localhost-only guarantee; remove or stop setting
network_mode: host and privileged: true in the service definition and instead
publish the required ports bound to localhost (e.g., bind host 127.0.0.1 to the
Home Assistant port) using the service's ports section, keep the default bridge
network (or an isolated user-defined network), and if any capabilities were
required by privileged: true, replace with minimal cap_add, devices, or sysctls
on the same service (refer to the service entry where network_mode: host and
privileged: true are declared).
- Around line 43-44: The current depends_on only enforces startup order for the
mosquitto service; add a Docker healthcheck to the mosquitto service that
verifies MQTT is accepting connections (e.g., TCP check against port 1883 or a
small mqtt probe/sub test) and then change the Zigbee2MQTT service's depends_on
to use the service_healthy condition (depends_on: { mosquitto: { condition:
service_healthy } }) so Zigbee2MQTT waits for Mosquitto readiness; update the
mosquitto service block (healthcheck) and the depends_on list for the
Zigbee2MQTT service accordingly.
- Line 14: The deployment uses floating image tags for the mosquitto and
zigbee2mqtt containers (image: eclipse-mosquitto:latest and image:
koenkk/zigbee2mqtt:latest); update those image references to pinned version tags
or immutable digests (for example replace with specific versions like
eclipse-mosquitto:2.1 or koenkk/zigbee2mqtt:2.11.0, or use SHA256 digests) so
deployments are reproducible and security patches are applied
intentionally—modify the mosquitto and zigbee2mqtt image fields accordingly.

In `@containers/llm.yaml`:
- Around line 38-39: Add a Docker Compose health check for the hermes service
and change hermes-dashboard's depends_on to wait for that healthcheck: define a
healthcheck block on the hermes service that probes http://localhost:8642/health
(using curl or equivalent) with sensible interval/timeout/retries, and update
hermes-dashboard's depends_on to the long-form mapping with condition:
service_healthy so the dashboard only starts when Hermes is actually ready; edit
the hermes service definition and the hermes-dashboard depends_on entry
accordingly.
- Line 3: Replace the floating images and gate dashboard startup: change image
references using exact release tags or multi-arch digests instead of
nousresearch/hermes-agent:latest and mintplexlabs/anythingllm:latest (e.g.,
nousresearch/hermes-agent:v2026.5.29.2 or the manifest-list digest, or set
platform + per-arch digest) and update any image keys referencing those symbols
to the pinned values; add a healthcheck block to the hermes service
(HTTP/TCP/command that verifies readiness) and change hermes-dashboard's
depends_on so it uses condition: service_healthy instead of just depending on
hermes to ensure the dashboard waits for actual Hermes readiness.

In `@containers/media.yaml`:
- Around line 38-39: Update the docker-compose dependency so qBittorrent and
aria2 wait for the Gluetun healthcheck, not just container start: replace
depends_on: - gluetun with depends_on: gluetun: condition: service_healthy
(apply this change for the qbittorrent and aria2 service blocks referencing
gluetun) so the services wait for the Gluetun healthcheck to pass before
starting.
- Around line 16-17: The BT port mapping "6888:6888" for the aria2 service
publishes the port on all interfaces; remove that host binding (delete the
"6888:6888" line) or change it to bind to localhost (use "127.0.0.1:6888:6888")
so it matches the other bindings and relies on VPN port forwarding; update the
containers/media.yaml aria2 port entries accordingly.

In `@containers/observability.yaml`:
- Line 60: The Grafana env var falls back to a weak default
(GF_SECURITY_ADMIN_PASSWORD=${GF_SECURITY_ADMIN_PASSWORD:-changeme}); remove the
insecure fallback and require the variable be provided by failing fast—replace
the defaulting form with a strict check (e.g. use shell-style required-variable
expansion or remove the ":-changeme" so the compose parsing fails if unset)
and/or wire the password through a secret; update the GF_SECURITY_ADMIN_PASSWORD
usage in containers/observability.yaml (the GF_SECURITY_ADMIN_PASSWORD env
entry) accordingly so the service will not start with a default weak credential.
- Line 91: Replace the hardcoded volume mount
"/var/run/podman/podman.sock:/var/run/docker.sock:ro" in
containers/observability.yaml with a configurable variable (e.g., use an env var
or template like $(CONTAINER_RUNTIME_SOCK) or {{
.Values.containerRuntimeSocketPath }}) and provide a sensible default (for
example "/var/run/docker.sock") so the socket path can be overridden per-host;
update the deployment/helm template that renders this volume mount and ensure
the new variable name CONTAINER_RUNTIME_SOCK or containerRuntimeSocketPath is
documented and wired into the container spec where the volume mount is defined.
- Line 131: Remove the redundant /cgroup bind mount from the cAdvisor container
spec (the entry "- /cgroup:/cgroup:ro") and rely on the existing "/sys:/sys:ro"
mount so cAdvisor can read cgroup v2 under /sys/fs/cgroup; update the
containers/observability.yaml cAdvisor volume mounts (the list containing
"/sys:/sys:ro" and "/cgroup:/cgroup:ro") to drop the "/cgroup:/cgroup:ro" line
and optionally add a brief comment noting that /sys provides the unified cgroup
v2 hierarchy.
- Around line 45-47: Add Docker Compose healthchecks for the tempo and loki
services and change dependent services (otelcol, grafana, alloy) to depend_on
with condition: service_healthy so they wait for readiness; specifically, add a
healthcheck for tempo that runs its native check (tempo --health
--health.url=http://127.0.0.1:3200/ready) and a healthcheck for loki using its
native -health (which checks /ready), then update otelcol, grafana, and alloy
depends_on entries to reference tempo and loki with condition: service_healthy;
if you must support podman-compose, add an extra startup gating (e.g., simple
retry/wait loop or startup script) for otelcol/grafana/alloy because
podman-compose can be flaky enforcing service_healthy.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: ae155f8f-e3ad-41f6-9548-2e36ca57ca09

📥 Commits

Reviewing files that changed from the base of the PR and between 3c39cf4 and 76767b9.

📒 Files selected for processing (4)

• containers/homeAutomation.yaml
• containers/llm.yaml
• containers/media.yaml
• containers/observability.yaml

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Host networking breaks localhost-only exposure guarantees for Home Assistant.

With network_mode: host, Home Assistant is no longer constrained by Compose port bindings and can be reachable on host interfaces. This conflicts with the stack’s localhost-only access posture and increases attack surface.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@containers/homeAutomation.yaml` around lines 6 - 7, Host networking and
privileged mode in the Home Assistant container breaks the stack's
localhost-only guarantee; remove or stop setting network_mode: host and
privileged: true in the service definition and instead publish the required
ports bound to localhost (e.g., bind host 127.0.0.1 to the Home Assistant port)
using the service's ports section, keep the default bridge network (or an
isolated user-defined network), and if any capabilities were required by
privileged: true, replace with minimal cap_add, devices, or sysctls on the same
service (refer to the service entry where network_mode: host and privileged:
true are declared).

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

What are the current stable/recommended production tags (or immutable digests) for Docker images eclipse-mosquittoandkoenkk/zigbee2mqtt, and what are their latest security advisories/changelog notes?

💡 Result:

Recommended/production tags (stable) as of 2026-06-03 1) eclipse-mosquitto (Docker Official Image) - Stable tag: 2.1 (and its variants) - Supported tags include: 2.1.2-alpine, 2.1-alpine, alpine, 2, latest, plus 2.0.x and 1.6.x lines. The “Official Images” metadata lists the 2.1 line under /docker/2.1-alpine and the tag set for that line. [1][2] - Production “latest” tag and immutable digest: - eclipse-mosquitto:latest → sha256:a908c65cc8e67ec9d292ef27c2c0360dbaaee7eb1b935cdd194e67697f15dea1 (amd64 manifest digest shown for the latest tag). [3] Latest security advisories / changelog notes (mosquitto codebase) - eclipse-mosquitto upstream changelog entries include multiple security fixes, including CVE-2023-28366 (memory leak) and other broker/client fixes. - In the upstream ChangeLog, the 2.0.21 and 2.0.22 sections list “Further fix for CVE-2023-28366” and “Fix leak on malicious SUBSCRIBE by authenticated client,” among other security items. [4][5] - Example published advisory (OS/package-level): - Ubuntu USN-7441-1 documents Eclipse Mosquitto vulnerabilities including CVE-2024-10525 and CVE-2024-3935, and recommends updating the relevant Ubuntu packages. [6] 2) koenkk/zigbee2mqtt - Stable/production tag: latest (release) and latest-dev (dev) - Zigbee2MQTT’s Docker guide states the following tags are available: “latest” (latest release version) and “latest-dev” (latest dev version based on dev branch), plus version-specific tags (e.g., 2, 2.0.0, etc.). [7][8] - Immutable digest for latest (from Docker Hub tag page) - koenkk/zigbee2mqtt:latest → Digest shown on Docker Hub tag summary: sha256:64877da04… (digest truncated in the snippet, but explicitly listed as the tag’s digest). [9] Latest security advisories / changelog notes (zigbee2mqtt project) - zigbee2mqtt changelog (project-level) is maintained in CHANGELOG.md and the latest release is 2.11.0 (published 2026-06-01). - The GitHub releases page shows release 2.11.0 published on 2026-06-01. [10] - The changelog provided in results is dominated by “Bug Fixes” sections; no specific security/CVE items were visible in the captured excerpts. - The repository CHANGELOG.md contains dated entries such as 2.9.2 (2026-03-31) and earlier versions, with a “Bug Fixes” section for each. [11] Practical recommendation - For “stable production” use the release tags: eclipse-mosquitto:2.1 (or the matching Alpine/openssl variants) and koenkk/zigbee2mqtt:latest. [1][2][7][8] - For immutability pin digests: - eclipse-mosquitto@sha256:a908c65cc8e67ec9d292ef27c2c0360dbaaee7eb1b935cdd194e67697f15dea1 [3] - koenkk/zigbee2mqtt@sha256:64877da04… (digest shown for the latest tag on Docker Hub). [9]

Citations:

• 1: https://github.com/docker-library/official-images/blob/master/library/eclipse-mosquitto
• 2: https://github.com/docker-library/docs/blob/master/eclipse-mosquitto/README.md
• 3: https://github.com/docker-library/repo-info/blob/master/repos/eclipse-mosquitto/remote/latest.md
• 4: https://github.com/eclipse-mosquitto/mosquitto/blob/v2.0.21/ChangeLog.txt
• 5: https://github.com/eclipse-mosquitto/mosquitto/blob/28f91478/ChangeLog.txt
• 6: https://ubuntu.com/security/notices/USN-7441-1
• 7: https://www.zigbee2mqtt.io/guide/installation/02_docker.html
• 8: https://github.com/Koenkk/zigbee2mqtt.io/blob/7c1f59e1/docs/guide/installation/02_docker.md
• 9: https://hub.docker.com/r/koenkk/zigbee2mqtt/
• 10: https://github.com/Koenkk/zigbee2mqtt/releases/tag/2.11.0
• 11: https://github.com/Koenkk/zigbee2mqtt/blob/master/CHANGELOG.md

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

file="containers/homeAutomation.yaml"
echo "== file: $file =="
nl -ba "$file" | sed -n '1,120p'

Repository: track-prepped-68-Corolla/ft-home

Length of output: 180

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

file="containers/homeAutomation.yaml"
echo "== file: $file (head -n 120) =="
cat -n "$file" | sed -n '1,120p'
echo "== relevant lines only (12-40) =="
cat -n "$file" | sed -n '12,40p'

Repository: track-prepped-68-Corolla/ft-home

Length of output: 2745

---

Pin eclipse-mosquitto and koenkk/zigbee2mqtt image tags instead of using :latest

containers/homeAutomation.yaml uses floating tags here:

  mosquitto:
    image: eclipse-mosquitto:latest

  zigbee2mqtt:
    image: koenkk/zigbee2mqtt:latest

Pin to specific release tags (e.g., eclipse-mosquitto:2.1 and koenkk/zigbee2mqtt:2.11.0) or immutable digests so deployments are reproducible and security updates happen intentionally (Mosquitto has security fixes in patch releases).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@containers/homeAutomation.yaml` at line 14, The deployment uses floating
image tags for the mosquitto and zigbee2mqtt containers (image:
eclipse-mosquitto:latest and image: koenkk/zigbee2mqtt:latest); update those
image references to pinned version tags or immutable digests (for example
replace with specific versions like eclipse-mosquitto:2.1 or
koenkk/zigbee2mqtt:2.11.0, or use SHA256 digests) so deployments are
reproducible and security patches are applied intentionally—modify the mosquitto
and zigbee2mqtt image fields accordingly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

What are the currently published immutable image digests for nousresearch/hermes-agentandmintplexlabs/anythingllm, and which tags are recommended as stable production releases?

💡 Result:

nousresearch/hermes-agent - Currently published immutable image digests (multi-arch manifests) as shown on Docker Hub tags page: - latest (docker pull nousresearch/hermes-agent:latest) → sha256:6c1367ce0a25 and sha256:3eee2f686eab [1] - main (docker pull nousresearch/hermes-agent:main) → sha256:6c1367ce0a25 and sha256:3eee2f686eab [1] - v2026.5.29.2 → sha256:00ec7c4d7ea8 and sha256:d034a3f09be9 [1] - v2026.5.29 → sha256:2f1f2f1725e5 and sha256:d0b10c6de204 [1] - Recommended stable production tags: use the pinned versioned release tags v*.. (e.g., the latest published v2026.5.29.2 shown on Docker Hub), not floating tags like latest/main (which are mutable). Docker Hub exposes immutable digests for those tags, but “latest/main” are floating pointers to whichever images are current. [1] mintplexlabs/anythingllm - Currently published immutable image digests (multi-arch manifests) as shown on Docker Hub tags page: - latest (docker pull mintplexlabs/anythingllm:latest) → sha256:1c2669ead5aa and sha256:2864d491dc54 [2] - master (docker pull mintplexlabs/anythingllm:master) → sha256:1c2669ead5aa and sha256:2864d491dc54 [2] - 1.13 → sha256:50754 and sha256:b61… (Docker Hub page is truncated in the captured snippet; the exact two digests for 1.13 are not fully visible in the provided highlights) [2] - 1.13.0 is also listed with digests on the Docker Hub tags page but the snippet is truncated, so only the partial digests are visible in the capture. [2] - Recommended stable production tags: use the pinned versioned release tags v*.. (examples: v1.13.0) as described in the AnythingLLM Docker docs (“v*.. images are the pinned versioned releases… published when a new release is made”). [3] If you want, I can do one more targeted pass specifically to extract the full digests for the current top v*.. release tags for anythingllm (the Docker Hub snippet is truncated for those specific rows).

Citations:

• 1: https://hub.docker.com/r/nousresearch/hermes-agent/tags
• 2: https://hub.docker.com/r/mintplexlabs/anythingllm/tags
• 3: https://docs.anythingllm.com/installation-docker/available-images

---

🌐 Web query:

What is the exact Docker Hub digest shown for mintplexlabs/anythingllm:1.13.0(orv1.13.0 if that’s the real tag), and is it a multi-arch manifest digest (manifest list) or per-arch digest?

💡 Result:

The Docker image mintplexlabs/anythingllm:1.13.0 is published as a multi-arch manifest list (also known as an image index) [1][2]. This format allows the Docker client to automatically pull the appropriate image version (amd64 or arm64) based on the host's architecture [1][2]. Because it is a multi-arch manifest list, there is no single digest associated with the tag that corresponds to a specific OS/Arch binary; rather, the tag points to the manifest list digest. While exact current digests change whenever the image is repushed, as of the time of this research, mintplexlabs/anythingllm images are consistently maintained as manifest lists supporting both linux/amd64 and linux/arm64 architectures [1][2]. Users can verify the specific manifest digest for their local environment by running docker manifest inspect mintplexlabs/anythingllm:1.13.0 [3][4].

Citations:

• 1: https://docs.anythingllm.com/installation-docker/available-images
• 2: https://github.com/Mintplex-Labs/anything-llm/blob/1cea4df8/docker/HOW_TO_USE_DOCKER.md
• 3: https://docs.docker.com/reference/cli/docker/manifest/inspect/
• 4: https://docs.docker.com/reference/cli/docker/manifest/

---

🌐 Web query:

On Docker Hub for nousresearch/hermes-agent, what is the exact digest value for the tag v2026.5.29.2 (and is there a distinct manifest-list digest vs per-arch digests)?

💡 Result:

For the Docker Hub tag nousresearch/hermes-agent:v2026.5.29.2, the exact digest value shown is sha256:00ec7c4d7ea8 [1]. Docker Hub shows per-OS/arch digests (distinct digests for linux/amd64 vs linux/arm64) and also has a digest for the overall manifest (or manifest-list/index) when applicable; for this tag, Docker Hub’s tag page lists two different digests under the same tag for linux/amd64 and linux/arm64 (00ec7c4d7ea8 and d034a3f09be9, respectively) [1]. The provided Docker Hub tag page output does not include the full manifest-list digest separately from the per-arch digests, so from Docker Hub’s UI alone we can only confirm the per-arch digests shown there [1].

Citations:

• 1: https://hub.docker.com/r/nousresearch/hermes-agent/tags

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

ls -la
fd -a -t yaml containers/llm.yaml || true
echo "---- containers/llm.yaml ----"
if [ -f "containers/llm.yaml" ]; then
  nl -ba containers/llm.yaml | sed -n '1,120p'
else
  echo "containers/llm.yaml not found"
fi

Repository: track-prepped-68-Corolla/ft-home

Length of output: 1677

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

if [ -f "containers/llm.yaml" ]; then
  python3 - <<'PY'
from pathlib import Path
p = Path("containers/llm.yaml")
lines = p.read_text().splitlines()
for i, line in enumerate(lines, 1):
    if i <= 120:
        print(f"{i:4d}\t{line}")
PY
else
  echo "containers/llm.yaml not found"
fi

Repository: track-prepped-68-Corolla/ft-home

Length of output: 2346

---

Pin container images to fixed releases (avoid :latest) and gate dashboard startup on Hermes readiness.

• containers/llm.yaml uses nousresearch/hermes-agent:latest (lines 3, 29) and mintplexlabs/anythingllm:latest (line 44); switch to fixed, versioned release tags (e.g., nousresearch/hermes-agent:v2026.5.29.2 and an anythingllm v*.*.* release) to keep deployments reproducible. If pinning by digest, use the multi-arch manifest-list digest (or set platform and pin the corresponding per-arch digest).
• hermes-dashboard only has depends_on on hermes (lines 38-39); add healthcheck + depends_on: { condition: service_healthy } so the dashboard waits for actual Hermes readiness, not just container start.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@containers/llm.yaml` at line 3, Replace the floating images and gate
dashboard startup: change image references using exact release tags or
multi-arch digests instead of nousresearch/hermes-agent:latest and
mintplexlabs/anythingllm:latest (e.g., nousresearch/hermes-agent:v2026.5.29.2 or
the manifest-list digest, or set platform + per-arch digest) and update any
image keys referencing those symbols to the pinned values; add a healthcheck
block to the hermes service (HTTP/TCP/command that verifies readiness) and
change hermes-dashboard's depends_on so it uses condition: service_healthy
instead of just depending on hermes to ensure the dashboard waits for actual
Hermes readiness.

[github-actions]

@claude CodeRabbit has submitted a review. Please address the feedback and push a fix.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@containers/homeAutomation.yaml`:
- Around line 28-33: The healthcheck's mosquitto_sub command and timing are too
tight for default Mosquitto $SYS cadence; update the healthcheck "test" to
subscribe to a more immediately-emitted $SYS topic (e.g., $SYS/broker/version or
$SYS/broker/uptime) instead of "$$SYS/#", and increase the mosquitto_sub wait
(-W) and the Docker healthcheck interval and start_period values to avoid false
failures; specifically modify the healthcheck test string (mosquitto_sub ...) to
target $SYS/broker/version (or $SYS/broker/uptime) with -C 1 retained, bump -W
from 3 to a larger value (e.g., 10) and increase the healthcheck interval and
start_period accordingly so the service_healthy check no longer flaps.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4744080a-0552-4176-9044-a70d927ca056

📥 Commits

Reviewing files that changed from the base of the PR and between 76767b9 and d4256e2.

📒 Files selected for processing (4)

• containers/homeAutomation.yaml
• containers/llm.yaml
• containers/media.yaml
• containers/observability.yaml

[github-actions]

@claude CodeRabbit has submitted a review. Please address the feedback and push a fix.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

containers/homeAutomation.yaml (1)

22-23: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Ensure Mosquitto is configured to allow Zigbee2MQTT connections (no anonymous-by-default mismatch)

containers/homeAutomation.yaml mounts /opt/containers/home-automation/mosquitto/config:/mosquitto/config (lines 22-23), but the repo contains no mosquitto.conf and no listener 1883 / allow_anonymous / auth directives. With Mosquitto 2.x (eclipse-mosquitto:latest), anonymous access is disabled by default, so Zigbee2MQTT may fail to connect. Add a mosquitto.conf to the repo (or clearly document how it’s created on the host) that defines the 1883 listener and either allow_anonymous true or the required authentication.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@containers/homeAutomation.yaml` around lines 22 - 23, The docker compose
service mounts a Mosquitto config directory via the volumes entry (the mosquitto
config mount) but the repo lacks a mosquitto.conf so Mosquitto 2.x will block
anonymous clients like Zigbee2MQTT; add a mosquitto.conf into the mounted config
(or document how it’s provisioned on the host) that declares a listener 1883 and
sets either allow_anonymous true or the appropriate authentication directives
(username/password or password_file) so Zigbee2MQTT can connect, and ensure the
service startup uses that config.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@containers/homeAutomation.yaml`:
- Around line 22-23: The docker compose service mounts a Mosquitto config
directory via the volumes entry (the mosquitto config mount) but the repo lacks
a mosquitto.conf so Mosquitto 2.x will block anonymous clients like Zigbee2MQTT;
add a mosquitto.conf into the mounted config (or document how it’s provisioned
on the host) that declares a listener 1883 and sets either allow_anonymous true
or the appropriate authentication directives (username/password or
password_file) so Zigbee2MQTT can connect, and ensure the service startup uses
that config.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 24344f78-9daa-4aae-9b5f-4a06a41c8c45

📥 Commits

Reviewing files that changed from the base of the PR and between d4256e2 and 20702f9.

📒 Files selected for processing (1)

• containers/homeAutomation.yaml

[github-actions]

@claude CodeRabbit has submitted a review. Please address the feedback and push a fix.