Files
twenty/packages/twenty-docker/helm/twenty
Miguel 873f8ad24c feat(helm): parametrize liveness, readiness and startup probes for server (#22268)
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>
2026-07-04 11:48:49 +02:00
..
2026-01-08 12:45:46 +00:00
2026-01-08 12:45:46 +00:00
2026-01-08 12:45:46 +00:00

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 twenty and schema core are 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.accessToken value via a secure values file; the auto-generated token is a convenience fallback.
  • 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's appVersion (currently v1.14.0). Override via image.tag in values to pin a different version or use latest for rolling updates.
  • Keep secrets secure: Avoid --set for sensitive values; use -f values-secrets.yaml or reference existing Kubernetes Secrets via server.extraEnvFrom.
    • S3 credentials can be referenced via storage.s3.secretName + accessKeyIdKey/secretAccessKeyKey to avoid embedding them in pod specs.