873f8ad24c
Closes #22267 ## What Exposes `startupProbe`, `livenessProbe` and `readinessProbe` as configurable values under `server.*` in `values.yaml`, with sensible defaults that work out of the box on current Twenty releases. Also switches the probe path from `/` to `/healthz`. ## Why The probes are hardcoded in the chart template today, and the defaults are no longer realistic for the current product. On a clean install of `v2.16.1` the server takes about **111 seconds** to reach `Nest application successfully started`. The current hardcoded `livenessProbe` only gives the pod **110 seconds** before killing it (`initialDelaySeconds: 60` + `failureThreshold: 5` x `periodSeconds: 10`). The pod is killed roughly 1 second before it would have been healthy and the deployment enters `CrashLoopBackOff` indefinitely. Twenty's boot time grows release by release as new Nest modules are added (v2.16 already registers 16 minor versions worth of upgrade commands at startup), so the chart's hardcoded defaults will keep drifting away from a working configuration. The probe path `/` returns the SPA HTML (or a 404 depending on routing), not a health response. The correct endpoint is `/healthz`, which returns `{"status":"ok","info":{},"error":{},"details":{}}` from a dedicated Nest controller. ## How Uses the same `{{- with }}` pattern already present in the chart (`extraEnv`, `extraVolumeMounts`, and the four scheduling fields added in #22233): ```yaml {{- with .Values.server.startupProbe }} startupProbe: {{- toYaml . | nindent 12 }} {{- end }} {{- with .Values.server.livenessProbe }} livenessProbe: {{- toYaml . | nindent 12 }} {{- end }} {{- with .Values.server.readinessProbe }} readinessProbe: {{- toYaml . | nindent 12 }} {{- end }} ``` This pattern lets the user disable any probe by setting it to `null`, override individual fields by providing the full block, or fall back to the defaults shipped in `values.yaml`. ## Defaults ```yaml server: startupProbe: httpGet: path: /healthz port: http-tcp periodSeconds: 10 failureThreshold: 30 # 5 minutes total boot grace livenessProbe: httpGet: path: /healthz port: http-tcp periodSeconds: 30 failureThreshold: 3 readinessProbe: httpGet: path: /healthz port: http-tcp periodSeconds: 10 failureThreshold: 3 ``` ## Scope This PR only touches the server Deployment. The worker Deployment is intentionally out of scope: it does not expose HTTP, had no probes before this change, and any probe added there would need a different shape (`exec` or `tcpSocket`). It can be addressed in a follow-up if maintainers want it. ## Backward compatibility For any cluster that booted Twenty correctly with the previous defaults (boot time under 5 minutes), `helm template` output is functionally equivalent: the new `startupProbe` covers the boot window, then `livenessProbe` and `readinessProbe` take over with similar semantics. For clusters where the previous defaults were already failing (such as this one — see "Validation" below), the new defaults make the install work out of the box. Setting any probe value to `null` disables that probe entirely. ## Schema note `values.schema.json` updated with `startupProbe`, `livenessProbe` and `readinessProbe` under `server`, all typed as `["object", "null"]` to honour the disable-by-null contract. ## Validation - `helm lint` passes. - `helm template` with default values renders the three probe blocks on the server Deployment. - `helm template` with one probe set to `null` correctly omits that probe. - `helm template` with overridden values renders the user-supplied probe configuration. - Live install validated on a multi-node Kubernetes cluster running Twenty v2.16.1 on an Oracle Cloud ARM64 worker node. With the new `startupProbe` the server reaches `Ready 1/1` in around 2 minutes from fresh pod creation. With the previous hardcoded probes the same pod entered `CrashLoopBackOff` indefinitely (276 restarts in 21 hours observed before applying the fix). ```` ## Files touched - `packages/twenty-docker/helm/twenty/templates/deployment-server.yaml` - `packages/twenty-docker/helm/twenty/values.yaml` - `packages/twenty-docker/helm/twenty/values.schema.json` ## Related - Discovered while validating PR #22233 (nodeSelector / tolerations / DNS overrides). - Same chart, same pattern, same self-host audience. - Closes #22267. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22268?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>
Twenty Helm Chart
Deploy Twenty CRM on Kubernetes with server, worker, PostgreSQL, and Redis components.
Features
- Server and worker deployments with full env exposure via
values.yaml. - Internal PostgreSQL (Spilo) and Redis deployments included.
- PVC-based persistence using dynamic storage classes (no static PV manifests).
- Ingress with configurable annotations, hosts, and TLS.
- Database readiness and migrations handled by server/worker init containers by default. – Standard Kubernetes Jobs for DB creation/user and migrations have been removed to simplify installs. Readiness and migrations run in init containers.
Quick Start
See QUICKSTART.md for a simple 2-line install with your domain.
Installing
Prerequisites: Kubernetes 1.21+, Helm 3.8+, default StorageClass
Internal DB + Redis (default):
helm install my-twenty ./packages/twenty-docker/helm/twenty \
--namespace twentycrm --create-namespace
External DB/Redis:
helm install my-twenty ./packages/twenty-docker/helm/twenty \
--namespace twentycrm --create-namespace \
--set db.enabled=false \
--set db.external.host=db.example.com \
--set redisInternal.enabled=false
Key Values
See values.yaml for a comprehensive list.
Notes
- Database URL and Redis URL are composed automatically from chart settings
- Database
twentyand schemacoreare created automatically by server init container - No optional jobs: the chart no longer provides separate Jobs for DB or migrations.
- Access token auto-generated (32 chars) if not provided; reuses existing secret if present
- For production, provide a strong
secrets.tokens.accessTokenvalue via a secure values file; the auto-generated token is a convenience fallback.
- For production, provide a strong
- TLS enabled by default via cert-manager (
acme: true) - Requires default StorageClass for PVC provisioning
Testing
helm lint ./packages/twenty-docker/helm/twenty
helm template my-twenty ./packages/twenty-docker/helm/twenty
helm plugin install https://github.com/quintush/helm-unittest
helm unittest ./packages/twenty-docker/helm/twenty
Storage
Local (default): Uses PVCs for persistence
S3: Set storage.type=s3 and provide credentials using a values file. You can either pass credentials directly or reference an existing Kubernetes Secret.
# values-secrets.yaml (do not commit)
# storage:
# type: s3
# s3:
# bucket: my-bucket
# region: us-east-1
# # Option A: direct values
# accessKeyId: AKIA...
# secretAccessKey: ...
# # Option B: reference a Secret
# # secretName: my-s3-creds
# # accessKeyIdKey: accessKeyId
# # secretAccessKeyKey: secretAccessKey
helm install my-twenty ./packages/twenty-docker/helm/twenty -f values-secrets.yaml
Production Tips
- Image versioning: The chart defaults to
Chart.yaml'sappVersion(currently v1.14.0). Override viaimage.tagin values to pin a different version or uselatestfor rolling updates. - Keep secrets secure: Avoid
--setfor sensitive values; use-f values-secrets.yamlor reference existing Kubernetes Secrets viaserver.extraEnvFrom.- S3 credentials can be referenced via
storage.s3.secretName + accessKeyIdKey/secretAccessKeyKeyto avoid embedding them in pod specs.
- S3 credentials can be referenced via