houseassassin/twenty
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
14,041 Commits 1 Branch 0 Tags
e4e1d24731f9fddd385a64c09d7b9bdc8295ab3d
Commit Graph

7 Commits

Author SHA1 Message Date
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
Miguel 921c528cc3 feat(helm): add nodeSelector, tolerations and DNS overrides to server and worker (#22233) 
Closes #22250

## What

Adds four standard pod spec fields to both server and worker Deployments
of the Helm chart, exposed under `server.*` and `worker.*` in
`values.yaml`:

- `nodeSelector`
- `tolerations`
- `dnsPolicy`
- `dnsConfig`

## Why

Self-hosters who run Twenty on clusters with dedicated nodes, taints, or
custom DNS requirements currently need to fork the chart or patch
rendered manifests with Kustomize. These are the standard pod spec
fields supported by virtually every other community chart (Bitnami,
prometheus-community, cert-manager, etc.) and are commonly needed in
production setups.

## How

Uses the same `{{- with }}` pattern already present in the chart (e.g.
`extraEnv`, `extraVolumeMounts`), so empty defaults skip rendering
entirely:

```yaml
{{- with .Values.server.nodeSelector }}
nodeSelector:
  {{- toYaml . | nindent 8 }}
{{- end }}
```

## Backward compatibility

Fully backward compatible. Defaults are empty:

```yaml
server:
  nodeSelector: {}
  tolerations: []
  dnsPolicy: ~
  dnsConfig: {}
```

`helm template` output is bit-identical to the previous version for any
existing install.

## Schema note

`dnsPolicy` is typed as `[string, null]` and the enum includes `null` so
the empty default (`dnsPolicy: ~`) passes validation. The `{{- with }}`
guard treats null as falsy and renders nothing.

## Validation

- `helm lint` passes
- `helm template` with default values produces bit-identical output to
before this PR
- `helm template` with values set renders the four fields correctly on
both server and worker
- Live install validated on a multi-node Kubernetes cluster, pinning
Twenty to a dedicated tainted node with custom DNS (`ndots: 1`); server
and worker scheduled and started successfully

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22233?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-06-29 13:00:42 +02:00
Charles Bochet e95adcc757 fix(helm): add unit tests, extraEnv schema validation, and minor fixes (#18836) 
## Summary

Follow-up to #18157. Cherry-picks the useful parts from #18481 (by
@dnplkndll), adapted to align with the current state of `main`:

- **Helm unit tests** for Redis external authentication (secret-based +
plaintext password, both server and worker)
- **Helm unit tests** for `extraEnv` injection (plain values and
`valueFrom` on both server and worker)
- **JSON schema validation** for `server.extraEnv` and `worker.extraEnv`
in `values.schema.json`
- **Fix** `server_url_test.yaml` to use JSONPath filters
(`@.name=="SERVER_URL"`) instead of brittle `env[0]` index selectors
- **Fix** worker `storageEnv` whitespace (missing `-` in `{{-
$storageEnv | nindent 12 }}`)

Stale tests from #18481 (for `disableDbMigrations`, `server.env`
pass-through, and `run-migrations` init container) were dropped since
those features were removed during the #18157 cleanup.

## Test plan

- [ ] `helm lint` passes
- [ ] `helm template` renders cleanly
- [ ] Unit tests pass with `helm unittest` (requires the plugin)


