# 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 secrets: # REQUIRED - op:// item path for the 1Password operator, carrying the fields # "hardcover-api-token" and "calibre-plugins". Both are needed even if you # never use Hardcover: the OnePasswordItem is created unconditionally, and so # are the environment reference and the volume. Without this value the render # aborts - required() in calibre-web-automated.secret.yaml is the whole # enforcement, and values.schema.json cannot help here (README, guideline 12). # Before the guard existed it produced an OnePasswordItem with an empty # itemPath, the operator had nothing to resolve, the Secret never appeared and # the pod could not start. cwaSecretRef: null cwa: # Replica count for this workload; 0 is allowed and scales it down. # The chart-global scaleDown flag takes precedence. replicas: 1 storage: 10Gi storageClass: longhorn timezone: "UTC" # The upload cap, and it lives entirely in the INGRESS: the chart renders it # into nginx.ingress.kubernetes.io/proxy-body-size and # nginx.org/client-max-body-size, so it is enforced by the nginx-family # controllers and by nothing inside CWA. Consequences worth knowing before # trusting it: with ingress.enabled: false it does nothing at all, and in # Gateway mode (httpRoute.enabled) it is NOT ENFORCED either - the Gateway # API has no body-size field, the limit is the Gateway's own, and this chart # deliberately renders no implementation-specific policy object to set it # (Gitea #114). NOTES.txt says so in both modes. maxUploadFileSize: "10m" livenessProbe: httpGet: path: / port: http periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: / port: http periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 # The startup probe gates liveness/readiness. Startup budget = 10s * 30 = 300s. startupProbe: httpGet: path: / port: http 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: 512Mi ephemeralStorage: 100Mi # Documented deviation from the repo-wide hardening standard: the CWA image # (linuxserver.io-style) must start as root — it boots via the s6-overlay # init system, whose stage-1/2 setup runs as uid 0 and then drops the app # to the PUID/PGID user (1000), so runAsNonRoot/runAsUser are deliberately # not set (s6 supervisors stay root, the application runs as uid 1000). # readOnlyRootFilesystem is deliberately false: in read-only mode the image # disables the PUID/PGID remapping (the runtime uid would silently change # from 1000 to the built-in 911 and break existing volume data) and its # init fails to write the ImageMagick policy under /etc. Everything else # is hardened: no privilege escalation and all capabilities dropped except # the minimal set the s6 init/supervision needs (verified against v4.0.6): # CHOWN/DAC_OVERRIDE/FOWNER/SETGID/SETUID for the ownership fix-up of # /config etc. and the root->PUID drop, KILL so the root supervisor can # signal the uid-1000 services (without it the pod cannot shut down # cleanly and gets SIGKILLed). securityContext: pod: fsGroup: 1000 fsGroupChangePolicy: Always # RuntimeDefault applies the container runtime's default seccomp filter, # which blocks the syscalls a normal workload never makes. It sits in the # pod context on purpose: from here it covers every container in the pod # including init containers, while a container-level seccompProfile would # have to be repeated for each one (and silently missed on the next one # added). A container that genuinely needs a different filter can still # override it under securityContext.container, which wins over this value. # # It is orthogonal to the readOnlyRootFilesystem: false deviation above: # the filter restricts syscalls, not mount flags, so the s6 init keeps # its writable root filesystem and the PUID/PGID remapping to uid 1000 # stays active. Verified against v4.0.6 under the filter. seccompProfile: type: RuntimeDefault container: allowPrivilegeEscalation: false readOnlyRootFilesystem: false capabilities: drop: - ALL add: - CHOWN - DAC_OVERRIDE - FOWNER - KILL - SETGID - SETUID # Extra environment variables, appended to the ones the chart always sets. # Rendered through tpl; value, secretKeyRef and configMapKeyRef forms are # supported (see template-chart). env: [] ingress: # Set to false to omit the Ingress entirely. Nothing inside the pod reads # ingress.domain - no environment variable, no probe Host header, no URL the # app builds itself - so with the Ingress off, clusterIssuer and domain are # both unnecessary. That is still true, but no longer the whole sentence: # the HTTPRoute below is a SECOND reader of ingress.domain (while # httpRoute.hostnames is empty), so "domain is not needed" holds only while # BOTH routing modes are off. # # Mutually exclusive with httpRoute.enabled below (Gitea #114): with both # true the render aborts, naming both values. enabled: true clusterIssuer: null # The public hostname of this release. Read by the Ingress and - when # httpRoute.hostnames is empty - by the HTTPRoute, and by nothing else. domain: null className: nginx # Extra annotations for the Ingress; merged with the cert-manager # cluster-issuer and proxy-body-size annotations the chart always sets. # # THESE HAVE NO COUNTERPART IN GATEWAY MODE. The Gateway API has no # annotation channel for controller behaviour, so anything configured here is # simply gone when httpRoute.enabled is used instead - it is then the # Gateway's business, or that of an implementation-specific policy object # this chart deliberately does not render. For THIS chart that includes the # upload cap: see cwa.maxUploadFileSize above. annotations: {} # Gateway-API alternative to the Ingress above (Gitea #114). Off by default, so # an existing release is unaffected; exactly one of ingress.enabled and # httpRoute.enabled may be true. # # The chart renders ONLY an HTTPRoute with parentRefs - no Gateway, no # gatewayClassName, no Certificate and no implementation-specific policy # object. Class and certificate belong to the Gateway and therefore to the # platform, which is what keeps this chart independent of whether the cluster # runs nginx-gateway-fabric, Cilium, Envoy Gateway or Istio. # # WHAT THIS MODE COSTS HERE: cwa.maxUploadFileSize is not enforced. It exists # only as an ingress-nginx annotation and the Gateway API has no body-size # field, so the limit becomes whatever the Gateway enforces. For an e-book # library that is the one value worth checking before switching - a book above # the Gateway's default is rejected by the proxy, and nothing in CWA's log says # a chart value was ignored. NOTES.txt prints this in Gateway mode. # # The Gateway-API CRDs must be installed in the cluster: the chart does not and # cannot detect them (.Capabilities.APIVersions is unreliable at template # time), so with httpRoute.enabled: true and no CRDs the INSTALL fails. httpRoute: enabled: false # The Gateway(s) this route attaches to - a platform object, usually in # another namespace, which must allow this namespace in its listener's # allowedRoutes. One entry per parent, the fields are the Gateway API's # ParentReference (name, and optionally namespace, sectionName, port, group, # kind), passed through unchanged: # # parentRefs: # - name: public # namespace: gateway # sectionName: https # # REQUIRED while httpRoute.enabled is true - the render aborts on an empty # list, because a route without a parent is created, is valid and routes # nothing, with no event to say so. parentRefs: [] # Empty means [ingress.domain], so the hostname has one source of truth. Set # explicitly only to publish under a different or an additional name - which # is how a migration from the Ingress runs: the HTTPRoute takes a second # hostname while the Ingress keeps ingress.domain. # # Cheap in this chart, because nothing inside the pod follows the hostname: # CWA is told its address by nothing, so a second name needs no second value # changed with it. hostnames: []