Nauka splits every file into Reed-Solomon shards scattered across the nodes of
a cluster. As long as k shards per stripe survive somewhere, the file comes
back byte-for-byte identical.
Membership is explicit and yours: the first machine founds the cluster, every
next one is added with a single command that provisions it over SSH and takes
it through consensus. No discovery layer, no central server, no side
infrastructure to keep alive.
Terminal window
# first machine — installs nauka and founds a systemd-managed cluster
curl-sSfLhttps://sh.getnauka.com|sh
# every next machine, run from the first one
naukanodeadd<ip>:7311
Durable by arithmetic, not by copying
4+2 by default: every stripe survives losing any 2 shards out of 6, for a
50% storage overhead — where ×3 replication charges 200% for the same
tolerance. BLAKE3 integrity is checked at every boundary; a corrupted
shard is caught on read and treated as lost, never served.
It repairs itself
A scrubber checks every file continuously and regenerates missing shards
from the survivors. A node that dies is healed around; a node that comes
back is refilled; a node you remove is drained. Nothing to babysit —
what survives what is spelled out, not implied.
Built for machines that are far apart
Nodes learn their network positions from the round-trip times they
measure (no GeoIP database) and pull each stripe’s shards apart, so a
file survives the loss of a region — not merely of a machine. Metered
links get monthly egress budgets:
exhausted nodes are deprioritized, never refused.
Proofs, not claims
A node can assert it still holds what it has quietly lost. Nauka demands
blake3(nonce ‖ bytes) proofs of possession before it gives
up any redundancy, and audits its peers continuously by sampling.
Topology-aware placement (learned, not configured)
✅
❌
❌
❌
Nauka is the storage engine, deliberately bare: it exposes an HTTP API and —
behind an opt-in build flag — an S3-compatible endpoint. User-facing
applications belong in products built on top, not in the engine.