Skip to content
ABRQ DATADocs Abrq DIP · latest
Product page Request a trial
On this page

Configuration Model

Two layers#

Abrq DIP configuration lives in exactly two places, with a clean split:

Layer What lives there Changed how Applies
Environment variables Infrastructure and security posture: database URLs, keys, TLS/CORS, run mode, retention windows — about 57 ABRQ_* fields Edit the deployment's env (.env, Kubernetes Secret/values) On process restart
In-app settings Operational settings: notifications, audit forwarding, backups, AI providers, SSO/LDAP, per-resource alert routing, masking and retention policies Web UI (Settings and resource pages) or the API At runtime, no restart

The rule of thumb: if changing it should require an operator with host access, it is an environment variable; if an admin should be able to change it from the UI while the platform runs, it is a DB-stored setting.

In-app settings are encrypted at rest#

DB-stored settings that contain secrets (SMTP passwords, webhook targets, API keys, SSO client secrets, LDAP bind credentials, connector passwords) never sit in plaintext. Secret values live in a dedicated secrets table, encrypted with Fernet under the master key you provide as ABRQ_MASTER_KEY.

  • ABRQ_MASTER_KEY is required — the backend will not start without it. Losing it makes every stored secret unrecoverable.
  • Key rotation is supported: set the variable to a comma-separated NEW,OLD list, bump ABRQ_MASTER_KEY_VERSION, and re-wrap stored rows with the shipped rotation script. See the deployment runbooks for the full four-step ritual.
  • The API never returns a stored secret. Settings surfaces show masked previews and accept write-only updates — see In-app settings for the exact semantics.

Which layer wins#

For almost every field the answer is trivial, because each field exists in only one layer. The one deliberate overlap is notification settings:

  • The DB-stored settings (Settings → Notifications) are authoritative once configured.
  • The legacy env vars (ABRQ_SMTP_*, ABRQ_LICENSE_ALERT_KIND, ABRQ_LICENSE_ALERT_TARGET) are deprecated. They act only as a one-time seed on first boot, into the DB, when nothing is configured yet. After that the DB wins, always.
  • If the deprecated vars are still present in the environment, the backend logs notification_env_config_deprecated on every boot as a nudge to remove them.

Tip. Treat the env vars as install-time bootstrap and the UI as the ongoing home of notification config. Details: Notifications.