services:
  ollama-piha:
    # Multi-arch image with a published linux/arm64 manifest — runs natively on
    # the Pi 5, no emulation (same mechanism as pgvector/pgvector:pg16 on PIHA).
    image: ollama/ollama:latest
    container_name: ollama-piha
    restart: unless-stopped
    environment:
      # PIHA is the RAM-bound 8 GB box shared with Home Assistant. bge-m3 must be
      # unloaded from RAM immediately after every call — a short spike per embed
      # (idle daemon ~100 MB), never a resident ~2 GB cost. Fallback traffic is
      # rare by design: kb-query only embeds here while SOLARIA sleeps.
      - OLLAMA_KEEP_ALIVE=0
    ports:
      # Loopback: healthcheck.sh + manual curl on the node itself.
      # LAN IP: kb-query runs in a separate compose project/network and reaches
      # this backend over the host's LAN interface — same reasoning as
      # kb-query -> kb-postgres (:5433). No 0.0.0.0, no Tailscale bind: nothing
      # off-node ever embeds here (SOLARIA-side callers use SOLARIA's own Ollama).
      # Requires .env (from env.example) next to this file at deploy.
      - "127.0.0.1:11434:11434"
      - "${LAN_BIND_IP}:11434:11434"
    volumes:
      # Named volume, NOT a bind mount: the ollama image runs as in-container
      # root and would fill a bind dir with root-owned files, breaking PIHA's
      # uid pattern (host oskar=1004, containers uid 1000 + setgid group pi).
      # Docker-managed volumes live under the data-root on the NVMe — same
      # convention as kb_postgres_data.
      - ollama_piha_models:/root/.ollama

volumes:
  ollama_piha_models:
    name: ollama_piha_models