Self-Hosted Agent Knowledge Deployment for Data That Must Stay in Your Infrastructure
Plan a self-hosted AKB deployment: what runs inside your boundary, where data is stored, how vault access works, and what your own team still has to verify.
Keep the store and model calls inside your boundary
- Deploy AKB where you control it: Docker Compose or Kubernetes can run the application and storage in your environment.
- Choose where retrieval data lives: pgvector is the default; Qdrant and self-hosted SeahorseDB are alternatives, while Seahorse Cloud is managed.
- Keep the full path in scope: embeddings, optional model calls, the agent’s LLM, logs, and backups all affect data location.
If agents need internal documents that must stay within your infrastructure, AKB—the Dnotitia agent knowledge base—can run on servers or cloud accounts your organization operates. Docker Compose and Kubernetes deployment options let your team manage the knowledge store and its supporting services. The boundary also depends on where your models, agent runtime, logs, and backups run.
Architecture and data routes
The native stack can run PostgreSQL, MinIO, the API, a separate worker, and the web frontend. The repository README covers Compose setup, and the native installation guide covers native installation paths for Compose and Kubernetes.
| Component | What it holds or does | Data route |
|---|---|---|
| PostgreSQL | Document text, metadata, revisions, and BM25 search data | In your database container or cluster when deployed there |
| Vector index | Dense and sparse search representations | pgvector in PostgreSQL by default; alternatively, a configured vector-store driver |
| Object storage | Files and attachments | MinIO in the deployment, or another configured storage location |
| Embedding endpoint | Converts text into vectors for dense search | The endpoint configured by your team; document text is sent to it for embedding |
| Agent model endpoint | Receives retrieved knowledge as context when the agent uses it | The endpoint configured for the consuming agent |
A local AKB and local embedding model do not by themselves keep retrieved knowledge inside your boundary. Check every hop: embedding, any optional reranking or curation model calls, the agent’s model endpoint, and the locations and retention settings for logs and backups. Data stays within an approved network only when those services and stores are deployed and configured there.
Search options
AKB combines dense vector search with BM25 keyword search and fuses the result lists with reciprocal rank fusion. The vector store is configurable:
- pgvector (default): runs in PostgreSQL.
- Qdrant: runs as a separate service you operate.
- Seahorse Cloud: a managed vector service. Its required schema includes chunk text (
content), section paths and source and vault identifiers, as well as dense and sparse vectors. Retrieval text and metadata therefore reside in the managed service, not just vectors. - Self-hosted SeahorseDB: a cluster you operate.
The Seahorse driver guide explains the configuration. Local drivers keep their data inside your boundary only when the relevant services are actually deployed within your approved network. Seahorse Cloud is managed separately from your AKB deployment.
Access and operations
A vault is AKB’s unit of access control, with reader, writer, and admin roles. akb_grant, akb_revoke, and akb_set_public configure permissions for users, organizations, or public access. For SQL over tabular content, PostgreSQL enforces isolation: a query that reaches another vault fails when the account lacks permission; an authorized account can access the data it is granted.
Map sensitivity levels to vaults—for example, an engineering vault for the wider team and an HR policy vault limited to authorized people and agents. Interactive clients use the authorized user identity. Unattended automation uses a scoped service identity, with permissions limited to what it needs.
Self-hosting means your team operates the environment and owns patches, monitoring, credential lifecycle, backups, and restore procedures. Confirm that storage, logs, snapshots, and replicas follow your organization’s residency requirements, and review provider access where you use public-cloud infrastructure. The Cloud Security Alliance guidance on LLM environments discusses provider access risks in IaaS environments.
Keep the public demo for trying features only; it is public and wiped weekly.
FAQ
Can AKB run fully on-premises?
AKB can run on your own hardware with Docker Compose or Kubernetes, using pgvector, Qdrant, or self-hosted SeahorseDB. To keep the full knowledge path on-premises, also host the embedding model, any optional reranking or curation models, and the consuming agent’s LLM there; keep logs and backups within the approved environment as well.
Does AKB include automatic curation of stored knowledge?
AKB Core is the read/write store; external curation or digest agents are optional consumers. Writes are recorded in a PostgreSQL outbox that can be streamed to Redis; teams can connect curation or digest agents to those events. If those agents make model calls, their endpoints are another data route to keep within the approved boundary when required.
Learn More
See the self-hosting guide and vector store options in the AKB repository.
