ADAMANT IPFS Node v0.1.0

This is the first tagged release of ADAMANT IPFS Node, and the first published container image. It is a self-hosted IPFS storage node for application file delivery, with bounded disk usage, deterministic replication, repair, health checkpoints, and a REST API. It is a standalone Node.js and Helia service, not a wrapper around Kubo.

Run it

docker volume create ipfs-node-data

docker run -d \
  --name ipfs-node \
  --restart unless-stopped \
  --stop-timeout 20 \
  -v ipfs-node-data:/data \
  -v "$PWD/config.json5:/app/config.json5:ro" \
  -p 127.0.0.1:4000:4000 \
  -p 4001:4001 \
  ghcr.io/adamant-im/ipfs-node:0.1.0

The image ships no configuration; mount one at /app/config.json5. HOME is /data, so a single /data volume holds the blockstore, datastore, libp2p peer identity, pin set, lifecycle registry, repair cursor, and health checkpoint. docker/config.example.json5 in the repository is a standalone starting point that joins no network. Built for linux/amd64 and linux/arm64, running as an unprivileged user, with an SBOM and a provenance attestation attached.

What is in it

The node provides REST upload of multipart files and content-addressed download by CID. It maintains a controlled peer mesh over TCP with Noise and Yamux, registering only identify and ping protocols. Storage lifecycle is bounded through disk reserve, aggregate request limits, temporary uploads with a TTL, and watermark-driven garbage collection. Placement is deterministic by rendezvous hashing, with copy counts that shrink as a file ages. Cross-node replication and a resumable repair cycle operate over a libp2p protocol authenticated by the handshake. Network-aware health checkpoints carry a monotonic height and an explicit membership epoch. Per-endpoint rate limits and admission control apply to concurrent uploads and downloads.

Boundaries

There is no DHT, no IPNS, no public gateway, and no Kubo API. Content stored here is not announced to the public IPFS network, and content that exists only on the public network cannot be fetched through this node. A controlled peer topology reduces public exposure of content-routing metadata, but it does not by itself make a deployment private, anonymous, trustless, or censorship-proof. Upload and download are unauthenticated by design; the only credential is one administrative key. Uploader-signed deletion (#27), peer discovery (#28), traffic accounting (#29), an absolute data directory (#30), and public-network interoperability (#31) are open work.