Miguel
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>
The #1 Open-Source CRM
Website · 
Documentation · 
Roadmap · 
Discord · 
Figma
Why Twenty
Twenty gives technical teams the building blocks for a custom CRM that meets complex business needs and quickly adapts as the business evolves. Twenty is the CRM you build, ship, and version like the rest of your stack.
Learn more about why we built Twenty
Installation
Cloud
The fastest way to get started. Sign up at twenty.com and spin up a workspace in under a minute, with no infrastructure to manage and always up to date.
Build an app
Scaffold a new app with the Twenty CLI:
npx create-twenty-app my-app
Define objects, fields, and views as code:
import { defineObject, FieldType } from 'twenty-sdk/define';
export default defineObject({
nameSingular: 'deal',
namePlural: 'deals',
labelSingular: 'Deal',
labelPlural: 'Deals',
fields: [
{ name: 'name', label: 'Name', type: FieldType.TEXT },
{ name: 'amount', label: 'Amount', type: FieldType.CURRENCY },
{ name: 'closeDate', label: 'Close Date', type: FieldType.DATE_TIME },
],
});
Then ship it to your workspace:
npx twenty app:publish --private
See the app development guide for objects, views, agents, and logic functions.
Self-hosting
Run Twenty on your own infrastructure with Docker Compose, or contribute locally via the local setup guide.
Everything you need
Twenty gives you the building blocks of a modern CRM (objects, views, workflows, and agents) and lets you extend them as code. Here's a tour of what's in the box.
Want to go deeper? Read the 
User Guide for product walkthroughs, or the Documentation for developer reference.
|
|
|
|
|
|
Learn more about version control in doc
Stack
TypeScript
Nx
NestJS, with BullMQ, 
PostgreSQL, 
Redis
React, with Jotai, Linaria and Lingui
Thanks
Thanks to these amazing services that we use and recommend for code review (Greptile), catching bugs (Sentry) and translating (Crowdin).
Join the Community
Star the repo · Discord · 
Feature requests · Releases · 
X · 
LinkedIn · 
Crowdin · 
Contribute