Intended Audience

This page describes who Nabu Store is built for and what level of familiarity you need to work with it effectively. Understanding the intended audience helps you gauge whether the documentation is pitched at the right level for your role and whether Nabu Store fits your infrastructure context. If you are evaluating Nabu Store for a project or onboarding a new team member, start here.

Who This Documentation Is For

Nabu Store targets two primary groups: enterprise engineering teams integrating high-performance AI inference infrastructure, and system integrators building hyper-converged platforms that need a programmable, distributed blob store at their core.

You will get the most out of this documentation if you are comfortable with the following:

• Issuing and interpreting HTTP/gRPC requests and reading JSON or Protobuf response payloads
• Deploying containerized workloads on Kubernetes
• Reasoning about distributed systems concepts such as replication, consistency, and fault tolerance
• Reading configuration files and shell-level tooling

You do not need to be a storage internals expert. The documentation explains architectural decisions — such as why Nabu Store uses a consistent hash ring with 150 virtual nodes, or when to choose EC 4+2 over full 3-replica replication — so you can make informed configuration choices without reading source code.

What You Are Expected to Do

As a primary user of Nabu Store, you will interact with the system through its HTTP-based API to store and retrieve blobs, manage cluster membership, and apply replication policies. Typical activities include:

• Deploying and operating clusters — spinning up single-node instances for development and multi-node clusters on Kubernetes for production
• Issuing authenticated API requests — constructing programmatic clients that authenticate and call blob operation endpoints (Put, Get, Delete, Stat, List)
• Configuring storage policies — choosing between Replica3, EC42, and EC82 based on your durability, capacity, and throughput requirements
• Extending the platform — registering custom storage backends or erasure coding plugins to meet site-specific hardware requirements, including SPDK NVMe and CXL memory tiering
• Operating at scale — adding nodes to a live cluster, diagnosing node failures, and interpreting cluster health and capacity metrics

Who This Documentation Is Not For

If you are an end user of an AI inference application built on top of Nabu Store, this documentation is not your entry point — speak to the team that deployed the platform. If you are a contributor to the Nabu Store codebase itself, the architecture reference and ADR documents in docs/ are a better starting point than the user-facing API guides.

Assumed Environment

The documentation assumes you have access to a Kubernetes cluster (for multi-node workflows) and a working Go toolchain (if you need to build binaries from source). For local development, a single-node deployment on any Linux host with a /data volume is sufficient. SPDK and CXL features require specific hardware and kernel configuration, which is called out explicitly in those sections.

Checking That You Can Reach the API

Before working through any workflow, verify that your Nabu Store node is reachable and responding. The testclient binary performs a round-trip blob operation and is the fastest sanity check for a new deployment.

# Against a local single-node instance
./testclient --addr=localhost:50051

Expected output (abbreviated):

Connected to localhost:50051
Put blob: OK  id=a1b2c3d4e5f60000...
Get blob: OK  bytes=1024
Delete blob: OK

If this succeeds, your environment matches the assumptions in this documentation and you are ready to follow any workflow on this site.

Verifying Access on a Kubernetes Cluster

For multi-node deployments on Kubernetes, you can run the same check against each node to confirm cluster membership and per-node availability:

kubectl exec -it aistore-node1 -- testclient --addr=localhost:50051
kubectl exec -it aistore-node2 -- testclient --addr=localhost:50052
kubectl exec -it aistore-node3 -- testclient --addr=localhost:50053

Expected output (each node):

Connected to localhost:5005X
Put blob: OK  id=...
Get blob: OK  bytes=1024
Delete blob: OK

A failure on one node while others succeed indicates a node-level issue rather than a client configuration problem — see the node failure recovery guide for next steps.

• Architecture overview — Explains the four core components (Blob, Ring, EC, Index) and how a write or read request flows through them. Recommended reading before you work with replication policies or erasure coding configuration.
• Authentication and API requests — Covers how to construct authenticated HTTP requests and interpret common error responses, which is the foundation for all programmatic workflows.
• Install and start a single-node cluster — The recommended starting point if you are new to Nabu Store and want a working environment before reading further.
• Choose and apply a replication policy — Explains the trade-offs between Replica3, EC42, and EC82 in terms of storage overhead, fault tolerance, and workload suitability.
• Monitor cluster health and capacity — Describes the metrics and endpoints you will use to confirm that your deployment is healthy after following any setup workflow.