Made with [Cursor](https://cursor.com)
 2026-03-22 21:45:31 +01:00
Lukas Huppertz 9d613dc19d Improve helm chart // Fix linting issues & introduce Redis externalSecret for redis password // Add additional ENVs // Improve migrations (#18157) 
This pull request enhances the Helm chart for the Twenty application by
improving how environment variables and Redis credentials are handled
for both server and worker deployments. The main changes include support
for injecting additional environment variables, improved Redis password
management (including external secrets), and a more robust database
migration workflow.

**Environment Variable Injection:**
- Added support for specifying additional environment variables for both
the server and worker deployments via the `additionalEnv` field in
`values.yaml`. These variables are automatically injected into the
respective pods.
[[1]](diffhunk://#diff-b5d958eae48fd1919e5623bcf0144aac7abb323ae8743e6f31367e383c63c296R55)
[[2]](diffhunk://#diff-b5d958eae48fd1919e5623bcf0144aac7abb323ae8743e6f31367e383c63c296R109-R110)
[[3]](diffhunk://#diff-20bb91909627a12b50b3c165a2a027b663479c0104ed8dbf91d2b9ad8ea8a931R74-R77)
[[4]](diffhunk://#diff-20bb91909627a12b50b3c165a2a027b663479c0104ed8dbf91d2b9ad8ea8a931R157-R172)
[[5]](diffhunk://#diff-20bb91909627a12b50b3c165a2a027b663479c0104ed8dbf91d2b9ad8ea8a931R225-R229)
[[6]](diffhunk://#diff-fb612a3b7a13156aaa607b27d23025e2c6831f111b6a582fd313fad26d2fdb5bR89-R92)

**Redis Credential Management:**
- Introduced support for using external secrets for Redis passwords by
adding `secretName` and `passwordKey` fields under `redis.external` in
`values.yaml`, and logic to inject `REDIS_PASSWORD` from a Kubernetes
secret if configured.
[[1]](diffhunk://#diff-b5d958eae48fd1919e5623bcf0144aac7abb323ae8743e6f31367e383c63c296R180-R182)
[[2]](diffhunk://#diff-5c4fa358b10abd7581188995feb9b4d6be0bc4f06a95bf27bb31b5595d6693d8R92-R100)
[[3]](diffhunk://#diff-20bb91909627a12b50b3c165a2a027b663479c0104ed8dbf91d2b9ad8ea8a931R157-R172)
[[4]](diffhunk://#diff-20bb91909627a12b50b3c165a2a027b663479c0104ed8dbf91d2b9ad8ea8a931R196-R205)
[[5]](diffhunk://#diff-fb612a3b7a13156aaa607b27d23025e2c6831f111b6a582fd313fad26d2fdb5bR70-R79)
- Updated the logic for constructing the `REDIS_URL` to include
authentication information if a password is set or an external secret is
used.

**Database Migration Workflow:**
- Improved the startup command for the server deployment to optionally
skip database migrations (using `DISABLE_DB_MIGRATIONS`), check for an
existing schema before running migrations, and ensure setup scripts are
only run on empty databases.

These changes make the chart more flexible and secure, especially for
production deployments requiring externalized secrets and custom
environment configurations.

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
 2026-03-22 21:36:10 +01:00
Félix Malfait c6f11d8adb fix: migrate driver modules to DriverFactoryBase lazy-loading pattern (#18731) 
## Summary

- Migrates `LogicFunctionModule`, `CodeInterpreterModule`, and
`CaptchaModule` from the `forRootAsync` + injection token pattern to the
`DriverFactoryBase` lazy-loading pattern (matching `EmailModule` and
`FileStorageModule`)
- Fixes #18724 where `LOGIC_FUNCTION_TYPE` was not respected in worker
processes because the driver was created at module boot time before the
DB config cache was loaded
- Removes `isEnvOnly` from `LOGIC_FUNCTION_TYPE`,
`CODE_INTERPRETER_TYPE`, `CAPTCHA_DRIVER`, `IS_MULTIWORKSPACE_ENABLED`,
and `FRONTEND_URL` — these can now be safely configured via the database
at runtime

## How it works

Each migrated module now uses a `DriverFactory` (extending
`DriverFactoryBase`) instead of a module-level async factory + Symbol
injection token:

1. **Lazy creation**: `getCurrentDriver()` creates the driver on first
call, after `DatabaseConfigDriver.onModuleInit()` has loaded the DB
cache
2. **Auto-recreation**: If config changes in the DB, the next
`getCurrentDriver()` call detects the key mismatch and creates a new
driver instance
3. **Unified config**: Both server and worker read from the same
database — driver config only needs to be set once

### Files deleted (old pattern)
- `logic-function-module.factory.ts`,
`logic-function-drivers.module.ts`, `logic-function-driver.constants.ts`
- `code-interpreter-module.factory.ts`
- `captcha.module-factory.ts`, `captcha-driver.constants.ts`

### Files created (new pattern)
- `logic-function-driver.factory.ts`
- `code-interpreter-driver.factory.ts`
- `captcha-driver.factory.ts`

Net: **-150 lines**

## Test plan

- [x] `npx nx typecheck twenty-server` passes
- [x] `npx nx lint:diff-with-main twenty-server` passes
- [ ] Integration tests pass (`npx nx run
twenty-server:test:integration:with-db-reset`)
- [ ] Verify logic functions execute in workflow runs (the original bug)
- [ ] Verify code interpreter works in workflow code steps
- [ ] Verify captcha validation works on sign-up (when captcha is
configured)


Made with [Cursor](https://cursor.com)
 2026-03-18 16:00:45 +01:00
Larron Armstead bc022f82cb Patch the postgres db url while using an external resource enabling a… (#17431) 
…n existing secret and password key
 2026-01-30 14:32:23 +00:00
Don Kendall 8630efc3d7 feat: helm chart (#16808) 
# Add Helm Chart

- Introduces a Twenty Helm chart with sensible defaults: internal
Postgres/Redis, auto DB creation/user, migrations, TLS via cert-manager,
and quickstart docs.

## Feedback requested
- Handling replicas > 1 with local storage (warn/force S3?).
- Defaults/guards for ephemeral pods + S3.
 2026-01-08 12:45:46 +00:00