MinIO S3 API on NAS-Backed Storage

Context

ADR-0205 sets an AWS-mirrors-local principle for joelclaw infrastructure. The system needs local object storage that behaves like AWS S3 so agents and pipelines can use the same SDK calls locally and in cloud environments.

The NAS “three-body” already provides large persistent capacity (64TB RAID5 + 1.9TB NVMe) and exports /volume1/joelclaw over NFS. Running MinIO in server mode with an NFS-mounted data path gives a local S3-compatible endpoint without changing application code.

Decision

Deploy MinIO as a single-replica StatefulSet in the joelclaw Kubernetes namespace, backed by an NFS mount at /volume1/joelclaw/s3 on three-body.

• S3 API: port 9000
• MinIO Console: port 9001
• Access pattern: ClusterIP service + NodePort service for host access

Use MinIO as the local implementation of the S3 API contract. All S3 SDK operations must work the same against local MinIO and AWS S3.

Use Cases

• Agent artifacts
• Hot image build outputs
• Pipeline results
• Video pipeline outputs
• Discovery captures
• Vault backups

AWS Mapping

• Local: MinIO
• Cloud: AWS S3
• Interface: same S3 API and SDKs

Consequences

Positive

• Provides local S3-compatible object storage with no app-level API divergence.
• Uses existing NAS capacity for high-volume artifact and media storage.
• Keeps local execution portable to AWS S3 later.

Negative

• Adds MinIO as another operational service to run and monitor.
• NFS-backed performance may be suboptimal for very small-object-heavy workloads.