## Context
Follow-up to #22673, which pinned the base image back to
`node:24.16.0-alpine` to stop the prod flood of `Invalid response body
while trying to fetch …: Premature close` failures on Gmail/Calendar
sync and Cloudflare checks introduced by the 24.17.0 bump (#22529).
The regression is confirmed upstream: 24.17.0's response-queue-poisoning
fix (CVE-2026-48931) attaches a public `'data'` listener on idle
keep-alive sockets in the `http.Agent` pool, which false-triggers
node-fetch@2's premature-close detection whenever a server abruptly
resets a keep-alive socket right after a **complete** response —
standard behavior for Google's front end. Reported the day 24.17.0
shipped (nodejs/node#63989, #64098) and fixed by nodejs/node#64004,
released in **Node 24.18.0 (2026-06-23)**.
## What this PR does
Bumps all four stages to `node:24.18.0-alpine3.23` (digest-pinned).
24.18.0 is the current 24 LTS and contains:
- everything from 24.17.0: OpenSSL 3.5.7, CVE-2026-48930 (CVSS 9.8), and
the response-queue-poisoning guard itself — reimplemented via the
socket's internal `onread` hook instead of a public stream listener
(nodejs/node#64004)
- so we get the full security posture back **and** the regression fix.
## Verification
Deterministic repro (complete chunked response over keep-alive, then
abrupt socket destroy — per nodejs/node#64098), run against all three
images with node-fetch v2 and v3:
| Node | node-fetch@2 | node-fetch@3 |
|------|--------------|--------------|
| 24.16.0 | OK | OK |
| 24.17.0 | **`ERR_STREAM_PREMATURE_CLOSE: Invalid response body …
Premature close`** (byte-for-byte the prod Sentry error) | OK |
| 24.18.0 | OK | OK |
node-fetch@2 is what the Gmail batch layer
(`@jrmdayn/googleapis-batcher`) and the Cloudflare client resolve to,
matching the affected prod paths.
## Related
- #22673 — interim rollback to 24.16.0 (shipped as twenty/v2.19.1); this
PR supersedes it
- #22671 — classifies `ERR_STREAM_PREMATURE_CLOSE` as a transient
retryable network error; still worth landing since servers legitimately
reset keep-alive sockets
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22677?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. -->
## Context
Since v2.19.0 rolled out to prod (2026-07-07), workers are flooded with
mid-body fetch failures — `Invalid response body while trying to fetch
…: Premature close` — on Gmail message import (Sentry TWENTY-SERVER-D3X,
~22k events/day, ~1k users) and, simultaneously, on Cloudflare
custom-domain checks (TWENTY-SERVER-HXW/HXT). Both code paths were
unchanged between v2.18.5 and v2.19.0; their only shared layer is the
runtime HTTP stack.
The one relevant change in v2.19.0 is #22529: the base image bump
`node:24.16.0-alpine` → `node:24.17.0-alpine`. Node 24.17.0 patched
exactly the components under these fetches:
- `http`: CVE-2026-48931 — idle keep-alive sockets in the Agent pool now
get `socket.resume()` + a destroy-on-data guard on every free→reuse
cycle
- `deps`: llhttp 9.4.2 (security bump of the HTTP parser that decides
when a chunked body is complete)
The messaging import loop cycles the same keep-alive socket through the
pool once per message fetched, so any per-cycle failure probability is
amplified by prod volume. (Note: undici's equivalent CVE fix needed two
follow-up commits for races of this exact kind — sockets destroyed while
freshly handed to a request.)
## What this PR does
Pins the base image back to `node:24.16.0-alpine3.23` (same digest
v2.18.5 shipped with) on all four stages, and updates the security note
accordingly.
This doubles as the definitive root-cause test: if the premature-close
rate drops back to its historical baseline on the rebuilt image, the
24.17.0 HTTP-stack change is confirmed and we can file a solid upstream
report to nodejs/node.
## Trade-off — please weigh in
This re-exposes what #22529 fixed: 24.16.0 statically links OpenSSL
3.5.6, so the scanner will re-flag CVE-2026-48930 (TLS embedded-nul
hostname authority rebinding, CVSS 9.8) on the node binary. There is no
24.x release newer than 24.17.0 yet. The Dockerfile carries a TODO to
re-bump as soon as a fixed 24.x ships.
## Related
- #22671 classifies `ERR_STREAM_PREMATURE_CLOSE` as a transient
(retryable) network error at the application level — worth landing
regardless of this rollback, since sync channels currently hard-fail to
`FAILED_UNKNOWN` on what is a plain network race.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22673?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. -->
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>
## Problem
The `prod-twenty` ECR image is flagged **CRITICAL** by Inspector/Oneleet
— currently ~99 active findings, all the same CVE, across every recent
per-arch digest.
- **CVE-2026-48930** (CVSS **9.8**) — a flaw in Node.js TLS hostname
handling: embedded-nul hostnames can lead to silent authority rebinding
due to c-string truncation in resolver bindings. Affects all supported
lines (22/24/26).
- The finding is on the statically-linked node binary
(`/usr/local/bin/node`), which is **24.16.0** — the version pinned
across all four stages of the Dockerfile. Every build, including the
latest, is affected; this does not age out on its own.
- Fixed in the [June 18, 2026 Node security
release](https://nodejs.org/en/blog/vulnerability/june-2026-security-releases)
→ **24.17.0**.
## Fix
Bump all four base-image stages to `node:24.17.0-alpine3.23`
(digest-pinned).
This also statically links **OpenSSL 3.5.7**, which resolves the pending
`TODO(2026-06-17)` OpenSSL 3.5.6 → 3.5.7 note in the same Dockerfile —
so the comment is updated to reflect the current state instead of a
stale TODO.
The nearby `apk` `libcrypto3/libssl3 >= 3.5.7-r0` constraints (Alpine
system libs, separate from Node's bundled OpenSSL) remain correct.
## Verification
- Fixed version confirmed against the Node.js June 2026 security release
blog and the Inspector finding (`fixedInVersion` for the 24.x line).
- New base digest resolved directly from Docker Hub for
`node:24.17.0-alpine3.23`.
- Once merged and the image rebuilds, the new digests scan clean and
Inspector auto-closes the stale findings as no image references the old
digests.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22529?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. -->
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>
Migrates `twenty-front`, `twenty-sdk`, and
`twenty-front-component-renderer` from `twenty-ui-deprecated` to
`twenty-ui` (mechanical import swap — the packages have API parity) and
deletes the deprecated package along with its workspace/CI/config
wiring.
Also adds `@linaria/react`/`@linaria/core` as direct deps of
`twenty-front` (it used them transitively via the deprecated package).
Note: move the required status check from `ci-ui-status-check` to
`ci-new-ui-status-check`.
Argos: the Storybook box-model/button-reset baseline shift (the bulk of
the visual diffs) is isolated in #21665 — Storybook now loads
twenty-ui's global `reset.scss`, which the production app already ships.
Once #21665 merges and this branch is rebased, the remaining Argos diffs
are component-level visual-parity items only.
## What
Set `ENV NODE_ENV=production` in the `twenty-server` Docker stage
(inherited by `twenty-server-aws` and `twenty`).
## Why — root cause of the empty verification emails
Verification emails have been delivered with an **empty body** in
deployed environments — the subject renders ("Bienvenue chez Twenty :
Veuillez confirmer votre email") but the HTML is `<!DOCTYPE
…><!--$!--><template></template><!--/$-->`, an **errored React Suspense
boundary**. Prod logs showed:
```
TypeError: dispatcher.getOwner is not a function
```
Chain:
1. The prod server stages never set `NODE_ENV`, so at runtime it's
**unset** → React loads its **development** builds.
2. Since the **React 18→19 upgrade** (#21531), React 19's dev JSX
runtime calls `dispatcher.getOwner()` (React 18's did not — which is why
this is a recent regression).
3. That call throws in the server runtime → the email React tree throws
during SSR → `@react-email/render` (which streams without an `onError`)
swallows it into an errored `<Suspense>` boundary → the body ships
empty. The subject is unaffected because it's built without React.
Production React never tracks owner, so `jsx()` never calls `getOwner` —
setting `NODE_ENV=production` removes the failing code path entirely.
It's also simply the correct prod configuration (dev React builds are
slower and emit dev-only behavior).
## Scope / safety
- Only the prod runtime stages are affected. The dev image
(`twenty-app-dev`) keeps its own `NODE_ENV=development`.
- Verified the deployed image currently bakes `NODE_ENV=[]` (unset) and
has a single, matched `react`/`react-dom` 19.2.7 — so this is a mode
issue, not a duplicate-React issue.
## Related
- Mitigation already in place: twentyhq/twenty-infra#729 disables email
verification on prod-eu meanwhile (revert once this ships).
- Diagnostic logging: #21628 (can be reverted after this lands).
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21635?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. -->
## Context
AWS Inspector flags the `prod-twenty` image (built from current main)
with 16 findings, and Dependabot alert 174 flags esbuild. This PR fixes
the OpenSSL scanner findings and the esbuild CVE. The typeorm bump
(CVE-2025-60542) was **pulled out of this PR** — see "typeorm status"
below.
## Changes
### Strip `/usr/local/include/node` from runtime stages
(`twenty-server`, `twenty-app-dev`)
15 OpenSSL CVEs (June 9 advisory, incl. CRITICAL CVE-2026-34182) are all
detected via **Node's bundled OpenSSL dev headers**: 3 GENERIC
`openssl/openssl` 3.5.6 detections per CVE at
`/usr/local/include/node/openssl/archs/linux-x86_64/{asm,asm_avx2,no-asm}/include/openssl/opensslv.h`.
The headers are only needed by node-gyp and native addons are compiled
in the build stages — nothing compiles at runtime. Dropping them clears
all 45 detection instances and permanently ends this class of finding
(third occurrence: 3.5.5 → 3.5.6 → 3.5.7). None of these CVEs are
reachable through Node (no CMS/PKCS#7 API, `pfx` is operator-supplied,
Node's QUIC uses ngtcp2, ASN.1 issues need ~2GB inputs).
**Follow-up (~June 17, 2026):** the `node` binary itself still
statically links OpenSSL 3.5.6 — invisible to the scanner after this PR
and unreachable in practice, but the real fix is bumping the pinned
`node:24-alpine` digest once the [announced June 17 Node.js security
releases](https://nodejs.org/en/blog/vulnerability/june-2026-security-releases)
ship a 24.x linking OpenSSL ≥ 3.5.7 (verify via
`deps/openssl/openssl/VERSION.dat` on the release tag — 24.16.0 is still
on 3.5.6). A dated TODO sits next to the cleanup in the Dockerfile.
### esbuild dev-server CORS CVE (Dependabot alert 174,
GHSA-67mh-4wv8-2f99)
`@lingui/cli@5.1.2` (pins `esbuild ^0.21.5`) was the last parent
resolving a vulnerable esbuild (≤ 0.24.2 lets any website send requests
to the dev server and read responses). Instead of a resolution override,
this bumps the lockstepped **lingui suite 5.1.2 → 5.9.5** (within-major;
lingui adopted `esbuild ^0.25.1` in 5.4.1), which:
- removes `esbuild@0.21.5` and all its platform packages from the
lockfile with no forced ranges;
- drops the `@lingui/core` lockstep resolution (its comment marked it
droppable on the next coordinated lingui bump — the tree now resolves a
single `@lingui/core@5.9.5`);
- `@lingui/swc-plugin` stays at `^5.11.0` (peers on `@lingui/core: 5`;
its 6.x line targets lingui 6).
**lingui 5.9.5 behavioral fallout handled here:**
- Translation functions now **throw without an active locale** (5.1.2
fell back silently). The global `i18n` singleton that backs server-side
`` t`…` `` calls only had a messages compiler set, never an activated
locale → activate the source locale in `I18nService.loadTranslations()`,
mirrored in the server jest setup (unit tests bypass Nest bootstrap).
- `msg`/`t` placeholders are now strictly typed (reject
`null`/`undefined`/`unknown`) → one server call site and 16 twenty-front
files adapted with minimal nullish-coalescing fixes that preserve
rendering.
- `.po`/compiled-catalog churn from the new extractor/compiler
(reference reordering, sorted keys — verified content-identical on
unchanged `.po` inputs) is intentionally not committed: the scheduled
i18n workflows regenerate those.
## typeorm status (pulled out)
typeorm 0.3.20 → 0.3.26 was originally in this PR but **made workspace
metadata sync intermittently lossy**: `example-app-postcard` failed
twice with a *different* field missing from the synced PostCard object
each run, and one integration shard's `DataSeedWorkspaceCommand` died
with "Could not find flat entity with universal identifier …" — versus
zero such failures on recent main. Local runs (db reset + seed, group-by
integration suite 19/19) pass, so it is a nondeterministic
CI-load-sensitive regression that needs dedicated debugging (typeorm
changed LIMIT/OFFSET 0 semantics, lazy count for `getManyAndCount`,
upsert WHERE construction, and topological-sort internals in that
range). The resolutions comment documents this as the blocker;
CVE-2025-60542 is MySQL-driver-only (`sqlstring`), so Postgres-only
Twenty is not exposed in the meantime.
## Verification
- `npx nx typecheck twenty-server` / `twenty-front` — clean (no cache)
- `npx nx test twenty-server` — full suite green
- `lingui:extract` + `lingui:compile` — clean for twenty-server /
twenty-emails / twenty-front
- `oxfmt --check` — clean for both packages
- Lockfile diff: lingui 5.9.5 entries, `esbuild@0.21.5` +
`@esbuild/*@0.21.5` platform packages removed, no typeorm changes
## Context
Image scanner flags the `prod-twenty` server image for OpenSSL CVEs. The
image carries **two independent OpenSSL surfaces**, and they are fixed
by different levers:
| Surface | Version (before) | Used by app at runtime? | Fix lever |
|---|---|---|---|
| **Node-bundled** OpenSSL | `3.5.6` | ✅ yes (Node links its own) | Node
base bump (separate; `24.16.0-alpine3.23` is already the latest digest)
|
| **Alpine system** `libcrypto3`/`libssl3` | `3.5.6-r0` | ❌ no (`ldd
node` shows no link) | **this PR** — apk upgrade to `3.5.7-r0` |
The pinned `node:24.16.0-alpine3.23` base bakes `libcrypto3`/`libssl3`
at `3.5.6-r0`, while the Alpine v3.23 repo now ships `3.5.7-r0`. These
libs ship as deps of `apk-tools`/`libapk`/`ssl_client` (so they can't be
removed), and Node does not link them — but the scanner still flags them
by version.
## Change
Pin a patched floor (`libcrypto3>=3.5.7-r0`, `libssl3>=3.5.7-r0`) in the
`apk add` lines of both runtime stages (`twenty-server` and
`twenty-app-dev`) so apk upgrades them at build time. Same technique
already used for `curl`/`nghttp2-libs`/`postgresql18-client` (#20805).
## Verification
- Built `--target twenty-server`; image builds clean.
- On the built image, `libcrypto3` and `libssl3` resolve to `3.5.7-r0`.
- Node-bundled OpenSSL is unaffected by this change (separate surface,
no Dockerfile-side upgrade path until a newer Node release links a
patched OpenSSL).
## Description
Promotes the next-gen UI library (formerly `twenty-new-ui`) to the name
**`twenty-ui`** (v0.1.0, publishable) and renames the old package to
**`twenty-ui-deprecated`**. Rewrites ~1,730 `twenty-ui` imports →
`twenty-ui-deprecated`, updates all configs/CI/Docker/deps, and migrates
twenty-front's `Toggle` to the new package (first consumer) as a
drop-in.
## Next steps
- Wire the `ui/v*` publish dispatch (`cd-deploy-tag.yaml` +
`.yarnrc.yml`), then tag `ui/v0.1.0` to publish.
- Continue migrating components from `twenty-ui-deprecated` →
`twenty-ui`.
Hardens the `prod-twenty` server image. Built `--target twenty-server`
and walked it to verify each change.
- **Node 24.15.0 → 24.16.0** (all stages + `.nvmrc`): 24.15.0 links
OpenSSL **3.5.5** (CVE-2026-31798), 24.16.0 links **3.5.6** — the proper
fix (deleting headers only hid it; the binary still linked the vuln
lib).
- **Remove the bundled npm CLI** (`ip-address`): app uses yarn via
corepack, never npm; npm still bundles `ip-address@10.1.0` and its
latest 10.2.0 is itself unfixed — no upgrade path.
- **Remove vendored `example/` apps** (`passport-microsoft/example`
ships a `package-lock.json` for an old Express demo, never
installed/run; not in our lockfile).
- **node-forge → 1.4.0** (Critical CVE-2026-33606) via `yarn dedupe` —
lockfile-only, no phantom dep, no root resolution.
Verified on the built image: node 24.16.0 / openssl 3.5.6, npm CLI +
example dirs absent, node-forge@1.4.0 only.
**Not included (need CI/QA):** real deps pinned inside
`@nestjs/*`/`express` (`lodash@4.17.21`, `file-type`, `path-to-regexp`,
`ws`, `qs`) need parent bumps or scoped resolutions; standalone
`undici@5.29.0` (5→7), `apollo-server-core@3` (EOL), `typeorm`, etc.
(`axios` already patched.)
## Summary
- ECR Inspector still flags `prod-twenty` for the High-severity CVEs
that PR #20603 was meant to fix (8x `postgresql18-18.3-r0`,
`nghttp2-1.68.0-r0`, `curl-8.17.0-r1`, plus the related Medium `curl`
CVE).
- Root cause: PR #20603 pinned the `node:24.15.0-alpine3.23` digest to
invalidate the buildx GHA cache once, but the cache layer was first
repopulated (on the PR branch) before Alpine 3.23 published `18.4-r0` /
`1.69.0-r0` / `8.19.0-r0`. Every build since — including today's prod
v2.6.2 — hits `#26 [twenty-server 2/19] RUN apk add --no-cache curl jq
postgresql-client / #26 CACHED` and ships the stale packages.
- Pinning minimum versions in the `apk add` spec changes the RUN text →
forces a new buildx cache key → apk re-resolves against the current
Alpine mirror. apk also refuses to install anything below the floor, so
the image can't silently regress if a stale layer ever matches the key
again.
## Summary
Follow-up to the Cloudflare/OpenNext migration (#20741). Now that the
legacy `twenty-website` package was already removed in #20270, the
`-new` suffix on the marketing site package is no longer meaningful.
## What changes
- **Directory rename**: `git mv packages/twenty-website-new
packages/twenty-website` (1213 files moved, no content change)
- **Package + nx config**: `package.json` and `project.json` name fields
updated, `sourceRoot` repointed
- **Source refs**: `load-local-articles.ts` and
`load-local-release-notes.ts` had a hardcoded `'twenty-website-new'`
segment in their monorepo-root fallback path;
`app/[locale]/releases/page.tsx` had display strings showing where to
add content
- **External refs**: root `package.json` workspaces, root `CLAUDE.md` /
`README.md`, `twenty-sdk` + `create-twenty-app` READMEs,
`.vscode/twenty.code-workspace`, `.cursor/rules/changelog-process.mdc`,
Crowdin config + the three `website-i18n-*` CI workflows +
`ci-website.yaml`
- **Docker cleanup**:
`packages/twenty-docker/twenty-website-new/Dockerfile` deleted; the two
Makefile targets (`prod-website-new-build` / `prod-website-new-run`)
that referenced it removed — EKS deploy was retired in the Cloudflare
migration
- **`yarn.lock`** regenerated against the new workspace path
## What's deliberately not in this PR
The dev hostname `website-new.twenty-main.com` in `wrangler.jsonc` stays
for now. Migrating it to `website.twenty-main.com` needs coordinated DNS
deletion (current CNAME points at the legacy Docusaurus NLB and serves
503s) and removal of the matching legacy `website` Helm chart in
`twenty-infra`. Flagged as a separate cleanup.
Companion infra PR: https://github.com/twentyhq/twenty-infra/pull/682
(workflow paths + Terraform ECR + docs)
## Test plan
- [x] `yarn install --immutable` resolves clean against the new path
- [x] `npx nx typecheck twenty-website` passes
- [x] `npx nx lint twenty-website` passes
- [ ] CI on this PR confirms the same on a fresh checkout
- [ ] After merge: trigger `Deploy Website` workflow against
`environment=dev` to confirm the renamed working-directory deploys
correctly
## Summary
- Documents the new at-rest encryption envelope (`ENCRYPTION_KEY` /
`FALLBACK_ENCRYPTION_KEY`) introduced in v2.5+ and clarifies its
relationship to the legacy `APP_SECRET`-as-encryption-key path.
- Adds a new dedicated **Key rotation** guide covering manual /
Enterprise-cron JWT signing-key rotation, signing-key revocation, and
the online `ENCRYPTION_KEY` rotation procedure (including the new
\`secret-encryption:rotate\` CLI shipped in a follow-up PR).
- Updates the docker-compose quickstart to generate a dedicated
\`ENCRYPTION_KEY\` from day 1.
- Mentions the v2.5+ enc:v2 backfill in the upgrade guide.
English-only — the localized mirrors will be picked up by i18n CI.
## Test plan
- [ ] Mintlify build passes locally / in CI
- [ ] Sidebar entry renders under **Self-Host → Key rotation**
- [ ] Internal links to /developers/self-host/capabilities/key-rotation
resolve from setup.mdx, docker-compose.mdx and upgrade-guide.mdx
---------
Co-authored-by: github-actions <github-actions@twenty.com>
## Summary
- ECR Inspector flagged 9 CVEs on the `prod-twenty` image — 8 PostgreSQL
CVEs on `postgresql18-18.3-r0` (pulled in transitively by `apk add
postgresql-client`) and CVE-2026-27135 on `nghttp2-1.68.0-r0` (pulled in
by `curl` / `aws-cli`).
- Alpine 3.23 already ships patched `postgresql18-18.4-r0` and
`nghttp2-1.69.0-r0`, but the GHA buildx cache was reusing the stale `apk
add` layer because `FROM node:24-alpine` had not moved.
- Pinning the base image to `node:24.15.0-alpine3.23@sha256:8e2c930f…`
forces a layer cache miss, picks up the patched apk packages, and gives
Dependabot/Renovate a stable target for future digest bumps.
Applied to both
[packages/twenty-docker/twenty/Dockerfile](https://github.com/twentyhq/twenty/blob/charles/trusting-solomon-259ec8/packages/twenty-docker/twenty/Dockerfile)
(4 stages → ECR `prod-twenty`) and
[packages/twenty-docker/twenty-website-new/Dockerfile](https://github.com/twentyhq/twenty/blob/charles/trusting-solomon-259ec8/packages/twenty-docker/twenty-website-new/Dockerfile)
(2 stages).
## Test plan
- [ ] CI builds both images successfully on amd64 + arm64
- [ ] After merge + deploy, re-run ECR Inspector on the new
`prod-twenty` image and confirm the 9 CVEs
(CVE-2026-6473/6474/6475/6476/6477/6478/6479/6637 + CVE-2026-27135) are
gone
- [ ] Smoke-test the staging deployment (server boot, DB migrations via
`psql` in the entrypoint)
# Introduction
When running the `run-instance-commands` on a migration failure the
process wouldn't throw at all
Leading to conditional flow to keep going whereas it should have stopped
This update is very invasive and impacts all the nest commander
registered commands
We should keep in mind that it impacts the way we create and init
database and so on
But I think that's for the best, as cli that never exit 1 is
counterintuitive
# Introduction
Aiming for faster cd process
## Splitting front end server deps
Reduce dependencies bloating when target is server only, installing only
root repo dev deps and server dev and prod deps
Still pruning before copying to prod node_modules
## Server only remove twenty-ui
Also removing twenty-ui from server build as it was not consumed at all
Depends on https://github.com/twentyhq/twenty/pull/20140
## Summary
The `twenty-app-dev` Docker image previously passed `--dev-mode` to
`cron:register:all`, which skipped all calendar, messaging, and workflow
sync cron jobs (only 4 generic crons were registered). This caused
periodic sync to silently stop after the initial import for community
members using the dev image as their actual instance.
## What changed
- Removed `--dev-mode` flag from
`packages/twenty-docker/twenty-app-dev/rootfs/etc/s6-overlay/scripts/register-crons.sh`
so the dev image registers all cron jobs (matching production behavior)
- Removed the now-unused `--dev-mode` option, `DEV_MODE_COMMANDS` set,
and conditional filtering logic from `cron-register-all.command.ts`
## Why this is safe
- **No log noise**: cron jobs gracefully no-op when no connected
accounts exist — they query for pending channels, find zero, and exit
early
- **No false banner**: the "reconnect account" banner only shows when a
user explicitly connected an account whose OAuth later fails, which is
correct behavior. No seed/demo data creates connected accounts, so a
fresh dev instance won't see any banner
- **Hiding crons just hid the symptom**: silently breaking sync with no
user feedback is worse than showing the banner if OAuth is misconfigured
## Context
Surfaced by a community member who reported that calendar sync cron jobs
never appeared in the queue after restarting the dev image, and only the
initial import worked. `--dev-mode` was added in #19138 as an
optimization for development but it doesn't match how the dev image is
actually used by community members deploying Twenty.
## Test plan
- [ ] Build/run the `twenty-app-dev` image
- [ ] Confirm worker logs show all cron jobs registering (calendar,
messaging, workflow, etc.)
- [ ] With no connected accounts: confirm no errors or log noise
- [ ] With a connected Google calendar: confirm periodic sync triggers
after ~5 minutes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Introduction
In aim to reduce and optimize the number of twenty-front build we do
during our cd process and allow twenty-front build promotion
### Build time
**Nothing is baked.** The `build/` directory is a clean, env-agnostic
artifact. `index.html` contains the empty placeholder:
```html
<script id="twenty-env-config">
window._env_ = {
// This will be overwritten
};
</script>
```
The JS bundles contain no hardcoded server URL.
---
### Deploy mode 1: Frontend served by the backend (Docker / NestJS)
1. Container starts, NestJS boots in `main.ts`
2. `generateFrontConfig()` runs, reads `process.env.SERVER_URL`
3. Rewrites `dist/front/index.html`, replacing the placeholder with:
```html
<script id="twenty-env-config">
window._env_ = {
REACT_APP_SERVER_BASE_URL: "https://api.example.com"
};
</script>
```
4. NestJS serves the static `dist/front/` directory
5. Browser loads `index.html`, `window._env_` is set before the app JS
executes
6. `src/config/index.ts` reads `window._env_.REACT_APP_SERVER_BASE_URL`
and uses it
---
### Deploy mode 2: Frontend served standalone (CDN / nginx / static
server)
1. Take the `build/` artifact as-is
2. Before serving, run at deploy time:
```bash
REACT_APP_SERVER_BASE_URL=https://api.example.com sh
./scripts/inject-runtime-env.sh
```
3. This does the same `sed` replacement on `build/index.html`
4. Serve the `build/` directory with your static server of choice
5. Same resolution in the browser:
`window._env_.REACT_APP_SERVER_BASE_URL` is picked up by
`src/config/index.ts`
---
### Fallback: no injection at all
If neither mechanism runs (e.g. local dev with `vite dev`),
`window._env_.REACT_APP_SERVER_BASE_URL` is `undefined`, and
`getDefaultUrl()` kicks in:
- **Localhost**: returns `http://localhost:3000`
- **Non-localhost**: returns same-origin (`window.location.origin`)
# Introduction
Creating a target funnel that allow bypassing front build and injection
in the server
## New targets
- `twenty-server` only ships server
- `twenty` ships both front and back in the same image
- `twenty-server-aws` only ships server and `aws-cli`
- `twenty-aws` ships both front and back in the same image with the
`aws-image`
## Summary
Fix the website-new Docker build which currently fails with:
\`\`\`
NX \"production\" is an invalid fileset.
All filesets have to start with either {workspaceRoot} or {projectRoot}.
\`\`\`
\`packages/twenty-website-new/project.json\` declares \`\"inputs\":
[\"production\", \"^production\"]\` — a named input defined in the root
\`nx.json\`. Without copying \`nx.json\` into the image, nx can't
resolve it and the build fails.
Mirrors what the main twenty Dockerfile already does (line 9 of
\`packages/twenty-docker/twenty/Dockerfile\` copies both
\`tsconfig.base.json\` and \`nx.json\`).
## Test plan
- [ ] Re-run twenty-infra's \`Deploy Website New\` workflow (dev) —
build step should now pass
Made with [Cursor](https://cursor.com)
## Summary
Adds the Docker build for the new marketing website at
`packages/twenty-website-new`, mirroring the existing
`packages/twenty-docker/twenty-website/Dockerfile`.
Differences from the existing `twenty-website` Dockerfile:
- Uses `nx build twenty-website-new` / `nx start twenty-website-new`
- Drops the `KEYSTATIC_*` build-time fake env (the new website doesn't
use Keystatic)
- Doesn't copy `twenty-ui` source (the new website has no workspace
dependency on it)
The image will be built by the new `deploy-website-new.yaml` workflow in
[`twentyhq/twenty-infra`](https://github.com/twentyhq/twenty-infra) and
pushed to ECR repos `dev-website-new` / `staging-website-new`.
Companion PRs:
- twentyhq/twenty-infra: Helm chart + ArgoCD app + deploy workflow
- twentyhq/twenty-infra-releases: bootstrap tags.yaml
## Test plan
- [ ] Local build: \`docker build -f
packages/twenty-docker/twenty-website-new/Dockerfile .\`
- [ ] First run of \`Deploy Website New\` workflow on dev succeeds
(build + push to ECR)
- [ ] ArgoCD \`website-new\` application becomes Healthy on dev
- [ ] https://website-new.twenty-main.com serves the new website
Made with [Cursor](https://cursor.com)
## Summary
- Enable application log console output in the `twenty-app-dev` Docker
image by adding `APPLICATION_LOG_DRIVER=CONSOLE` to the Dockerfile ENV
block
- Rename `APPLICATION_LOG_DRIVER_TYPE` to `APPLICATION_LOG_DRIVER` and
`ApplicationLogDriverType` to `ApplicationLogDriver` for consistency
with all other driver config variables (`EMAIL_DRIVER`, `LOGGER_DRIVER`,
`CAPTCHA_DRIVER`, etc.)
- Add `APPLICATION_LOG_DRIVER` to `.env.example`
## Motivations
A lot of self hosters hands up using the `yarn database:migrated:prod`
either manually or through AI assisted debug while they try to upgrade
an instance while their workspace is still blocked in a previous one
Leading to their whole database permanent corruption
## What happened
Replaced the direct call the the typeorm cli to a command calling it
programmatically, adding a layer of security in case a workspace seems
to be blocked in a previous version than the one just before the one
being installed ( e.g 1.0 when you try to upgrade from 1.1 to 1.2 )
For our cloud we still need a way to bypass this security explaining the
-f flag
## Remark
Centralized this logic and refactored creating new services
`WorkspaceVersionService` and `CoreEngineVersionService` that will
become useful for the upcoming upgrade refactor
Related to https://github.com/twentyhq/twenty-infra/pull/529
## Summary
- When `STORAGE_S3_PRESIGNED_URL_BASE` is configured, the file
controller returns a **302 redirect** to a presigned S3 URL instead of
proxying every byte through the server. This eliminates server bandwidth
and CPU overhead for S3-backed deployments.
- For local storage or S3 without a public endpoint, behavior is
unchanged (stream + pipe with security headers).
- Added `getPresignedUrl` to the `StorageDriver` interface (required
method returning `string | null`), with implementations in S3Driver
(uses a separate presign client with the public endpoint), LocalDriver
(returns `null`), and ValidatedStorageDriver (path traversal protection
+ delegation).
- Added a unified `getFileResponseById` method in `FileService` that
performs a single DB lookup and returns either a redirect URL or a
stream, avoiding double lookups.
- Extracted `getContentDisposition` from the header util so both the
proxy path and presigned URL path share the same inline/attachment
allowlist.
- Added MinIO service to `docker-compose.dev.yml` (optional `s3`
profile) for local S3 testing.
- Documented S3 presigned URL setup, CORS, and `nosniff` requirements in
the self-hosting docs.
## Test plan
- [x] All 63 unit tests pass across 5 test suites (util, S3 driver,
validated driver, file storage service, controller)
- [x] `npx nx typecheck twenty-server` passes
- [ ] Manual E2E test with MinIO: `docker compose --profile s3 up -d`,
configure S3 env vars, verify `curl -I` returns 302 with `Location`
header pointing to MinIO
- [ ] Verify local storage (no `STORAGE_S3_PRESIGNED_URL_BASE`) still
streams files with 200 + security headers
- [ ] Verify public assets endpoint still proxies (no redirect)
Made with [Cursor](https://cursor.com)
## Summary
- **Reduce app-dev image size** by stripping ~60MB of build artifacts
not needed at runtime from the server build stage: `.js.map` source maps
(29MB), `.d.ts` type declarations (9MB), compiled test files (14MB), and
unused package source directories (~9MB).
- **Add CI smoke test** for the `twenty-app-dev` all-in-one Docker
image, running in parallel with the existing docker-compose test. Builds
the image, starts the container, and verifies `/healthz` returns 200.
## Test plan
- [x] Built image locally and verified server, worker, Postgres, and
Redis all start correctly
- [x] Verified `/healthz` returns 200 and frontend serves at `/`
- [ ] CI `test-compose` job passes (existing test, renamed from `test`)
- [ ] CI `test-app-dev` job passes (new parallel job)
Made with [Cursor](https://cursor.com)
## Summary
- **Add `lingui:compile` to Dockerfile** before both the server and
frontend build stages, ensuring compiled translation catalogs are always
fresh regardless of git state
- **Add `repository-dispatch` to i18n workflows** (`i18n-push.yaml` and
`i18n-pull.yaml`) to trigger reactive automerge in `twenty-infra` when
the i18n PR is ready, replacing the 15-minute polling approach
## Context
Users sometimes see "Uncompiled message detected" errors because
releases can be cut from `main` before the i18n PR (with freshly
compiled translation catalogs) has been merged. This creates a race
condition between new translatable strings landing on `main` and their
compiled catalogs being available.
These changes fix this in two ways:
1. **Safety net in builds**: Every Docker build now compiles
translations before building, so even if compiled catalogs in git are
stale, the build artifact is always correct
2. **Faster i18n PR merges**: Instead of a 15-minute cron polling for
i18n PRs, the workflows now notify `twenty-infra` immediately when
translations are ready, reducing merge latency from ~15 minutes to ~1
minute
Companion PR in twenty-infra: twentyhq/twenty-infra
(feat/i18n-reactive-automerge)
## Test plan
- [ ] Verify `TWENTY_INFRA_TOKEN` secret is available to i18n workflows
- [ ] Docker build still succeeds with the added `lingui:compile` steps
- [ ] i18n-push triggers automerge in twenty-infra after pushing changes
- [ ] i18n-pull triggers automerge in twenty-infra after pulling
translations
Made with [Cursor](https://cursor.com)
## 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)
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>
## 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)
## Summary
Completely rewrites the development environment setup script to be more
robust, idempotent, and flexible. The new implementation auto-detects
available services (local PostgreSQL/Redis vs Docker), provides multiple
operational modes, and includes comprehensive health checks and error
handling.
## Key Changes
- **Enhanced setup script** (`packages/twenty-utils/setup-dev-env.sh`):
- Added auto-detection logic to prefer local services (PostgreSQL 16,
Redis) over Docker
- Implemented service health checks with retry logic (30s timeout)
- Added command-line flags: `--docker` (force Docker), `--down` (stop
services), `--reset` (wipe data)
- Improved error handling with `set -euo pipefail` and descriptive
failure messages
- Added helper functions for service detection, startup, and status
checking
- Fallback to manual `.env` file copying if Nx is unavailable
- Enhanced output with clear status messages and usage instructions
- **New Docker Compose file**
(`packages/twenty-docker/docker-compose.dev.yml`):
- Dedicated development infrastructure file (PostgreSQL 16 + Redis 7)
- Includes health checks for both services
- Configured with appropriate restart policies and volume management
- Separate from production compose configuration
- **Updated documentation** (`CLAUDE.md`):
- Clarified that all environments (CI, local, Claude Code, Cursor) use
the same setup script
- Documented new command-line flags and their purposes
- Noted that CI workflows manage services independently via GitHub
Actions
- **Updated Cursor environment config** (`.cursor/environment.json`):
- Simplified to use the new unified setup script instead of complex
inline commands
## Implementation Details
The script now follows a clear three-phase approach:
1. **Service startup** — Auto-detects and starts PostgreSQL and Redis
(local or Docker)
2. **Database creation** — Creates 'default' and 'test' databases
3. **Environment configuration** — Sets up `.env` files via Nx or direct
file copy
The auto-detection logic prioritizes local services for better
performance while gracefully falling back to Docker if local services
aren't available. All operations are idempotent and safe to run multiple
times.
https://claude.ai/code/session_01UDxa2Kp1ub9tTL3pnpBVFs
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Add standard command menu items
### Summary
This PR introduces standard command menu items, migrating hardcoded
command menu actions to the backend command menu item architecture
powered by front components. It adds a new `twenty-standard-application`
package that defines, builds, and registers front components as standard
command menu items, gated behind the `IS_COMMAND_MENU_ITEM_ENABLED`
feature flag.
### Description
- **New `twenty-standard-application` package**: Contains front
component definitions with an esbuild-based build pipeline that
generates minified `.mjs` bundles and a manifest with checksums.
- **Server-side registration**: New constants register all items with
metadata (labels, icons, positions, availability types, conditional
expressions). A `StandardFrontComponentUploadService` uploads built
components to file storage.
- **`FALLBACK` availability type**: New enum value for command menu
items that appear as fallback options (e.g., "Search Records" fallback).
- **`CommandMenuContextApi` refactor**
- **Conditional availability enhancements**: New array-based helper
functions for evaluating multi-record conditions.
- **Frontend wiring** (twenty-front):
`useCommandMenuItemFrontComponentCommands`
## Next steps
Only simple commands have been implemented for now:
- **Navigation (9)** -- `CommandLink`: go-to-companies,
go-to-dashboards, go-to-notes, go-to-opportunities, go-to-people,
go-to-runs, go-to-settings, go-to-tasks, go-to-workflows
- **Side panel (4)** -- `CommandOpenSidePanelPage`: ask-ai,
search-records, search-records-fallback, view-previous-ai-chats
We still have to implement front components for all the following
commands:
All have placeholder `execute` logic (`async () => {}`) with a `// TODO:
implement execute logic` comment:
**Record (22)**
- `add-to-favorites`, `remove-from-favorites`
- `create-new-record`, `create-new-view`
- `delete-single-record`, `delete-multiple-records`
- `destroy-single-record`, `destroy-multiple-records`
- `restore-single-record`, `restore-multiple-records`
- `export-from-record-index`, `export-from-record-show`,
`export-multiple-records`, `export-note-to-pdf`, `export-view`
- `hide-deleted-records`, `see-deleted-records`
- `import-records`, `merge-multiple-records`, `update-multiple-records`
- `navigate-to-next-record`, `navigate-to-previous-record`
**Page layout (3)** -- `cancel-record-page-layout`,
`edit-record-page-layout`, `save-record-page-layout`
**Dashboard (4)** -- `cancel-dashboard-layout`, `duplicate-dashboard`,
`edit-dashboard-layout`, `save-dashboard-layout`
**Workflow (10)** -- `activate-workflow`, `add-node-workflow`,
`deactivate-workflow`, `discard-draft-workflow`, `duplicate-workflow`,
`see-active-version-workflow`, `see-runs-workflow`,
`see-versions-workflow`, `test-workflow`, `tidy-up-workflow`
**Workflow version (4)** -- `see-runs-workflow-version`,
`see-versions-workflow-version`, `see-workflow-workflow-version`,
`use-as-draft-workflow-version`
**Workflow run (3)** -- `see-version-workflow-run`,
`see-workflow-workflow-run`, `stop-workflow-run`
## Summary
Moves the custom ESLint rules from `tools/eslint-rules` to
`packages/twenty-eslint-rules` for better organization within the
monorepo packages structure.
## Changes
- Move `eslint-rules` from `tools/` to `packages/twenty-eslint-rules`
- Use `loadWorkspaceRules` from `@nx/eslint-plugin` to load custom rules
- Update all ESLint configs to use the `twenty/` rule prefix instead of
`@nx/workspace-`
- Update `project.json`, `jest.config.mjs` with new paths
- Update `package.json` workspaces and `nx.json` cache inputs
- Update Dockerfile reference
## Technical Details
The custom ESLint rules are now loaded using Nx's `loadWorkspaceRules`
utility which:
- Handles TypeScript transpilation automatically
- Allows loading workspace rules from any directory
- Provides a cleaner approach than the previous `@nx/workspace-`
convention
## Testing
- Verified all 17 custom ESLint rules load correctly from the new
location
- Verified linting works on dependent packages (twenty-front,
twenty-server, etc.)
## Summary
This PR reduces clutter at the repository root to improve navigation on
GitHub. The README is now visible much sooner when browsing the repo.
## Changes
### Deleted from root
- `nx` wrapper script → use `npx nx` instead
- `render.yaml` → no longer used
- `jest.preset.js` → inlined `@nx/jest/preset` directly in each
package's jest.config
- `.prettierrc` → moved config to `package.json`
- `.prettierignore` → patterns already covered by `.gitignore`
### Moved/Consolidated
| From | To |
|------|-----|
| `Makefile` | `packages/twenty-docker/Makefile` (merged) |
| `crowdin-app.yml` | `.github/crowdin-app.yml` |
| `crowdin-docs.yml` | `.github/crowdin-docs.yml` |
| `.vale.ini` | `.github/vale.ini` |
| `tools/eslint-rules/` | `packages/twenty-eslint-rules/` |
| `eslint.config.react.mjs` |
`packages/twenty-front/eslint.config.react.mjs` |
## Result
Root items reduced from ~32 to ~22 (folders + files).
## Files updated
- GitHub workflow files updated to reference new crowdin config paths
- Jest configs updated to use `@nx/jest/preset` directly
- ESLint configs updated with new import paths
- `nx.json` updated with new paths
- `package.json` now includes prettier config and updated workspace
paths
- Dockerfile updated with new eslint-rules path
# 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.
Charles Bochet
