# Scale the whole chart down without uninstalling it: scaleDown: true renders
# every Deployment/StatefulSet with replicas: 0 (and suspends CronJobs) and
# takes precedence over any per-workload replicas value. PVCs, Secrets and
# Services stay in place; scaleDown: false brings the workloads back up.
scaleDown: false

config:
  storage: 50Gi
  storageClass: longhorn
  secretRef:
    db: null
    zipline: null
  domain: null
  maxUploadFileSize: 30m
zipline:
  # Replica count for this workload; 0 is allowed and scales it down.
  # The chart-global scaleDown flag takes precedence.
  replicas: 1
  # The upstream image ships no dedicated user, but the Node.js server runs
  # fine as an arbitrary non-root uid; fsGroup makes the uploads PVC writable.
  securityContext:
    pod:
      runAsNonRoot: true
      runAsUser: 1000
      runAsGroup: 1000
      fsGroup: 1000
      fsGroupChangePolicy: Always
    container:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      capabilities:
        drop:
          - ALL
  # Zipline v4 exposes /api/healthcheck (checks server and database health);
  # the endpoint is enabled by default (config.features.healthcheck). Since it
  # includes the database, it is used for readiness/startup only; liveness
  # uses "/" so a database outage does not restart the pod.
  livenessProbe:
    httpGet:
      path: /
      port: zipline-server
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3
  readinessProbe:
    httpGet:
      path: /api/healthcheck
      port: zipline-server
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3
  # The startup probe gates liveness/readiness. Zipline runs database
  # migrations on startup, so grant a generous budget: 10s * 30 = 300s.
  startupProbe:
    httpGet:
      path: /api/healthcheck
      port: zipline-server
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 30
  resources:
    # Limits are optional: memory and ephemeral-storage limits default to
    # limitFactor x the request, an explicitly set limit always wins, and a
    # CPU limit is only set when configured explicitly under "limits".
    limitFactor: 3
    requests:
      cpu: 0.1
      memory: 265Mi
      ephemeralStorage: 100Mi