Data & Infrastructure Settings
What this screen is for
Data & Infrastructure is the sixth of the eight purpose groups of Platform Settings. It gathers what the platform's data plane runs on: the event-streaming topics and the credentials services use to reach the event broker, the credentials and TLS material of the cache and of the database, the connection pools the services draw from, and the two host locations the environment was created with. Its address says data-messaging while the screen reads Data & Infrastructure; the slug is kept stable so older links keep working.
The group has five subgroups: Messaging, Cache, Database, Connection Pools, and Storage & Paths. Each subgroup is a card on the group landing and a leaf in the sidebar tree; none of them is a subsystem with records of its own, so every leaf here is a plain list.
No value in this group can be changed from this screen. Some are owned by the deployment, the rest are read-only, and many of the read-only ones are masked credentials. Set the Posture filter to Editable and this group's card reads 0 — that is the group's real shape, not an empty result.
What must exist first
This is a platform screen, reached in the platform context and served only to the platform tenant. Opening it from inside a tenant sends you to that tenant's dashboard, and the request behind it is refused with a bare Forbidden that names neither the tenant nor the permission.
- The permission to read platform configuration. It is what puts Platform Settings in the sidebar and what loads the catalogue these cards count. The platform super administrator, auditor and viewer roles hold it.
- The permission to write platform configuration buys you nothing on this group. Every value here answers
405 Method Not Allowedon a write, and it does so from the catalogue rather than from your permissions — so the refusal is identical for a platform administrator and for a viewer. - No separate subsystem permission. Unlike Cryptography & Trust, no leaf in this group administers records, so platform-configuration read admits you to all five.
- Nothing here is gated on the deployment model: the five subgroups are offered on an ANKA-hosted and on a customer-operated install alike.
Decisions you make here
What this group is actually for
Reading. It is the one place that states, in one list, what the data plane was built with and where each value comes from — which is what you need before you change a deployment file, and what an auditor asks for.
Every row carries the same five facts: the key, the description, a badge per service the catalogue says consumes it, the effective value or —, and whether a value is Set or Not set. A non-writable row shows a lock instead of an edit control, and a deployment-owned row additionally names the deployment setting that owns its value, so you leave knowing what to edit rather than only that you cannot edit it here.
Two consequences worth knowing before you read a value:
- The source badge is mostly a raw layer name —
ENVorCODE_DEFAULT— because only one of the five source values is written out in words. That one is Not visible from admin-api, and it appears on a value that is read by some other service and that the deployment supplied nothing for here. - Nothing in this group can be changed here, so nothing you do on this screen can raise the Restart required banner. If you see it, it was raised by another group.
Rows inside a leaf are sorted by key, which puts the UPPER_SNAKE deployment names and the dotted property names in two separate runs. The filter box above the list matches the key, the label and the effective value, and it never fetches.
Messaging
The topics that carry the audit trail, the dead-letter topics for undeliverable notifications and undeliverable SIEM/XDR forwards, a flag stating whether event publishing is enabled at all, and the credentials and client TLS material each service authenticates to the event broker with. The keys that seal and sign outbound notifications are here too.
All of these are read-only, and the credentials are masked: the platform substitutes a sentinel before sending, so the console never holds the value and there is no reveal control anywhere on this surface.
One entry is deployment-owned: the retry interval after the event broker refuses a service's authorization at start-up. It exists for the window in which a consumer starts before its broker permissions are in place. Zero or negative stops the service from starting; a long interval leaves consumers idle after permissions are granted, and events pile up while the audit trail lags.
There is no broker address on this screen. The connection endpoints are not catalogue values, so the subgroup's one-line description on the card promises rather more than the leaf contains.
Cache
All masked credentials, all read-only: the cache server's own TLS certificate and private key, the CA the services trust when they verify that certificate, the password the services authenticate with, and the signing key for the cached role-to-permission mappings and their invalidation messages.
The authorization data the services share and every platform-settings change are not signed by a value here. They are signed with the projection signing keys, which only the administration service holds and which you read and rotate under Cryptography & Trust.
What this leaf gives you is presence, not value. Each row reads Set or Not set beside the layer that supplied it, which is enough to answer "was this credential ever provisioned?" and nothing more. Rotating any of them is a deployment operation.
Database
All masked, all read-only: the passwords of the database roles the platform connects with, the CA certificate the services trust for the database server, and that server's own TLS certificate and private key. As in Cache, the leaf answers presence only.
Note what is absent: no connection URL, no schema name, no datasource tuning. The pool sizing lives one card away under Connection Pools, and the connection string is not a catalogue value at all.
Connection Pools
The only subgroup in this group with parameters a deployment genuinely tunes. The tunable ones are deployment-owned and each names its deployment setting on the row; the database connection timings — acquisition, idle, maximum lifetime, minimum idle and validation — are read-only and reported for visibility only.
The database pool sizes are classified sensitive, and the reason is one shared ceiling: every pool in the deployment draws on the same database connection limit, so an oversized pool starves the other services rather than speeding its own up, while an undersized one makes requests queue for a connection and time out. Pools are built at start-up, so a change lands on the next restart of that service.
Another set governs the shared service-to-service connection pool: its maximum connections, its idle and total lifetime limits, the background eviction interval, and how many requests may queue for a connection.
Two of those are checked when the service boots, and failing either stops the service rather than degrading it: the idle time must stay below the 60-second upstream keep-alive ceiling, and the total lifetime must not be shorter than the idle time. The idle limit is the eviction lever that stops a connection being reused after the upstream has already closed it, which is why pushing it toward the ceiling brings back intermittent gateway errors that read as upstream faults.
The last is the connection leak-detection threshold. Set it above the slowest legitimate query or every long report floods the logs with false leak traces; set it to zero and leak detection stops entirely, so a genuinely leaked connection stays invisible until the pool is exhausted.
Storage & Paths
Two read-only values: where the environment's persistent data lives on the host, and where its secrets are mounted. Both are reported as (auto) in the catalogue default, because the environment chooses them when it is created.
How it relates to other screens
The group root explains the vocabulary this page assumes — posture, source, assignment, the propagation types and the restart banner — and is worth reading once:
What this group reports on, two other screens act on: the map of what your installation is connected to, and the live view of whether those pieces are answering.
The resilience knobs that surround these pools — retries, circuit breakers, timeouts and the caching tiers — are a group of their own:
The keys that sign the platform's shared authorization data and its settings changes: