Data storage and lifecycle

Obot stores platform records, activity history, and workload files separately. Each needs its own plan for surviving restarts, removing old data, and recovering from a failure.

Where data is stored

Use an external PostgreSQL database for production, configured through OBOT_SERVER_DSN. See Kubernetes production deployment.

The bundled PostgreSQL database is for testing and evaluation. In that setup, the Docker deployment uses a /data volume to retain its database and local files.

Data	Storage
Platform configuration, identities, and metadata	External PostgreSQL in production; bundled PostgreSQL for testing and evaluation
MCP and LLM audit records	The Obot database
Device scan history	The Obot database; scans can include captured configuration files containing sensitive content

Keep files across restarts

The database, Obot server's data volume, and any persistent files used by MCP servers serve different purposes. Back up each store your deployment uses.

For testing and evaluation, retain the Docker /data volume to keep the bundled database and local files when replacing the container.

The Kubernetes persistent storage guide covers the Obot server data volume.

Decide how long to keep activity records

Retention controls when Obot automatically deletes old records. MCP audit logs, LLM audit logs, and device scans each have a separate retention setting; changing one does not change the others. Choose the retention period for each in Server configuration.

If you need MCP or LLM audit records after their retention period ends, export them before cleanup removes them. Configure how long exported files are kept in the destination storage separately.

Understand what encryption protects

Application encryption is disabled by default. When configured, it protects selected stored fields, such as credential secrets and gateway request and response bodies. Other metadata can remain readable. The encryption coverage table lists the protected fields.

Configure encryption for exported logs, storage volumes, and backups through the systems that store them. Obot's application encryption does not encrypt those stores as a whole.

Turning encryption on also does not encrypt all previously stored data automatically. An existing installation may need a separate data migration; account for that when planning the change.

Understand what deletion and access changes remove

Some resources contain copies of other resources. Removing the source or changing access does not necessarily remove those copies.

Action	Effect
Delete an MCP catalog entry	Existing vMCPs can keep using their saved snapshot of the entry. Review, update, or delete the affected vMCPs separately. See vMCP snapshots and updates.
Remove a Git-managed vMCP definition from its catalog source	A successful sync deletes that vMCP. This differs from deleting a catalog entry used by an independently managed vMCP. See Git-managed vMCPs.
Remove a skill source or a regular user's last access grant	The affected skills are no longer available to that user for discovery or installation through Obot. Copies already installed on clients remain. See skill access.

Back up the stores you need to recover

Persistent storage keeps files across workload replacement; backups let you recover from deletion, corruption, or loss of that storage. Back up the database and the file or object stores your installation uses, and retain access to any encryption keys needed to restore them. Follow Backup and recovery to plan and test a restore.