fix(security): GPU access + production hardening (health checks, image pins, required password)

[POWERFULMOVES]

Summary

This PR combines GPU configuration fixes with comprehensive production hardening:

1. GPU Access Fixes ✅

• Added NVIDIA_VISIBLE_DEVICES and deploy.resources.reservations.devices to GPU services
• Fixed media-audio Dockerfile to use nvidia/cuda base image
• Services: gpu-orchestrator, ultimate-tts-studio, hi-rag-gateway-gpu, hi-rag-gateway-v2-gpu, media-audio

2. POSTGRES_PASSWORD Now Required ✅ (Security Critical)

• Changed from insecure :-pmoves default to required syntax ${VAR:?error}
• Compose will now fail if POSTGRES_PASSWORD is not set
• Affected lines: 59, 78, 937

3. Pinned :latest Images ✅ (8 images)

Previous	Pinned Version
postgrest/postgrest:latest	v12.2.3
minio/minio:latest	RELEASE.2024-12-18T13-15-44Z
ollama/ollama:latest	0.5.4
tensorzero/gateway:latest	2024.12.18
tensorzero/ui:latest	2024.12.18
invidious:latest	2024.12.09
invidious-companion:latest	2024.12.20
grayjay:latest	2024.11.01

4. Health Checks ✅ (37 new, 52 total)

Added health checks to services that were missing them:

• Data tier: qdrant, meilisearch, minio
• API tier: hi-rag-*, retrieval-eval, presign, render-webhook
• Worker tier: extract-worker, pdf-ingest, langextract, notebook-sync, ffmpeg-whisper, media-video, media-audio, pmoves-yt, channel-monitor
• Agent tier: agent-zero, mesh-agent, deepresearch, supaserch, nats
• TensorZero: gateway, ui, ollama
• Others: publisher-discord, messaging-gateway, jellyfin-bridge, grayjay-*

Test Plan

• docker compose config validates successfully with required vars
• Verified :latest tags only remain in comments (Docker MCP TODO)
• Health check count increased from 15 → 52
• Manual: Start services and verify health check endpoints respond

Breaking Changes

⚠️ POSTGRES_PASSWORD is now required - Deployments without this variable set will fail to start. Set it in your .env.local or env tier file.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added comprehensive health monitoring across services for improved reliability and readiness detection.
  • Enhanced GPU resource visibility and configuration support.

• Documentation

  • Added detailed service catalog with GPU and External Integrations sections.
  • Introduced Environment Tier Consolidation learnings and guidance.

• Chores

  • Updated service images to explicit versions for consistency and stability.
  • Added new environment configuration examples for Media and Worker tiers.
  • Implemented security improvements including non-root user enforcement.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

This PR introduces GPU infrastructure support, environment tier consolidation patterns, and comprehensive service health monitoring. Key changes include adopting NVIDIA CUDA base image for media services, adding extensive healthchecks across docker-compose services, pinning image versions to explicit tags, creating environment tier example configurations, and documenting tier consolidation learnings.

Changes

Cohort / File(s)	Summary
Documentation & Learnings .claude/context/services-catalog.md, .claude/learnings/env-tier-consolidation-2025-12.md	Adds GPU & Compute Services (GPU Orchestrator, E2B Runner) and External Integrations sections (Firefly III, wger, Jellyfin) to services catalog. Introduces new learnings document detailing 6-tier architecture patterns, YAML anchors, secrets isolation rules, and testing guidance.
Docker Compose Core Configuration pmoves/docker-compose.yml	Enforces required PostgreSQL password. Updates image tags to explicit versions (postgrest/postgrest:v12.2.3, minio, tensorzero-related images). Adds extensive healthcheck blocks across services with interval, timeout, retry, and start_period configurations. Introduces NVIDIA_VISIBLE_DEVICES environment variables and GPU device reservations for GPU-enabled services. Updates NATS command from ["-js"] to ["-js", "-m", "8222"]. Expands health verification across database, search, datastores, gateways, and microservices.
Environment Tier Examples pmoves/env.tier-api.example, pmoves/env.tier-media.example, pmoves/env.tier-worker.example	Adds gpu-orchestrator to API tier services. Creates new Media tier configuration with NATS, MinIO, Supabase, FFmpeg-Whisper, YOLO, and indexer settings. Introduces Worker tier configuration with TensorZero, Qdrant, Meilisearch, MinIO, Supabase, and Open Notebook defaults.
Media Audio Service Runtime pmoves/services/media-audio/Dockerfile	Replaces base image from python:3.11-slim to nvidia/cuda:12.4.1-runtime-ubuntu22.04. Adds system dependencies (ffmpeg, libsndfile1, ca-certificates, curl) and Python 3.11 configuration. Implements explicit pip upgrade and constrained dependency installation. Creates non-root user (pmoves, uid/gid 65532) with video group permissions. Exposes port 8082 and configures uvicorn server startup.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

