Where Data Lives
"Local-first" is only worth something if it is auditable, so this page is the audit: every place this server persists anything, its lifetime, its deletion path, and the complete, short list of ways any byte can leave the machine. A reviewer should be able to read this page and know what to write in the data-protection assessment; an operator should be able to read it and know what to back up.
1One root: the state directory#
Everything the server writes resolves under ONE directory, decided at startup: the
executable's own directory when it is writable (services, portable installs, dev builds),
otherwise the local application-data folder, and LMKIT_STATE_DIR pins it explicitly. The
startup log names the directory and which rule applied. This is the single path that
matters for backup, disk sizing, and disposal: back it up and you have the server's state;
wipe it and the server has never seen your data.
2The inventory#
| Store | Where | Lifetime and deletion |
|---|---|---|
| Uploaded files | upload/ under the state directory |
Swept automatically after MaxFileRetention (default 30 minutes, live-configurable); DELETE /lmkit/v1/files/{id} removes one immediately; a retain-all switch exists for workflows that manage deletion themselves. |
| Job records | Memory only, never disk | Kept one hour after completion, gone on restart; the full contract is Errors, Retries, and Jobs. |
| Request audit trail | On disk, bounded by RequestHistoryCapacity (oldest records roll off) |
Body and response captures are LEADING BYTES only, bounded by the preview settings, and 0 disables capture entirely; textual content only, so uploads are never mirrored into the trail. |
| Logs | server.log under the state directory |
The capture level is the write floor: entries below it are never recorded, not recorded-then-hidden. |
| Agent memory | memories/ under the state directory |
Facts persist until deleted: per-fact deletion and consolidation from the admin surface, which is the data-subject-request path. |
| Skills | skills/ under the state directory |
Plain folders you manage like files, because they are files. |
| Search indexes | Embedded per-cluster SQLite databases under the cluster's data directory, or an EXTERNAL database you operate (PostgreSQL and friends) when configured | Deletion is first-class: collections and tenants delete through the Search API; external databases follow your own operational policy. |
| Models | The model storage directory (LMKIT_MODELS_DIR overrides) |
Downloaded model files; delete from the admin Models section. Content, not user data. |
| Inference state | Hibernation and offload files under the temp/hibernation directory | Strictly transient: a payload only means anything to the engine that wrote it and dies with it. |
| Settings and credentials | The runtime settings file plus sidecar stores under the state directory | API keys are stored as SHA-256 hashes (the plaintext exists only in the moment of creation, shown once); configuration is readable text an operator can review line by line. |
| Training artifacts | The training workbench's output folders | Datasets you provided and models you produced; yours to keep or delete. |
Two general rules ride across every row. Retention settings are read LIVE, so tightening a policy applies on the next sweep without a restart. And nothing above is hidden state: every store is a file or folder an operator can inspect with ordinary tools.
On a load-balanced fleet the map shifts deliberately: operator identity, API keys, and
stored responses move into the shared admin database (Admin:Identity), uploads and models
onto shared volumes, and search onto external engines, so the durable truth lives where your
database and storage practice already governs it; each node's state directory keeps only
that node's own operator history (Scaling Out).
3What can leave the machine, exhaustively#
By default: nothing. Prompts, documents, extractions, memory facts, and search content are processed and stored locally, full stop. Bytes leave only through channels an operator explicitly configures, and each is individually controllable:
- Model downloads: pulling a model from the catalog fetches it from its hosting repository. Air-gapped deployments pre-place files in the model directory instead.
- Web-reaching tools: web search and HTTP tools run under the egress policy: a mode plus an allowlist, so "the agent can reach the web" is a decision with a scope, not a default.
- MCP connectors: tool calls to the external MCP servers you attach carry whatever arguments the exchange produces; attach only endpoints you trust with that.
- Telemetry export: metrics flow to YOUR OTLP or Prometheus endpoints only when telemetry export is enabled; the admin panel's own view works without any export.
- SSO: when admin SSO is enabled, the OIDC exchange talks to your identity provider, and to nothing else.
There is no sixth channel: no usage phoning home, no license pings carrying content, no background "improvement" uploads. If the machine's firewall blocks everything outbound, the server still serves everything local.
4The disposal story#
Decommissioning a server or answering "forget this person" is mechanical because every store has a named path: delete the memory facts (per fact or per memory id), delete the tenant's search collections, delete uploaded files (or wait out retention), let job records expire, and finally remove the state directory itself. The security model covers who is allowed to do each of these.
5Stated plainly#
- One state directory holds everything; back it up to keep the server, wipe it to dispose of the server.
- Every store has a stated lifetime and a deletion path; the shortest-lived data (uploads) cleans itself up in minutes by default.
- Exactly five channels can send bytes out, all opt-in, all scoped; a default install sends nothing anywhere.