Grow the cluster, watch it migrate live.
Peanut is the resilience and scale layer for Walter: it routes uploads and reads to the right shard, watches every node's health, and runs rebalances without downtime.
A single Walter instance is already a complete file store, but it's also a single point of failure and a hard ceiling on capacity. Scaling that by hand, deciding which server holds which shard, noticing when one goes down, moving data around without breaking clients mid-migration, is exactly the kind of operational work nobody wants to do under pressure. Peanut is the piece that does it: a small, highly-available brain in front of the cluster that an operator, or an automated governance layer acting on their behalf, can drive through a handful of deliberate actions.
Every server, its shard, its role, and whether it's up, at a glance.
Growing the cluster is a real workflow, not a switch. Pick a new target shard count and start a rebalance, migrate the data over in controlled batches, then cut over once migration is complete. The riskier path, cutting over anyway with migration still incomplete, is there for the rare case that calls for it, but it sits behind its own explicit warning and a checkbox acknowledging the risk, and orphan cleanup afterward is its own deliberate step rather than something invisible.
A rebalance you drive in steps: migrate, cut over, sweep, not one switch.
Key compliance is enforced, not just propagated. Publisher API keys are managed from one place, created, revoked, and re-pushed to every master at once, and a master that hasn't yet caught up on the latest key state is excluded from taking uploads until it does. A revoked key doesn't work its way out of the cluster eventually; there's no window where a stale node can still accept a write with a key that's already been pulled. A reconciliation sweep runs on demand too, copying any file missing from a server to the rest of its cluster.
Compliance checked per master, not assumed once a key is pushed.
Underneath all of it is one rule: exactly one Peanut instance is ever active, the standby is a pure hot spare sharing a floating address with it. Every health check and routing decision has a single, unambiguous source of truth, so there's never a "whose opinion wins" problem to resolve. One failed reach is enough to mark a node down, one success is enough to mark it back up. No quorum, no debounce window to tune, and no distributed consensus protocol standing in for what a single decision-maker settles by construction.
What it does
- One active instance at a time, with a pure hot spare, so there's never a conflicting source of truth
- A single failed health check marks a node down for routing; a single success brings it back
- Rebalancing as a real workflow: migrate in batches, cut over deliberately, sweep orphans after
- An on-demand reconciliation sweep, copying any file missing from a server to the rest of its cluster
- Publisher key management from one place: create, revoke, and re-push the full roster to every master
- Revoked keys enforced everywhere immediately: a master not yet caught up is excluded from uploads until it is
- Bootstraps onto an existing Walter with no forced re-keying, it pulls current key state once and takes over from there