Pepper v0.2.0 - Developer Preview

Pepper 0.2.0 — Developer Preview

Release date: 2026-07-17
Git tag: v0.2.0
GitHub release: prerelease

Pepper 0.2.0 adds a transactional metadata and publication layer to the immutable storage and data-local compute foundation introduced in 0.1.0. This remains a developer-preview release for evaluation and controlled private-cluster deployments.

Highlights

• Transactional namespaces with snapshot isolation, immutable history, named snapshots, bounded diffs, rollback, retention, and conditional/idempotent writes.
• Linearizable key-value operations and atomic transactions backed by exact three-replica OpenRaft namespace groups.
• Versioned bucket objects and immutable snapshot-based filesystem trees with native HTTP and CLI surfaces.
• Durability-gated publication, distributed protection reconciliation, checkpoint recovery, replica replacement, backup verification, and identity fencing.
• An opt-in S3-compatible gateway with AWS Signature Version 4, object and bucket operations, durable multipart uploads, checksums, copies, range reads, multi-object deletion, browser POST uploads, and basic bucket controls.
• Expanded deterministic process and Docker system tests, fault injection, linearizability checking, a five-hour hosted soak, optional WAN/KVM diagnostics, and an exact-commit release qualification gate.

The repository changelog contains the complete implementation summary for this release.

S3 compatibility

The S3 gateway supports path-style requests and virtual-hosted names when deployment DNS and TLS provide the required routing. It authenticates SigV4 headers, presigned URLs, signed browser POST policies, and AWS streaming payloads. Supported operations include:

• bucket create, list, head, empty delete, tagging, CORS, and incomplete-multipart lifecycle configuration;
• object put, get, head, delete, conditional requests, one byte range, copy and ranged part copy, and deletion of up to 1,000 objects;
• ListObjectsV2 with root-bound continuation tokens, prefixes, delimiters, and start-after;
• multipart create, upload or replace part, list parts/uploads, complete, abort, and automatic abort of expired incomplete uploads.

Pepper ETags are opaque content CIDs, not MD5 digests. Object version enumeration, S3 bucket-versioning configuration, legacy ListObjects v1, multi-range responses, ACL/IAM/STS, anonymous access, S3-managed encryption claims, Object Lock, bucket policies, notifications, replication, websites, storage classes other than STANDARD, and most lifecycle actions are not supported. ListMultipartUploads does not group by delimiter. Unsupported semantics fail explicitly rather than being silently ignored.

See S3-compatible API layer for the exact operation, authentication, consistency, error, configuration, and limitation contract.

Compatibility and upgrades

• Existing 0.1.0 blocks, objects, directories, pins, repair state, and compute interfaces remain supported. Existing object and directory CIDs can be referenced by namespaces without rewriting their payload data.
• Agent metadata migration is forward-only and runs when an older database is opened. Stop or quiesce the node and take a verified metadata backup before upgrading. Do not attempt to open migrated metadata with Pepper 0.1.0.
• Namespace groups require exactly three replicas. Losing quorum prevents linearizable metadata progress until quorum is restored or the documented explicit recovery procedure is used.
• The S3 gateway is disabled by default. It requires a protected secret file and remains subject to Pepper's loopback HTTP deployment boundary.

Review the namespace operator guide, recovery runbook, and consistency and durability guarantees before upgrading a persistent cluster.

Release scope and known limits

• Pepper is designed for protected private clusters. This release does not add tenant isolation, a complete IAM model, public-federation abuse resistance, Byzantine durability, confidential compute, or attestation.
• HTTP is loopback-only by default, and SigV4 does not encrypt traffic. Remote S3 access needs a private network or authenticated TLS gateway.
• Firecracker compute requires a Linux KVM host, Firecracker, a configured guest kernel, an allowlisted CID-backed root filesystem, and the Pepper guest agent.
• Real WAN and Firecracker/KVM scenarios are optional manual diagnostics in 0.2.0; they are not release gates because Pepper does not require self-hosted GitHub Actions runners.
• Metadata backup requires a stopped or quiescent agent. Namespace backup and restore use signed, identity-bound manifests and should be exercised before an incident.
• EC reconstruction and S3 range responses use bounded buffering. Operators must configure limits appropriate to their hosts.
• Concurrent bucket creation during a partition does not provide a globally serialized name claim. Discovery detects conflicting durable markers but does not merge them.

Release qualification and publication

The release tag must identify the exact commit that passed Pepper's release gate. Before publishing v0.2.0:

1. Run the smoke, nightly functional, chaos, and five-hour GitHub-hosted soak workflows against the final candidate commit.
2. Run release-qualification with that commit and the four successful workflow run IDs.
3. Confirm the protected release environment approved a successful qualification report and that no source run used a different commit.
4. Create the annotated tag v0.2.0 on the qualified commit.
5. Create a GitHub prerelease titled Pepper v0.2.0 - Developer Preview from that tag and use this document as the release body.

The release has no separately built binary artifacts; GitHub provides source archives for the tag.