Core UI service

The Core UI service is the Node.js process that ships inside the UI container. It serves the web client's static assets and provides the HTTP endpoints that belong to the frontend rather than to App Suite Middleware. It follows the Backend-for-Frontend pattern: a small server owned by the UI team, deployed with the UI, released on the UI's cadence.

It replaced the previous static nginx container in 8.46. It has different resource characteristics - read Breaking changes and requirements before upgrading an existing deployment.

Why it exists

Some work cannot be done in the browser and does not belong in the Java middleware:

• Requests that must not originate from the user's browser, because they would leak the user's IP address or require outbound network access the browser does not have - DNS lookups for BIMI, or one-click unsubscribe requests to a sender's endpoint.
• Work that needs secrets, such as signing JWTs.
• Operator-provided content that is mounted into the container, such as signature and template catalogs.

Putting these in the UI stack means they can be built, configured and released with the UI, rather than requiring a middleware release.

It deliberately does not hold domain data. Mail, calendar, contacts, tasks and files stay with the Middleware.

What it serves

All routes are mounted under the /ui prefix.

Static UI assets are served from the same process.

Authentication

The service issues the JWTs that newer services - for example the AI Service - use to authenticate requests, bridging from App Suite's cookie-based session via the Middleware's token login API. The flow, the required Middleware properties and the service configuration are documented under Authentication.

Outbound requests

Both BIMI and one-click unsubscribe make requests to hosts named in a message. That makes them an SSRF surface, so the service resolves and validates the target first: hostnames are resolved explicitly and the resulting addresses are rejected if they fall into loopback, link-local, private, unique-local, multicast or other reserved ranges, and requests are bounded by a timeout. Logos are sanitized before they are served to the browser.

Deployments that route egress through a proxy or use a custom CA need to configure that at the container level; see the Helm chart values.

Configuration

The service reads a YAML configuration file, mounted into the container. Its own feature switches are separate from the UI's settings - the UI's feature toggles come from the Middleware over JSlob, while this file configures the service itself. BIMI, for example, is enabled here and additionally accepts operator-configured logo records for specific domains.

features:
  bimi: true
bimi:
  records:
    - domain: example.com
      selector: default
      type: cmc
      file: /etc/bimi/example.svg

See BIMI for the full set of options.

Storage and metrics

The service uses a MariaDB schema for the data it caches itself, with migrations applied on start. It exposes Prometheus metrics, and dashboards are shipped alongside the chart.

Sizing

The Node.js service needs more memory than the static nginx container it replaced, particularly with BIMI enabled. The chart defaults to 256Mi for both request and limit, and deploys two replicas. A CPU request is set but no CPU limit, so the service can absorb short bursts without being throttled; if your cluster policy requires a limit, 1 CPU is a reasonable value.