Data storage

This page explains, from a security perspective, where Keragi data lives, who can decrypt it, and what happens when data is deleted. Database choices and deployment configuration (SQLite by default, plans for other databases) are covered in Runtime and database.

1. Server relay, client storage

Keragi uses a server relay, client storage model by default:

Messages, group chats and channels are encrypted on the client before sending; the server only relays (and, when necessary, blind-stores) ciphertext.
The server does not hold private keys or conversation keys and cannot read message plaintext.
Private keys, conversation keys and message history live on the client; the client is the ultimate storage location for message data.

2. What the server stores

The server database mainly holds the non-plaintext data required to operate the service:

Accounts, devices and public keys;
Conversation indexes and the synchronization metadata it needs;
Ciphertext messages during relay/blind storage;
Connector and WASM resource runtime state.

The server may process metadata related to accounts, connections and routing, so relay mode is not anonymity.

3. What the client stores

The client stores the material that can decrypt messages:

Private keys and conversation keys;
Plaintext messages and local history;
Client settings, caches and conversation state.

Location	Main contents	Can it decrypt messages?
Server	Accounts, public keys, conversation indexes, ciphertext messages, connector and resource state	No
Client	Private keys, conversation keys, plaintext messages and local history, client settings	Yes

4. Risk of deleting client data

Important: Messages, keys and similar data ultimately live on the client. Clearing browser site data, uninstalling the client, resetting a device or manually deleting client data may also delete the messages and keys stored on that device. Without another signed-in device or a usable backup, those messages may be unrecoverable or impossible to decrypt. The server only holds ciphertext and cannot recover them for you.

Recommendations:

Do not casually clear browser site data or delete the client’s cache and data directory.
Before switching devices, reinstalling the client or resetting the system, confirm that you have a usable backup or another signed-in device.
For conversations you need to keep long-term, export or back them up using the client’s supported method.
On public or shared devices, confirm you will not lose messages you need before signing out and clearing local data.

5. Backup and recovery

Client backups preserve messages, keys and local history; the exact method depends on what the client supports.
Server backups restore server data such as accounts, ciphertext and resource state only. They cannot decrypt messages and are not a substitute for client backups.
Backup files also contain sensitive data; encrypt them and restrict access.

6. Data path for AI and connectors

AI takeover is client-side logic that decides whether to reply based on conversation settings. When you enable a third-party AI service or connector, relevant conversation content is sent to that service under your configuration; its processing and retention are controlled by that provider and are outside the end-to-end encryption boundary.

Data and security: security model, server/client hardening and disclaimer.
Runtime and database: default SQLite configuration and database plans.
Configuration: server ports, secrets and resource prefixes.