• fix(security): GPU access + production hardening (health checks, image pins, required password) #355 — Implements identical GPU access configuration (NVIDIA_VISIBLE_DEVICES, device reservations), NVIDIA CUDA media-audio base image, required POSTGRES_PASSWORD, and expanded healthchecks across the same compose services.
• refactor(env): Phase 1 - Migrate data tier to env-tier-data anchor #349 — Adds GPU-related services (gpu-orchestrator, pmz-e2b-runner) to docker-compose.yml and introduces tiered env anchors with env.tier example files.
• fix(docker): correct build contexts and requirements.lock references #348 — Modifies gpu-orchestrator and pmz-e2b-runner service configurations in docker-compose.yml, updates hi-rag-gateway-gpu settings, and adjusts Dockerfile build contexts and requirements.lock handling.

Poem

🐇 A GPU garden grows so bright,
With CUDA soil and health-checks tight,
Tiers of config, neatly stacked,
NVIDIA bless this Docker-backed stack! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main changes: GPU access fixes, security hardening with required POSTGRES_PASSWORD, health checks, and image pinning.
Description check	✅ Passed	The description includes a clear summary of changes, breaking changes warning, and a partial test plan. The summary section and testing requirements are provided with good detail, though some optional sections are missing.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0246ecf and 212befc.

📒 Files selected for processing (1)

• pmoves/docker-compose.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 3

Caution

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

⚠️ Outside diff range comments (2)

pmoves/docker-compose.yml (2)

905-905: Redundant GPU configuration in hi-rag-gateway-v2-gpu.

The service specifies GPU access using three different methods:

• runtime: nvidia (line 905) - legacy Docker runtime
• gpus: all (line 949) - docker-compose v1.28+ shorthand
• deploy.resources.reservations.devices (lines 950-955) - Compose Specification format

Docker Compose only needs ONE method. Mixing methods can cause conflicts or unexpected behavior. The deploy.resources.reservations format is the current standard and is already used by all other GPU services in this file.

🔎 Proposed fix to use consistent GPU configuration

     runtime: nvidia
     restart: unless-stopped
     command: [ "uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8086" ]
-    runtime: nvidia
     restart: unless-stopped
     command: [ "uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8086" ]
     env_file: [ env.shared.generated, env.shared, .env.generated, .env.local ]
     environment:
       # ... environment variables ...
       - NVIDIA_DRIVER_CAPABILITIES=${NVIDIA_DRIVER_CAPABILITIES:-compute,utility}
       - NVIDIA_VISIBLE_DEVICES=${NVIDIA_VISIBLE_DEVICES:-all}
-    gpus: all
     deploy:
       resources:
         reservations:
           devices:
             - capabilities: [ gpu ]
               count: ${GPU_COUNT:-all}

Note: Also noticed the runtime: nvidia appears twice at line 905 (duplicate line).

Also applies to: 949-955

---

676-703: Add multi-arch build support and Trivy scanning to media-audio Dockerfile.

The CUDA base image is correctly set to nvidia/cuda:12.4.1-runtime-ubuntu22.04, and GPU configuration in docker-compose.yml (lines 689-694) is properly set. However, per multi-arch build requirements, the Dockerfile must support both amd64 and arm64 architectures using ARG BUILDPLATFORM and ARG TARGETPLATFORM statements in the FROM directive. Additionally, the build process should include Trivy scanning to detect HIGH/CRITICAL vulnerabilities. Apply the same multi-arch pattern used in media-video and ensure docker-compose.yml includes Trivy scanning integration.

🧹 Nitpick comments (1)

pmoves/docker-compose.yml (1)

5-49: Document tier-based environment file structure and consider .env.local security implications.

The tier-based environment file approach implements least privilege well by separating credentials by service tier. However:

1. .env.local is included in ALL tier anchors, potentially granting broader access than intended if it contains sensitive credentials.
2. Missing documentation on which environment variables belong in which tier file (e.g., env.tier-data vs env.tier-api vs env.tier-llm).

Consider:

• Creating example/template files: env.tier-data.example, env.tier-api.example, etc., documenting which variables belong in each tier.
• Documenting that .env.local should only contain non-sensitive local overrides, or splitting it into tier-specific local override files like .env.local.data, .env.local.api.

