Files and storage¶

koinon persists original files as well as the knowledge extracted from them. An installation needs its database state, referenced objects and protected encryption material together to recover a complete repository.

Know what is stored¶

Store	Contents
Documents	Original versions, normalized artifacts and replay inputs tied to recorded source identities.
Structured data	Original dataset files, registered Parquet snapshots and retained query results.
Private chat files	Owner/conversation-scoped originals, normalized content and registered staging.
Durable bulk staging	Exact originals admitted to file batches, upload attempts and retained receipt inputs before canonical processing. This has an independent private storage profile.
PostgreSQL	Ownership, permissions, catalog/version bindings, hashes, source text, indexes, jobs, conversations, audit, profiles and encrypted credentials.

The document, structured and private-chat stores can each use local storage, S3, Azure Blob Storage or Google Cloud Storage. They have independent profiles. Durable bulk staging separately supports local storage, Azure Blob Storage or Google Cloud Storage; its pinned queued-file contract does not currently support S3. Object storage does not replace PostgreSQL, and an index is not a backup of the originals.

Find the right guide¶

What you need to do	Read
Set up a new store, credentials or environment variables	Configure storage providers
Understand durability, limits, shared mounts and cloud behavior	Durability and limits
Configure queued Library originals and their consumers	Durable bulk staging and worker roles
Move retained data or rehearse recovery	Migration and recovery
Connect an external enterprise document system	ECM integration
Create and check database backups	Backup and recovery

Configure the installation¶

Storage belongs to protected deployment configuration. Organization administrators can inspect observations in Settings, under Storage & indexing, in Deployment observations; model-provider settings and personal API tokens do not change a bucket, container, mount or cloud identity.

For one machine, use private persistent volumes. Multiple instances need the same intended shared stores and database bindings; separate node-local directories do not provide shared storage. Provision cloud namespaces and their least required permissions before qualifying the deployment.

A valid profile and installed SDK establish configuration. Cloud availability remains unknown until separately observed. Check credentials, object reads/writes, private access, signing where required, and restoration against an owned test namespace before relying on a deployment.

Change an existing store¶

Changing configuration does not copy files or rewrite historical snapshot URIs. Inventory and back up the complete state, prepare a fresh target, compare registered keys and exact bytes, then rehearse access and restoration before cutover. Both local attachment root bindings must agree when the retained compatibility setting is present. The migration guide gives the complete procedure.

Bulk work remains separate¶

When its capability is configured, ordinary Library uploads use the same durable source batches as headless callers: queued originals up to 128 MiB each and 512 MiB per batch, subject to effective lower limits. Their staging profile and file-batch consumer are independent prerequisites. The synchronous upload endpoint remains at most 32 MiB; larger originals are not silently sent through it when queued storage is unavailable.

A cloud adapter alone does not supply the native admission, lease, authorization or immutable publication contract. The Library file profile records raw/expanded/object/parser bounds and the lifetime quota policy. Preserve every accepted receipt and reconcile unknown outcomes explicitly. A submitted batch is not yet searchable knowledge; verify per-file processing and final availability.