Self-hosting

Backup & data

eli.ai keeps state in two places: Postgres (the authoritative store for everything with no file form — entities, relations, runs, evals, traces — plus the derived content index) and the vault on disk (the source of truth for document content and attachments). A complete backup covers both. This page is the durability and retention contract.

"Backup = copy the files" corrupts a live database

Copying Postgres's data directory out from under a running server tears the write-ahead log and is silently broken until restore day. Always back up the database with a consistent tool (a logical dump or a managed snapshot), not a file copy.

Postgres

Supabase.Supabase supplies managed, point-in-time backups — it replaces the need for a self-run database dump sidecar. Confirm the retention tier meets your engagement's requirements.
Self-run Postgres. Take a consistent logical dump on a schedule and ship it off-box encrypted (e.g. pg_dump -Fcpiped to an encrypted store like restic). Delete local dumps after upload, prune old images, and alarm on a disk-usage threshold — disk fill is the identified 2 a.m. page.

a consistent DB backupbash

# self-run: custom-format dump, then push to encrypted off-box storage
pg_dump -Fc "$DATABASE_URL" > eli-$(date +%F).dump
restic backup eli-*.dump && rm -f eli-*.dump   # local copy removed after upload

The vault (files)

Vault markdown and attachments live under DATA_DIR/vaults/<workspace>/. Managed database backups do not cover these — the vault needs its own file backup. Because the vault is plain markdown, it is also git- and Dropbox-syncable; keep the derived index (which lives outside the vault) out of that sync so the two never fight.

back up the vault + exportsbash

# DATA_DIR holds vaults/ (source of truth) and exports/
restic backup "$DATA_DIR/vaults" "$DATA_DIR/exports"

Export tarballs vs. backups

Don't confuse the two. A backup is your operational safety net — it contains everything, including internal cost/margin data. An export is a client deliverable — a .tar.gz of the client-facing KB (vault markdown, the graph as JSONL, golden sets, a manifest) that excludesthe consultant's economics by construction. Never hand a raw backup to a client; use an export. See Export & offboarding.

Deletion & retention

Deletion in eli.ai is designed to be honored, not deferred:

Soft-deleting a document synchronously hard-deletes its derived rows (chunks, FTS, vectors), so retrieval can never surface deleted content before any nightly job.
A hard purge cascades through every verbatim-text copy — version snapshots, mention surface text, relation-evidence quotes — and flags affected eval items and traces.
A workspace delete is a full cascade (content, graph, conversations, gap events, traces, eval history, plus blob removal) that writes a dated destruction record referencing the documented backup-retention window.

Retention window is part of the contract

Because destruction records reference the backup-retention window, be explicit about it with clients: data purged from the live system may persist in encrypted backups until that window elapses. Set the retention to match your data-processing agreements.

Restore drill

A backup you have never restored is a hypothesis. Periodically restore a dump into a scratch database and a copy of the vault into a scratch DATA_DIR, point a throwaway instance at them, and confirm documents render and chat cites. See Deployment for standing up an instance.