Based on learnings and coding guidelines, verify that the tier-based approach is documented in service READMEs and pmoves/docs/PMOVES.AI PLANS/ runbooks.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a5c214e and 281b52e.

📒 Files selected for processing (1)

• pmoves/docker-compose.yml

🧰 Additional context used

📓 Path-based instructions (1)

pmoves/**/docker-compose.yml

📄 CodeRabbit inference engine (pmoves/AGENTS.md)

Use Compose profiles (data, workers) to scope what runs locally in docker-compose.yml

Files:

• pmoves/docker-compose.yml

🧠 Learnings (6)

📓 Common learnings

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: GEMINI.md:0-0
Timestamp: 2025-12-07T11:03:07.638Z
Learning: Applies to **/pmoves/**/{media,analysis,pipeline}*.py : Implement `media-video` and `media-audio` analysis pipelines with GPU auto-detect for faster-whisper

📚 Learning: 2025-12-15T12:03:17.291Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T12:03:17.291Z
Learning: Applies to services/**/README.md : Update services/*/README.md and pmoves/docs/PMOVES.AI PLANS/ runbooks when touching service operational code

Applied to files:

• pmoves/docker-compose.yml

📚 Learning: 2025-12-15T12:03:17.291Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T12:03:17.291Z
Learning: Applies to {Dockerfile,docker-compose.yml,docker-compose.*.yml,pmoves/docker-compose.*.override.yml} : Dockerfile and docker-compose.yml must follow multi-arch build practices (amd64+arm64) with Trivy scanning for HIGH/CRITICAL vulnerabilities

Applied to files:

• pmoves/docker-compose.yml

📚 Learning: 2025-12-15T12:03:17.291Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T12:03:17.291Z
Learning: Mandatory context before changes: read pmoves/docs/PMOVES.AI PLANS/ROADMAP.md and pmoves/docs/NEXT_STEPS.md to align with current sprint focus

Applied to files:

• pmoves/docker-compose.yml

📚 Learning: 2025-12-07T11:03:53.415Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: pmoves/AGENTS.md:0-0
Timestamp: 2025-12-07T11:03:53.415Z
Learning: Applies to pmoves/**/docker-compose.yml : Use Compose profiles (`data`, `workers`) to scope what runs locally in docker-compose.yml

Applied to files:

• pmoves/docker-compose.yml

📚 Learning: 2025-12-15T12:03:17.291Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T12:03:17.291Z
Learning: Agents/Archon: for full-stack validation, follow the 'All Services Up, Then Tests' section in pmoves/docs/SMOKETESTS.md and the Archon service guide

Applied to files:

• pmoves/docker-compose.yml

🔇 Additional comments (4)

pmoves/docker-compose.yml (4)

59-59: Excellent security improvement - enforcing required POSTGRES_PASSWORD.

The use of ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required} syntax correctly prevents the stack from starting with default or missing database credentials. This eliminates a common security misconfiguration.

Also applies to: 78-78, 937-937

---

64-64: Excellent use of Compose profiles for service scoping.

The profile structure (data, workers, orchestration, agents, gpu, tensorzero, etc.) follows the coding guidelines and allows fine-grained control over which services run locally. This makes it easy to:

• Run just the data tier: docker-compose --profile data up
• Run worker services: docker-compose --profile workers up
• Run GPU-accelerated services: docker-compose --profile gpu up
• Run specific stacks like TensorZero or Invidious

Services appropriately use multiple profiles where needed (e.g., MinIO in data, orchestration, workers, agents).

As per coding guidelines, Compose profiles (data, workers) are used to scope what runs locally in docker-compose.yml.

Also applies to: 84-84, 171-171, 203-203, 230-230, 254-254, 273-273, 308-308, 334-334, 366-366, 397-397, 428-428, 452-452, 480-480, 508-508, 552-552, 636-636, 667-667, 696-696, 735-735, 749-749, 777-777, 826-826, 880-880, 957-957, 994-994, 1022-1022, 1061-1061, 1246-1246, 1282-1282, 1307-1307, 1376-1376, 1394-1394, 1411-1411, 1437-1437, 1467-1467, 1488-1488, 1516-1516, 1543-1543, 1567-1567, 1610-1610, 1625-1625, 1646-1646, 1677-1677

---

1024-1029: Verify NATS monitoring port is exposed.

The health check attempts to reach http://localhost:8222/healthz, which is NATS's HTTP monitoring port. The service definition at line 1018 only exposes port 4222 (NATS client port). Verify that:

