§00 · Apache 2.0 · single node to cluster

Start on one node.
Grow into one storage layer.

GrainFS exposes object storage, file system mounts, block volumes, and data lake catalog access from the same engine. Add nodes while the service stays online.

4 protocolsS3 · NFS · NBD · ICE
1 binarysingle process
N nodeslive join
same data, two protocols
# start one local storage server
DATA_DIR=./tmp
make bin/grainfs
CLUSTER_KEY=$(openssl rand -hex 32)
./bin/grainfs serve --data "$DATA_DIR" --port 9000 --cluster-key "$CLUSTER_KEY"

# write once through S3
echo "hello grainfs" > file.txt
aws --no-sign-request --endpoint-url http://localhost:9000 s3 cp file.txt s3://default/

# read the same data through a mounted file system
./bin/grainfs nfs export add default --endpoint "$DATA_DIR/admin.sock"
sudo mkdir -p /mnt/grainfs
sudo mount -t nfs4 -o nolock,nfsvers=4.0 localhost:/default /mnt/grainfs
ls /mnt/grainfs # file.txt
§01 — Surfaces S3, NFS/9P, NBD, and Iceberg clients keep the contract they expect. Operators still manage one engine.

Same data. Four ways in.

S3-compatible HTTP APIaws · mc · boto3
object
NFSv4 + 9P2000.Lmount -t nfs4 · 9p
file
single binary
GrainFS
↳ raft
↳ erasure
↳ DEK/KEK
Linux NBD volumesnbd-client · qemu
block
Iceberg REST CatalogDuckDB · pyiceberg
lake
§02 — Teams Start with one node. Expand to production without downtime. Same admin surface, same recovery docs.

From one node to a production cluster.

02.01
Data / AI platforms

Object storage and catalog access in one system.

Point DuckDB, S3-compatible clients, and lakehouse tooling at the same storage layer instead of operating an object store beside a catalog service.

02.02
On-prem / edge / lab

One small cluster near the workload.

Serve object, file, and block access in labs, edge sites, GPU racks, and private networks without bringing in a full storage platform.

02.03
Developer infrastructure

Protocol coverage for CI and product tests.

Exercise S3, NFS/9P, NBD, and Iceberg clients with one server instead of maintaining a fixture for each protocol.

§03 — Architecture A single node can stay simple. A cluster still needs agreement, placement, encryption, and recovery.

What makes the cluster production-grade.

01 Consensus

Raft keeps metadata consistent.

Cluster membership, IAM state, protocol credentials, placement metadata, and admin changes commit through the Raft-backed metadata layer.

02 Durability

Erasure coding follows topology.

The cluster derives its erasure-coding profile from topology and stops writes when it cannot meet the required durability target.

03 Encryption

At-rest encryption covers data and secrets.

Object data, metadata snapshots, WAL records, service-account keys, and protocol secrets use the generation-aware DEK/KEK envelope.

§04 — Operator safety Recent releases focused on the points where storage systems hurt: cutovers, stale credentials, format markers.

Safety shows up in failure paths.

04.01
Zero-CA

Cutover removes shared bootstrap keys.

grainfs cluster complete-cutover moves voters to per-node transport identities and drops the legacy shared cluster key only after readiness checks pass.

04.02
Credentials

Stale credentials fail before attach.

S3, Iceberg, NBD, NFS, and 9P attach paths reject stale, revoked, expired, or mismatched credentials before clients connect.

04.03
At rest

Format changes fail closed.

Nodes refuse to open data directories with mismatched format markers. They fail closed rather than mix storage formats without a flag.

04.04
Real clients

Real clients run every release.

MinIO mc covers bucket-scoped S3 credentials. DuckDB covers the Iceberg REST Catalog path on single-node GrainFS.

NoteThe public compatibility tables mark a feature supported only when e2e, conformance, or real-client integration tests cover it. Unit tests alone do not qualify.

§05 — Adoption Run the Apache 2.0 engine from GitHub. Add support when GrainFS sits on the path of production workloads.

Adopt the engine first. Add support when it matters.

Tier 01 · Community
Apache 2.0

Start from GitHub

  • Single-node and small-cluster usage
  • Object, file, block, and Iceberg interfaces
  • CLI, docs, runbooks, and benchmark artifacts
Start on GitHub
Tier 03 · Enterprise
For regulated

Run in controlled environments

  • Air-gapped install and long-term support builds
  • SSO/RBAC, audit workflows, recovery assistance
  • Architecture review for on-prem, edge, and lab clusters
Contact sales
§06 — Benchmarks Every benchmark logs its setup: object size, concurrency, signing, cache, and comparison target.

Local numbers, methodology attached.

Metric GrainFS MinIO Ratio Trend
S3 PUT throughput
64 KiB · concurrency 32 · signed
548.30MiB/s
175.14MiB/s
3.13×
S3 GET throughput
warm reads · same dataset · Apple M3
1,849.34MiB/s
457.81MiB/s
4.04×
Errors observed
across both warp passes
0err
● PASS
Methodology

warp 1.0.6 · same-host single node · DATA_DIR on local SSD · request signing enabled · MinIO baseline measured with identical warp invocation.

Disclosure

Local runs on Apple M3, 16 GB. Treat them as engine signal. Production sizing needs your own hardware. Raw output sits in the repo benchmark artifacts.

§07 · grainfs.gritive.com

Try GrainFS locally in minutes.

Run a local node, prove the same-data path, then bring GrainFS into production with review, upgrades, and recovery planning.