Infrastructure

Added

• Scope management selects Zitadel v1 or v2 APIs from the server version so mixed 3.x and 4.x tenants can share one image; operators can pin the mode with ZITADEL_API_MODE.

• Frontend Helm charts (admin, chat, knowledge-upload, theme) configure cross-app navigation URLs via a structured frontends values object instead of flat *_APP_URL overrides.

• sbx-storage exposes checkpoint deletion on a dedicated port; node-chat's dependency on it (disabled by default) is scoped to that port, so enabling it in an overlay grants delete-only access without requiring Cilium L7 proxying.

Fixed

• Chat metrics jobs no longer load a full day of message debug data into memory when computing daily tool-call and MCP summaries.

• Client insights reads now use indexed lookups on installation and time range instead of scanning the full insight table.

• First installs no longer hang on the migration when the namespace has a default-deny policy. Charts with a migration hook now render a <fullname>-hooks network policy, for both cilium and kubernetes flavors. Remove any hand-made <fullname>-hooks policy, it clashes by name.

Feature Flags

Required infrastructure updates

Secure WebSocket token-to-ticket migration

To improve security, WebSocket connections are now authenticated with short-lived, single-use tickets issued by the Kong gateway instead of passing the user's access token. Tickets are stored in Redis for a few seconds and removed when used. This requires Redis 6.2 or newer (for GETDEL), reachable from Kong, with a writable primary, password authentication, and key expiry (TTL). By default, the existing redis-replication instance is used. Legacy token-based WebSocket authentication stays available during the client rollout.

Requirements:

Code interpreter display switches move to assistant configuration

The two code interpreter display flags are gone. Both switches are now plain fields in the Code display section of the assistant configuration:

Behaviour change: both flags used to default to off. The new configuration fields default to true. So HTML files now show as an interactive card with a code view for every client, unless an operator sets enable_html_with_fence to false.

enable_html_with_fence only works when enable_code_execution_fence is also on. If either switch is off, HTML files fall back to a plain HtmlRendering block.

Action required: remove both environment variables from your environment. If you do not want the HTML card, set enable_html_with_fence to false (true by default) in the assistant configuration. If you do not want the FILE card, set enable_code_execution_fence to false(true by default) in the assistant configuration.

Code Execution moves from a feature flag to a company setting

The Code Execution tool is no longer controlled by FEATURE_FLAG_ENABLE_CODE_EXECUTION_UN_17498. It is now a company setting called codeExecutionEnabled, served by backend-service-configuration. The old flag is still present but it is ignored.

Action required. The new setting is off by default. If you run Code Execution today, you must set the new variable on backend-service-configuration, or the tool disappears after the upgrade.

configurationBackend:
  env:
    COMPANY_CONFIGURATION_CODE_EXECUTION_ENABLED: "*:true"

Use *:true to turn it on for every company on the deployment. Use a list of company IDs when only some companies may run it:

    COMPANY_CONFIGURATION_CODE_EXECUTION_ENABLED: "225336703097770043:true;257914415460909091:true"

The two forms behave differently. *:true writes a deployment-wide default. A company that an admin has switched by hand keeps its own value. A companyId:true pair writes a per-company value, which is stronger, and it is written again on every restart — also over a value an admin set by hand.

Before you turn it on, check these three points:

• The Code Execution sandbox runs on Azure OpenAI. Do not turn it on if your models come from on-premise, AWS, or a non-Azure LiteLLM.

• FEATURE_FLAG_USE_OPENAI_V1_13819 must be on. If it is off, keep Code Execution off, or the tool is offered and the call fails.

Scope count moves from scope management to ingestion

countOfScopes is no longer emitted by backend-service-scope-management. client-insights-exporter must scrape it from backend-service-ingestion instead. Until both sides of this wiring are deployed, the metric stops.

Action required. Apply both changes in the same release window.

On client-insights-exporter, add this under internalServices.dependencies in the preview, offset, and stable defaults. On Prod, use the same block with namespace finance-gpt.

ingestion:
  enabled: true
  name: node-ingestion
  namespace: chat

On backend-service-ingestion, add this under internalServices.dependents in the preview, offset, and stable defaults:

clientInsightsExporter:
  name: client-insights-exporter
  namespace: apps

Reflector service now needs the credentials passed through the kong plugin

As the reflector service now is secured via cookie credentials, they need to be allowed to pass through the Kong plugin in order to avoid CORS issues.

Example of CORS plugin to allow credentials

- apiVersion: configuration.konghq.com/v1
    kind: KongPlugin
    metadata:
      name: reflector-cors
    plugin: cors
    config:
      origins:
        - {THE PUBLIC URL OF THE CHAT APP (example: next.unique.app)}
      credentials: true
      max_age: 600
- apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        external-dns.alpha.kubernetes.io/hostname: {THE PUBLIC URL OF THE REFLECTOR SERVICE (example: reflector.next.unique.app)}
        konghq.com/plugins: {YOUR EXISTING PLUGINS},reflector-cors
      name: reflector