1. NATS image nats:2.10-alpine exposes port 8222 by default for monitoring, or
2. Port 8222 needs to be added to the ports section if external health checks are required.

#!/bin/bash
# Description: Verify NATS monitoring port configuration

# Check if NATS exposes port 8222 for monitoring by default
echo "Checking NATS 2.10-alpine image for exposed ports..."
docker pull nats:2.10-alpine 2>/dev/null
docker inspect nats:2.10-alpine | jq -r '.[0].Config.ExposedPorts | keys[]'

# Search for NATS health check patterns in codebase
echo -e "\nSearching for NATS monitoring port usage in codebase..."
rg -n "8222" --type yaml -g "docker-compose*.yml"

---

73-73: Good practice: Image version pinning for reproducibility and security.

Pinning images to explicit versions (postgrest:v12.2.3, minio:RELEASE.2024-12-18T13-15-44Z, ollama:0.5.4, tensorzero:2024.12.18, invidious:2024.12.09, grayjay:2024.11.01) prevents unexpected changes from :latest tags and makes deployments reproducible.

Also applies to: 104-104, 163-163, 1421-1421, 1471-1471, 1500-1500, 1547-1547, 1571-1571, 1635-1635

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Inconsistent GPU count configuration in gpu-orchestrator.

The gpu-orchestrator service hardcodes count: 1 while other GPU services use count: ${GPU_COUNT:-all} (e.g., ffmpeg-whisper line 634, media-video line 665, media-audio line 694). This inconsistency could cause issues in multi-GPU environments where users want centralized GPU allocation control via the GPU_COUNT variable.

🔎 Proposed fix to use GPU_COUNT variable

     deploy:
       resources:
         reservations:
           devices:
             - driver: nvidia
-              count: 1
+              count: ${GPU_COUNT:-1}
               capabilities: [ gpu ]

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	deploy:
	resources:
	reservations:
	devices:
	- driver: nvidia
	count: 1
	capabilities: [ gpu ]
	deploy:
	resources:
	reservations:
	devices:
	- driver: nvidia
	count: ${GPU_COUNT:-1}
	capabilities: [ gpu ]

🤖 Prompt for AI Agents

In pmoves/docker-compose.yml around lines 1000 to 1006, the gpu-orchestrator
service hardcodes GPUs with `count: 1` while other GPU services use the
environment variable `${GPU_COUNT:-all}`; change the hardcoded `count: 1` to
`count: ${GPU_COUNT:-all}` (or the project-standard variable) so
gpu-orchestrator follows the centralized GPU_COUNT setting, maintaining
consistent multi-GPU behavior across services.

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

pmoves/docker-compose.yml (1)

1002-1008: gpu-orchestrator still uses hardcoded GPU count.

This issue was previously flagged: gpu-orchestrator hardcodes count: 1 while other GPU services use count: ${GPU_COUNT:-all}. This inconsistency prevents centralized GPU allocation control.

🧹 Nitpick comments (1)

pmoves/docker-compose.yml (1)

512-518: Inconsistent GPU count in ultimate-tts-studio.

The ultimate-tts-studio service hardcodes count: 1 while most other GPU services use count: ${GPU_COUNT:-all} (e.g., media-video line 667, media-audio line 696). Consider using the GPU_COUNT variable for consistency.

🔎 Proposed fix for consistency

     deploy:
       resources:
         reservations:
           devices:
             - driver: nvidia
-              count: 1
+              count: ${GPU_COUNT:-1}
               capabilities: [ gpu ]

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 281b52e and 0246ecf.

📒 Files selected for processing (1)

• pmoves/docker-compose.yml

🧰 Additional context used

📓 Path-based instructions (1)

pmoves/**/docker-compose.yml

📄 CodeRabbit inference engine (pmoves/AGENTS.md)

Use Compose profiles (data, workers) to scope what runs locally in docker-compose.yml

Files:

• pmoves/docker-compose.yml

🧠 Learnings (4)

📓 Common learnings

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: GEMINI.md:0-0
Timestamp: 2025-12-07T11:03:07.638Z
Learning: Applies to **/pmoves/**/{media,analysis,pipeline}*.py : Implement `media-video` and `media-audio` analysis pipelines with GPU auto-detect for faster-whisper

📚 Learning: 2025-12-07T11:03:53.415Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: pmoves/AGENTS.md:0-0
Timestamp: 2025-12-07T11:03:53.415Z
Learning: Applies to pmoves/services/{agent-zero,archon}/**/*.py : For Agents/Archon full-stack validation, follow the 'All Services Up, Then Tests' section in `pmoves/docs/SMOKETESTS.md` and use `make -C pmoves agents-headless-smoke`, `make -C pmoves smoke-gpu`, and `make -C pmoves verify-all`

