# ${VAR} substitution below (DAYBOOK_BIND_ADDR, DAYBOOK_HOST_DATA_DIR) reads
# from deploy/.env because Compose resolves .env relative to *this file's*
# directory, not the caller's cwd. That relies on being invoked as
# `docker compose -f deploy/docker-compose.yml` from the repo root, per
# deploy/cloud_agent_deploy.md and docs/deployment.md. If that invocation
# pattern ever changes, re-verify these still resolve — a silent fallback to
# the defaults (0.0.0.0 bind, ./data) would be a security regression, not
# just a broken build.
services:
  daybook:
    build:
      context: ..
      dockerfile: deploy/Dockerfile
    container_name: daybook
    restart: unless-stopped
    env_file:
      - .env
    mem_limit: 384m
    mem_reservation: 128m
    ports:
      - "${DAYBOOK_BIND_ADDR:-0.0.0.0}:8000:8000"
    volumes:
      - ${DAYBOOK_HOST_DATA_DIR:-./data}:/data
    healthcheck:
      # Hit the login page, not /api/capabilities: capabilities returns 403
      # when unauthenticated, and `curl --fail` treats 403 as an error, which
      # would mark a perfectly healthy container unhealthy. The login page
      # serves 200 without auth and still proves Django is up and responding.
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8000/accounts/login/"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 20s