# Staging overlay for InboxIntel.
#
# The base docker-compose.yml IS the production definition (Linux containers,
# ASPNETCORE_ENVIRONMENT=Production). This overlay layers a *staging* variant on
# top of it so you can run a production-shaped stack locally on Windows WITHOUT
# clobbering a real production deployment's data, ports, or volumes.
#
# It differs from prod only in the ways staging is meant to differ:
#   - the dev/test banner is on (App__DevMode=true)
#   - the initial Gmail sync is capped so a big mailbox doesn't take forever
#   - ports are shifted into the 18xxx range so staging can run alongside prod
#   - a distinct project name gives it its own isolated pgdata + keys volumes
#
# Run it with the -p (project name) flag so volumes/networks are namespaced:
#
#   docker compose -p inboxintel-staging \
#     --env-file deploy/.env.staging \
#     -f docker-compose.yml -f docker-compose.staging.yml up --build -d
#
# (deploy/up.ps1 -Staging / up.sh --staging wrap this for you.)

services:
  postgres:
    # !override replaces the base port list instead of merging with it, so staging
    # binds ONLY its shifted 18xxx/15432 ports and never squats on prod's 8080/8081.
    ports: !override
      - "127.0.0.1:15432:5432"

  api:
    environment:
      # Same Production runtime as prod (real config binding, real build), but
      # flagged as a non-production instance so the UI shows the staging banner
      # and the first sync is bounded.
      App__DevMode: "true"
      GmailSync__MaxMessages: ${MAX_MESSAGES:-2000}
      Cors__Origins__0: ${FRONTEND_ORIGIN:-http://localhost:18081}
    ports: !override
      - "127.0.0.1:18080:8080"

  frontend:
    ports: !override
      - "18081:80"

  nginx:
    ports: !override
      - "18000:80"