v0.11.0 — one clustered path

Hamster v0.11.0 — one clustered path.

Hamster stops being two data paths and two command namespaces and becomes one product: a node is a one-node cluster, the CLI is flat, S3 serves on every node by default, and the cluster S3 surface is now a strict superset of what the old single-node store offered.

Still early development (v0). Not production ready. On-disk and on-wire formats may change between v0 releases.

⚠️ Breaking changes

This release is a deliberate, pre-1.0 hard break — there are no aliases.

• The CLI is flat. The cluster namespace is gone: hamster cluster <command> no longer works. Every operational command is now top-level — hamster status, hamster drain, hamster encrypt, hamster rotate-ca, and so on. Run hamster -h to see them all (the old help hid most of them under hamster cluster -h).
• hamster serve is now the node command. It replaces hamster cluster run. A node is a one-node cluster, so a single-node deployment is hamster init then hamster serve — the same path that scales to many nodes.
• The standalone single-node serve store is removed. There is no separate non-clustered code path. An existing single-node serve deployment does not convert in place (the on-disk formats differ — they never converted): migrate its data over S3 (e.g. rclone move) to a one-node cluster. That migration carries current object data only.

Highlights

• One flat CLI. All commands are top-level verbs with a single, complete -h help generated from the dispatch table, so help can never drift from what the binary runs.
• S3 on by default. hamster serve serves the S3 API on 127.0.0.1:9000 automatically, requiring credentials (it refuses to boot serving an unauthenticated endpoint). -no-s3 runs a headless storage-only node; -s3 <addr> overrides the address.
• Any node accepts writes. A write that lands on a non-leader is committed, not bounced with 503. The receiving node does the data-plane work locally (placement, erasure coding, shard transfer) and forwards only the small metadata commit to the leader — object bytes never cross the leader hop or the Raft log. Point an S3 client at any node behind any round-robin.
• Full S3 surface on the cluster path. Streaming PUT (bounded memory at any object size), Range-efficient GET (only the covering shards are fetched), server-side CopyObject / UploadPartCopy, and erasure-coded multipart — each part erasure-coded independently and durable on upload, the parts stitched on read. aws s3 cp of a large file now works against a cluster.

Notes

• A one-node deployment now runs Raft (a single voter) and mints its own CA automatically — mTLS on one node is trivial and the configuration burden stays near zero, in exchange for a uniform operational model from one node to many.
• Encryption at rest, object lock / WORM, versioning, key/CA rotation, rolling upgrades, and the metrics endpoint all carry forward unchanged, now on the one path.

Design records: ADR-0036 (one clustered path), ADR-0037 (proposal forwarding), ADR-0038 (erasure-coded multipart and data-path parity).