nanocached

A tiny distributed in-memory cache written in Rust. One small binary per role, a wire protocol you can read with nc, and clients that do the clustering — no proxies, no coordinators.

Get started Source on GitHub

Experimental. nanocached is not ready for production use yet. The protocol and APIs are stable within v1, but the project is young — treat it accordingly.

Small on purpose

An in-memory key-value store with get / set / delete, optional TTL, and LRU eviction under a memory bound. Nothing else.

Client-side clustering

Clients route keys with rendezvous hashing over a node list served by a lightweight discovery server. No proxy hop on the data path.

Replication built in

Each key lives on its top-R nodes (default R=2). A node death costs no cached data: reads fail over, writes recover within seconds.

No single point of failure

Discovery replicas hold only soft state rebuilt from node announces — run several with zero coordination between them.

Auth and TLS, all or nothing

Shared-secret authentication and TLS are off by default and strictly required once enabled — no plaintext fallback.

A protocol you can read

ASCII headers, binary-safe bodies, one-byte commands. Debug a cluster with printf and nc.

Try it in a minute

docker pull ghcr.io/nanocached/nanocached-node:latest
docker run --rm --publish 8356:8356 ghcr.io/nanocached/nanocached-node:latest

# store "Alice" under "name", then read it back
printf 'S 4 5\nnameAliceG 4\nname' | nc 127.0.0.1 8356

The server answers S, then V 5 and Alice. That is the whole protocol experience — the reference fits on one page.

Six SDKs, one behavior

Every client speaks the same handshake, routes with the same hash, and recovers from the same failures — verified against shared cross-language test vectors.

TypeScriptPythonJava Rust.NETGo

Point any of them at a single node or at a discovery server; the SDK detects which from the server's own reply and behaves accordingly. See SDKs for install and quick-start snippets.

Plan before you size

Memory, effective capacity, replication factor, TTL, and hit rate trade off against each other — and only the binding constraint responds to tuning. The capacity planner is a self-contained, offline estimator that shows which lever actually moves your hit rate.