docker-compose.yml

services:
  # Dev defaults are safe to run locally. For production sizing see
  # deploy/docker-compose.prod.yml and DEPLOYMENT.md. Override resource limits
  # via COMPOSE_CPU_LIMIT / COMPOSE_MEMORY_LIMIT / COMPOSE_MEMORY_RESERVATION
  # environment variables.
  api:
    build: .
    ports:
      - "${PORT:-3000}:3000"
    env_file:
      - .env
    environment:
      # Override the DATABASE_URL to point at the persistent volume
      DATABASE_URL: sqlite:///data/stellargate.db
    volumes:
      - stellargate_data:/data
    restart: unless-stopped
    # Compose's own default (10s) is shorter than the app's own
    # SHUTDOWN_GRACE_SECS drain budget (default 30s) — see "Shutdown grace"
    # in DEPLOYMENT.md.
    stop_grace_period: 35s
    # Local/dev guardrails, not a tuned production ceiling — see "Resource
    # limits" in DEPLOYMENT.md. deploy/docker-compose.prod.yml has the
    # sizing that actually matters.
    deploy:
      resources:
        limits:
          cpus: "${COMPOSE_CPU_LIMIT:-2.0}"
          memory: "${COMPOSE_MEMORY_LIMIT:-1G}"
        reservations:
          memory: "${COMPOSE_MEMORY_RESERVATION:-256M}"
    logging:
      driver: json-file
      options:
        # Without a cap, container logs will eventually fill the disk — a
        # slow, surprising way to take the gateway down.
        max-size: "10m"
        max-file: "5"
    healthcheck:
      # /health is exempt from the per-IP rate limiter (see DEPLOYMENT.md), so
      # a traffic spike can never turn this into a 429 and restart the container.
      # The binary checks its own health, so no HTTP client is needed in the image.
      test: ["CMD", "/usr/local/bin/stellargate", "healthcheck", "health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s

volumes:
  stellargate_data: