docker-compose.yml

# No `version:` key — it has been obsolete since Compose v2 and only earns a
# deprecation warning on every invocation.
#
# Profiles: `docker compose up` starts the application and nothing else. The
# services that are tooling rather than application sit behind profiles, so they
# neither start nor get rebuilt unless asked for:
#
#   docker compose up                        the app: fpm, nginx, workers, valkey
#   docker compose --profile test up -d      adds selenium, for the dusk suite
#   docker compose --profile tools up node   runs the asset watcher
#
# `assets` is not behind a profile: fpm and nginx both depend on it completing
# successfully, so a plain `docker compose up` always builds
# public/build/manifest.json before either one starts, however stale or
# missing it was on disk. It is a one-shot `npm run build`, not the watcher —
# that stays the `node` service under `tools`, for iterating with `npm run
# watch` or `npm test` running.
#
# `docker compose run` starts a profiled service without naming its profile, so
# the one-shot invocations in CLAUDE.md keep working unchanged:
#
#   docker compose run --rm --no-deps -T --entrypoint /usr/local/bin/npm node run build
#   docker compose run --rm --entrypoint /usr/bin/composer composer install

# Volumes
volumes:
  composer_cache: {}
  node_cache: {}

# Services
services:
  fpm:
    image: metager:latest
    build:
      context: ./
      dockerfile: build/fpm/Dockerfile
      target: ${APP_ENV}
    pull_policy: never
    restart: unless-stopped
    depends_on:
      assets:
        condition: service_completed_successfully
      # Nothing user-facing works without it — the authorization path and the
      # search path's Redis::brpop both reach it directly, cache store aside
      # (see CLAUDE.md's "Running things"). Declared here rather than left to
      # convention, so `docker compose run fpm ...` starts it too, not just a
      # plain `up`.
      valkey:
        condition: service_healthy
    networks:
      - metager
    volumes:
      - ./metager:/metager/metager_app
    extra_hosts:
      - "host.docker.internal:host-gateway"
    healthcheck:
      test: "curl -f http://nginx:8080/health-check/liveness"
  nginx:
    image: metager_nginx:latest
    build:
      context: ./
      dockerfile: build/nginx/Dockerfile
      target: ${APP_ENV}
    restart: unless-stopped
    depends_on:
      assets:
        condition: service_completed_successfully
      fpm:
        condition: service_started
      reverb:
        condition: service_started
    networks:
      - metager
    volumes:
      - ./metager/public:/metager/metager_app/public
    ports:
      - 8080:8080
    healthcheck:
      test: "curl -f http://nginx:8080/health-check/nginx"
  scheduler:
    image: metager:latest
    pull_policy: never
    restart: unless-stopped
    entrypoint: /usr/local/bin/php
    command: artisan schedule:work-mg
    # SchedulerHeartbeat reads its stamp with Redis::get directly — see fpm's
    # depends_on above.
    depends_on:
      valkey:
        condition: service_healthy
    networks:
      - metager
    volumes:
      - ./metager:/metager/metager_app
    extra_hosts:
      - "host.docker.internal:host-gateway"
    healthcheck:
      test: "curl -f http://nginx:8080/health-check/liveness-scheduler"
  queue:
    image: metager:latest
    pull_policy: never
    restart: unless-stopped
    entrypoint: /usr/local/bin/php
    # `broadcasts` is App\Events\KeyChanged's own queue (config/broadcasting.php).
    # One worker covers it here because the compose stack runs QUEUE_CONNECTION=redis
    # for everything, so the broadcast connection and the default are the same one.
    # The chart cannot do that — there the default is `database` — and runs a second
    # worker for this queue instead; see chart/templates/deployment-queue.yaml.
    command: artisan queue:work --backoff=60 --tries=5 --sleep=1 --queue=donations,default,general,broadcasts
    # The queue connection this actually drains outside of testing is
    # Redis-backed — see fpm's depends_on above.
    depends_on:
      valkey:
        condition: service_healthy
    networks:
      - metager
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - ./metager:/metager/metager_app
    healthcheck:
      test: ["CMD", "pgrep",  "-f", "queue:work"]
  worker:
    image: metager:latest
    pull_policy: never
    restart: unless-stopped
    entrypoint: /usr/local/bin/php
    command: artisan requests:fetcher
    # Fetches upstream results and pushes them back onto Redis — see "Search
    # request flow" in CLAUDE.md and fpm's depends_on above.
    depends_on:
      valkey:
        condition: service_healthy
    networks:
      - metager
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - ./metager:/metager/metager_app
    healthcheck:
      test: ["CMD", "pgrep",  "-f", "requests:fetcher"]
  reverb:
    image: metager:latest
    build:
      context: ./
      dockerfile: build/fpm/Dockerfile
      target: ${APP_ENV}
    pull_policy: never
    restart: unless-stopped
    entrypoint: /usr/local/bin/php
    command: artisan reverb:start --debug
    # Same reasoning as fpm's depends_on above.
    depends_on:
      valkey:
        condition: service_healthy
    # The metager image inherits STOPSIGNAL SIGQUIT from the php-fpm base image
    # (it is the right default for the fpm service, which does run php-fpm).
    # Reverb is a plain PHP process, not fpm, and only subscribes to
    # SIGINT/SIGTERM/SIGTSTP (Laravel\Reverb's StartServer::getSubscribedSignals())
    # — SIGQUIT is not among them, so without this override `docker compose
    # stop`/`down` send a signal Reverb never handles and it hangs until
    # forcibly SIGKILLed at the end of the grace period.
    stop_signal: SIGTERM
    networks:
      - metager
    volumes:
      - ./metager:/metager/metager_app
    extra_hosts:
      - "host.docker.internal:host-gateway"
    healthcheck:
      test: ["CMD", "pgrep",  "-f", "reverb:start"]
  # Only the browser suite needs this, and it is a 2 GB-shm container that pulls
  # a full Firefox image. See CLAUDE.md for the dusk workflow.
  selenium_standalone_firefox:
    image: ${SELENIUM_IMAGE}
    profiles: ["test"]
    restart: always
    shm_size: 2GB
    networks:
      - metager
    ports:
      - "7900:7900"
  composer:
    image: metager:latest
    profiles: ["tools"]
    pull_policy: never
    entrypoint: /usr/bin/composer
    command: install
    environment:
      - COMPOSER_HOME=/composer_cache
    networks:
      - metager
    volumes:
      - ./metager:/metager/metager_app
      - composer_cache:/composer_cache

  # One-shot asset build that fpm and nginx depend on (see the note at the top
  # of this file). Always the `production` Dockerfile target — build-then-exit
  # — regardless of local APP_ENV, because `depends_on: condition:
  # service_completed_successfully` needs the container to actually exit 0;
  # the `development` target runs `npm run watch` and never would.
  assets:
    build:
      context: ./
      dockerfile: build/node/Dockerfile
      target: production
    pull_policy: never
    restart: "no"
    environment:
      # Source maps stay on for a local build regardless of target — see the
      # same setting on `node` below.
      APP_ENV: local
    networks:
      - metager
    volumes:
      - ./metager:/home/node/metager
      - node_cache:/home/node/.npm

  node:
    build:
      context: ./
      dockerfile: build/node/Dockerfile
      target: $APP_ENV
    profiles: ["tools"]
    # NOT `unless-stopped`. Whether this process is long-lived depends on the
    # Dockerfile target: the development entrypoint runs `npm run watch` and
    # stays up, but the production one runs `npm run build` and exits 0 — which
    # under `unless-stopped` was restarted immediately, rebuilding the assets
    # forever. `on-failure` restarts a watcher that crashed and lets a completed
    # build stay completed.
    restart: on-failure
    stop_signal: SIGKILL
    environment:
      # A local build is never the production deployment, whatever APP_ENV in
      # your .env says — that value only picks the Dockerfile target above, and
      # running the production target locally is a way to check the production
      # build, not to serve it. Pinning it here keeps the source maps on for
      # every local build; vite.config.js drops them only for APP_ENV=production.
      APP_ENV: local
    networks:
      - metager
    volumes:
      - ./metager:/home/node/metager
      - node_cache:/home/node/.npm
  # Valkey, matching the version the Helm chart deploys (chart/Chart.yaml pins
  # cloudpirates/valkey, appVersion 9.1.0) so local behaviour matches production.
  #
  # The service is named `valkey`, but answers to `redis` on the network too: a
  # developer's metager/.env is gitignored and will still say REDIS_HOST=redis,
  # and there is no reason to make everyone edit it. .env.example names the new
  # one for fresh checkouts.
  valkey:
    image: valkey/valkey:9.1.3-alpine
    restart: unless-stopped
    user: "valkey:valkey"
    networks:
      metager:
        aliases:
          - redis
    healthcheck:
      test: "valkey-cli ping"
networks:
  metager:
    name: metager_net
    ipam:
      driver: default
      config:
        - subnet: "192.168.5.0/24"