Applied to files:

• pmoves/docker-compose.yml

📚 Learning: 2025-12-07T11:03:53.415Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: pmoves/AGENTS.md:0-0
Timestamp: 2025-12-07T11:03:53.415Z
Learning: Applies to pmoves/**/docker-compose.yml : Use Compose profiles (`data`, `workers`) to scope what runs locally in docker-compose.yml

Applied to files:

• pmoves/docker-compose.yml

📚 Learning: 2025-12-15T12:03:17.291Z

Learnt from: CR
Repo: POWERFULMOVES/PMOVES.AI PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T12:03:17.291Z
Learning: Agents/Archon: for full-stack validation, follow the 'All Services Up, Then Tests' section in pmoves/docs/SMOKETESTS.md and the Archon service guide

Applied to files:

• pmoves/docker-compose.yml

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Analyze (python)

🔇 Additional comments (15)

pmoves/docker-compose.yml (15)

59-59: Good security improvement - POSTGRES_PASSWORD now required.

The required password syntax prevents deployments with unset credentials. The implementation is consistent across all three usages.

Also applies to: 78-78, 939-939

---

66-71: LGTM - postgres health check start_period added.

The 15s start period gives postgres adequate initialization time before health checks begin.

---

123-128: LGTM - data tier health checks are appropriate.

Health checks for qdrant, meilisearch, and minio use correct endpoints and reasonable timing parameters. The MinIO check correctly uses curl instead of mc which is not available in the image.

Also applies to: 138-143, 174-179

---

1020-1031: LGTM - NATS monitoring port enables health checks.

The -m 8222 flag enables the HTTP monitoring endpoint, which the health check correctly uses. This is a proper operational improvement.

---

311-317: Health check improved to verify module imports.

The health check now verifies that the watcher module and its dependencies can be imported. While this doesn't test runtime connectivity to NATS/MinIO, it catches missing dependencies and import errors at the Docker health check level.

---

1251-1257: Health check improved to verify main module and NATS client availability.

The health check now imports the main module and verifies the NATS client is available, catching dependency and configuration issues at startup.

---

340-345: LGTM - worker service health checks are well-configured.

All worker services use appropriate /healthz endpoints with consistent timing. GPU-enabled workers (ffmpeg-whisper, media-video, media-audio) correctly use longer start periods (60s) to account for GPU initialization.

Also applies to: 370-375, 401-406, 431-436, 456-461, 484-489, 640-645, 671-676, 700-705

---

213-218: LGTM - API service health checks are properly configured.

All API services use appropriate health endpoints with reasonable timing. The GPU-enabled v2 gateway correctly uses a 90s start period to accommodate model loading time.

Also applies to: 235-240, 257-262, 279-284, 558-563, 739-744, 753-758, 781-786, 836-841, 891-896, 970-975

---

1065-1072: LGTM - agent service health checks are appropriate.

Agent services use proper health endpoints with consistent timing. Agent-zero correctly uses a longer 60s start period and includes host.docker.internal access for external API calls.

Also applies to: 1291-1296, 1313-1318, 1383-1388, 1401-1406, 1418-1423

---

1448-1453: LGTM - TensorZero stack health checks are well-configured.

Ollama, gateway, and UI services all have appropriate health endpoints. Ollama correctly uses a 60s start period for GPU initialization.

Also applies to: 1497-1502, 1523-1530

---

1543-1548: LGTM - invidious-db health check start_period added.

The 15s start period is consistent with the main postgres service and gives adequate initialization time.

---

1633-1638: LGTM - Grayjay service health checks are appropriate.

Both plugin-host and server use suitable health endpoints with reasonable timing parameters.

Also applies to: 1654-1659

---

1210-1215: LGTM - E2B runner health check start_period added.

The 30s start period completes the health check configuration with a reasonable initialization window.

---

1336-1341: LGTM - consciousness-service health check start_period added.

The 30s start period appropriately completes the health check configuration.

---

74-74: Compose profiles already properly used; verify tensorzero/gateway version.

Image pinning is correct—all 8 images use specific versions instead of :latest. Compose profiles (data, workers, etc.) are already extensively used throughout the file, meeting the guideline requirement. However, the tensorzero/gateway:2024.12.18 tag could not be verified; confirm this version exists on Docker Hub or update to a verified release tag.

Also applies to: 74-74, 105-105, 164-164, 1426-1426, 1476-1476, 1505-1505, 1553-1553, 1577-1577, 1641-1641