Skip to main content
Configuration and secrets back a server’s environment and settings. A built-in file provider ships by default, and the store is swappable behind one contract, so a server can read its config from a file, from Kubernetes, or from another backend without any change to the code that consumes it.

​
The provider seam

Config is a pluggable-provider feature. The skeleton ships the selection seam — a config mode, its settings, and a factory that maps a mode to a provider module — and the default file provider. The active mode is chosen with TAI_CONFIG_MODE (file by default). The factory loads the selected provider by dynamic import and builds its manager:
Other providers ship as separately installed plugins that expose the same build_config_manager() convention. The factory needs nothing but the mode and the module; the consuming code never knows which provider is behind the manager.

​
Secrets are referenced, not embedded

Sensitive values are referenced by the name of the environment variable that holds them, not by value. A secret_env field carries an env var name; the runtime reads the secret from the environment at use time. So a manifest, a hook, or a webhook verifier binding names secret_env and never contains the credential itself — keeping secrets out of files that are edited, versioned, or displayed.

​
How a config change is written

Every change to the manifest or env — a tool reload, a manifest replace, a live env edit — runs one mutation pipeline: validate the resulting config, persist it transactionally, reload the calling process, then broadcast on the worker bus. Persisting before reloading is why the persisted config and the live config cannot drift apart through a supported path — the running state is always what is on disk. Two guarantees hold across every provider:
  • Transactional writes, in both config modes. A write holds exclusive access across the whole read-modify-write span, so a concurrent writer cannot interleave and lose an update — the file provider takes a lock, the k8s provider retries on an optimistic-concurrency conflict.
  • Comment preservation. A manifest edit keeps the surrounding comments, key order, and formatting of the untouched document. An automated edit does not reflow a file a human maintains by hand.

​
The plugin model

Config providers are one member of a broader pattern. A plugin is any separately-shipped package that registers through the tai42_app contract handle — connectors, storage backends, config providers, backends, monitoring, and webhook verifiers. A plugin is loaded because the manifest names its module, and no plugin imports the skeleton, which is what keeps the core provider-free and the ecosystem open-ended. Change environment values and read the active mode from the CLI:

​
Settings reference

Every setting below is read from the environment (or the managed .env store) at use time. These are hand-maintained here — there is no generated reference for the skeleton, toolbox, and agents settings, so this page is their canonical home.

​
Core environment

​
Worker bus

The worker bus is app-owned internal infrastructure — a plain-Redis fan-out primitive, not a plugin. It is configured entirely through these TAI_BUS_* variables; no manifest field selects a bus.

​
Connector token encryption

Connector OAuth token blobs are encrypted at rest. Supply the key by env var name — the value is never embedded in a manifest.

​
Proxy pool (tai42-toolbox)

​
Timeouts and limits

Guardrails on downstream calls, concurrency, and payload sizes. All have safe defaults; raise a timeout only when a legitimately longer operation needs it. Per-feature connection timeouts. Each Redis- or Postgres-backed feature carries its own connection tuning under that feature’s env prefix. Postgres connections expose <PREFIX>PG_CONNECT_TIMEOUT (default 10) and <PREFIX>PG_STATEMENT_TIMEOUT_SECONDS (default 60) — for example ACCESS_CONTROL_STORE_PG_CONNECT_TIMEOUT, VERSIONING_STORE_PG_STATEMENT_TIMEOUT_SECONDS. Redis connections expose <PREFIX>SOCKET_TIMEOUT and <PREFIX>SOCKET_CONNECT_TIMEOUT — for example ACCESS_CONTROL_SOCKET_TIMEOUT, TAI_TOOL_RUNS_SOCKET_CONNECT_TIMEOUT.
A specific config provider’s setup — for example which secret store and config source it reads — lives in that provider package’s own repository, reachable from the catalog. The platform documents the provider contract, not any one provider.
See the config-provider author guide for writing a provider and the CLI reference for tai config.