Runtime settings & administration

Retention, concurrency and performance.

The Settings page is the administrator's control panel. It is restricted to the Admin role — other users do not see it, and a direct link shows a forbidden notice. It is organised into four tabs.

Users & roles

Because users and roles are managed in your identity provider, this tab is mostly informational: it shows which provider is active and offers a deep link to its admin console. It also reminds you that the other provider ships wired in but is selected at server start, not from the UI. See Authentication & Roles.

Runtime

The Runtime tab holds the runtime's own tuning knobs, grouped into sections with a searchable side navigation (the same layout you are reading this documentation in).

Run history

• Retention — how long run records and audit-log entries are kept before the cleaner trims them. Default 30 days; range 1–365.
• Global max concurrency — the maximum number of jobs running concurrently across the whole system. 0 means unlimited (only per-client limits apply).

Session

• Cookie lifetime — how long a signed-in user stays logged in before re-authenticating. Default 480 minutes. Applied to new sessions after the next server restart.

Transport tuning

HTTP/2 flow-control and keepalive settings for the gRPC + Arrow Flight transport between the clients and the server. These tune throughput over the WAN; the defaults are sensible and rarely need changing.

• HTTP/2 stream window — per-stream flow-control window. Larger lets the server receive bigger Arrow batches in one burst. Default 16 MiB.
• HTTP/2 connection window — caps total in-flight bytes across all streams on one connection. Default 64 MiB.
• HTTP/2 keepalive — periodic ping to keep NAT/proxy entries alive across the long-poll hold. Default 20 seconds; 0 disables.

These bind when the server process starts. A field whose saved value differs from the value the server is actually running shows a Pending restart badge until the server is restarted.

Run-logs storage

Where per-run debug bundles land — the server log, the client log, and a snapshot of the run record. Configure a storage backend (Azure Data Lake Storage Gen2 today), a storage account, a container, an optional path prefix, and an authentication method (Managed Identity, account key, or SAS token). This is independent of where each destination stages its data.

Leave the backend unconfigured to disable bundle capture: runs still complete, but the Download bundle button on the run detail page stays disabled. See Monitoring & Runs.

Integrations & security

The Runtime tab also carries the master switches for the optional integrations. Each one, when enabled, reveals its own sidebar entry:

• Secrets / Vault — keep credentials in Azure Key Vault or HashiCorp and reference them with @kv(...). See Secrets & Vault.
• Firewall — ordered allow / deny rules evaluated at the start of every transport run. See Firewall.
• Git integration — version your configuration as YAML and deploy it between instances. See Git integration.
• Presidio (PII) — server-side PII detection / anonymization. See Presidio.
• Schema Registry — the catalog of landed dataset shapes. See Schema Registry.

Audit log

A searchable, time-ordered record of configuration changes and operator actions — who changed what, and when. Filter by the toolbar at the top and page through the results. Audit entries are trimmed by the same retention window as run history.

Client distribution

Where you manage the on-prem client MSI installer. Each release is published with matching release notes that the UI renders here, and an administrator promotes a release to be the current download. The version that the Information page and the Clients page report as available is the one promoted here. See Clients.