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 URLs that someone outside the deployment controls: the unsubscribe URL comes from a message, and BIMI's logo and certificate URLs come from the sender's DNS record and certificate. That makes them an SSRF surface, so all of these requests go through one code path with the same rules:

• Public hosts only. The URL must name a public DNS host, not an IP address. The service resolves the host itself and rejects it if any address falls into loopback, link-local, private, unique-local, multicast or other reserved ranges.
• Pinned connections. The request goes to the validated address, so a second DNS answer cannot redirect it to an internal host.
• HTTPS on its default port. The one exception is BIMI's intermediate CA certificates, which CAs publish over plain HTTP on port 80. They are signed, so a tampered download only fails validation.
• Limited redirects. One-click unsubscribe follows no redirects, as RFC 8058 requires. BIMI follows one redirect to the same scheme, host and port.
• Bounded. Every request has a 5-second timeout, and responses are capped at 1 MB.

Logos are sanitized before they are served to the browser.

Deployments that reach the internet only through a proxy set it in the Helm chart. The service then tunnels to the validated address through the proxy; see Outbound proxy. A custom CA for outbound TLS is configured at the container level.

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.