Data and security

This page describes the Keragi security model, data storage, deployment hardening and risk notices. Your rights and obligations are governed by the Terms of Service and Privacy Policy; this page is not legal advice.

1. Security model

End-to-end encryption by default: direct messages, group chats and channels are encrypted on the client before sending; group chats use client-managed Sender Keys.
Keys stay on the client: private keys and conversation keys are not sent to the server. The server only relays (and, when necessary, blind-stores) ciphertext and cannot decrypt message content.
Minimal server role: the server handles accounts, devices/public keys, routing and the ciphertext synchronization it needs. This is not anonymity — the server still processes the connection and account metadata required to operate the service.
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 privacy and retention practices are controlled by that provider and are outside the end-to-end encryption boundary.

2. Data storage

Keragi uses server relay, client storage by default: the server only relays or blind-stores ciphertext, while messages, keys and history stay on the client. Deleting client data may make messages unrecoverable or impossible to decrypt.

For storage locations, decryption boundaries, backups and deletion risks, see Data storage (a security perspective, kept separate from database deployment configuration).

3. Server hardening

Use HTTPS / a reverse proxy for public access; never expose administrative interfaces directly to untrusted networks.
Change JWT_SECRET and the bootstrap administrator password before first use. Use a different secret per deployment; a connector server must share the main server’s JWT_SECRET.
Restrict ports with a firewall, run with least privilege and avoid running the host as root.
Restrict permissions on data/ and .env; protect backups as well, and keep them encrypted and offline where appropriate.
Review wasmx.log regularly and keep the host and WASM resource packs up to date.
In multi-server deployments, install only the resources each role needs to reduce the attack surface.

4. Client hardening

Use a screen lock/PIN or biometrics, keep the OS and browser updated, and avoid extensions or software from untrusted sources.
Never share accounts, private keys, conversation keys or client data backups.
On public or shared devices, sign out and clear local data as directed by the client; first make sure you will not lose messages you need to keep.
Install the client and server only from the official downloads page or official npm packages, not third-party modified builds.

5. Risks and disclaimer

End-to-end encryption cannot protect a compromised endpoint: malware, keyloggers, weak device passcodes, browser extensions, screenshots or a recipient disclosing content can all expose it.
Messages, keys and history ultimately live on the client. Deleting client data, losing a device, resetting the system or skipping backups may cause messages to be permanently lost or impossible to decrypt; the server cannot recover them.
When you enable a third-party AI service, connector or other external service, that provider is responsible for how it processes and retains the content; it is outside the end-to-end encryption boundary.
In self-hosted deployments, the operator is responsible for server access control, network security, backups, logging, compliance and lawful use. We do not control the security of self-hosted environments.
The software is provided as is. To the maximum extent permitted by law, we are not liable for indirect, incidental or consequential losses arising from the use or inability to use the software, data loss, third-party services or self-hosted environments. Specific limitations are governed by the Terms of Service.
This page explains technical characteristics and security recommendations. It is not legal advice or a security guarantee; consult a professional for compliance requirements.

Runtime and database: server platforms and the default SQLite configuration.
Configuration: secrets, ports and resource prefixes.
Deployment example: main server and connector server deployment.