Platform Configuration Persistence
Nothing erodes trust in a platform faster than configuring everything with care — contexts, prompts, the visibility matrix — and watching the work vanish after an upgrade. That does not happen in DATTA: every runtime setting made through the interface is written to durable storage and survives restarts, upgrades and even a reinstall of the platform, with no action on your part.
Since 8 May 2026, the runtime configuration and the prompts live on a dedicated volume of the installation. Before that they lived in a temporary area (/tmp/datta-runtime-config.json) and the domains registered through the interface vanished on every restart — the very problem this change closed.
What is preserved
- Data contexts and domains registered through the interface, in .
- Per-context prompts, kept in the prompts folder of the same volume.
- Other runtime settings adjusted through the console.
Writing is immediate: saved in the interface means persisted. There is no extra "apply" or "publish" step.
How the storage is sized
The parameters below are part of the platform installation and rarely need adjusting:
| Parameter | Default | What it is for |
|---|---|---|
| Persistence | on | Keeps configuration and prompts out of the temporary area |
| Volume size | 1 GiB | Wide margin: configuration + prompts typically take ~50 KB |
| Storage class | empty | Uses the installation's default storage |
DATTA_CONFIG_PATH | /data/datta-config/runtime-config.json | Runtime configuration file |
DATTA_PROMPTS_PATH | /data/datta-config/prompts | Folder for the per-context prompts |
The volume is created by the installation itself with a retention policy: it is preserved even when the platform is uninstalled. A reinstall finds contexts and prompts exactly where they were — reinstalling never costs you the configuration.
Backup and restore
Even with automatic persistence, keep safety copies: they cover disk loss and human error (for example, deleting a context by mistake).
- Volume snapshots — the storage environment allows taking snapshots of the configuration volume. Automatic scheduling of those snapshots is not delivered yet; today they are triggered on demand.
- Manual restore — the procedure is: copy the
runtime-config.jsonfile out of the volume, keep it as a backup and, when restoring, put it back at the same path and restart the platform's configuration module. All of that is done from the administration console, with no direct infrastructure access.
Migrating older installations
Installations older than this change, which still wrote to the temporary area, lose the configuration on upgrade — it is not migrated automatically. In that case:
- Re-register the domains through the interface in or with the
scripts/recreate-domains.shscript. - Nothing else is needed: automatic cataloging fires for every new domain and repopulates the Knowledge Catalog in the background.
Good practices
- Do not try to bypass persistence by pointing the settings back at temporary areas "for development". Durable storage is provisioned instantly, even in a local installation, and has no extra cost — the temporary area only brings the original problem back.
- The configuration storage takes a single writer. That is why the configuration module runs as a single instance; multiple simultaneous replicas are not supported in the current version. A high-availability setup would require shared storage with concurrent writes, or moving the configuration to the platform's shared cache.
- Periodic backups of the configuration along with the data, in the same routine as the operations team.