Sprune

Node operators on Cosmos chains eventually hit the same wall: the server disk fills up. The standard advice is "prune your node," but the tooling to do that safely was either fragile, underdocumented, or required manual steps that were easy to get wrong. We needed a Go CLI that operators could trust — something with sensible defaults, configurable retention, and enough care about the underlying database structure to not corrupt state.

Sprune targets two separate databases that Cosmos nodes maintain. The Tendermint/CometBFT block database stores block headers and commit data. The Cosmos SDK application database stores state snapshots at each height. Both accumulate indefinitely unless explicitly pruned. Sprune handles both independently, with configurable retention: defaults are 100 Tendermint blocks and 10 application state versions. It operates on the standard Cosmos node directory structure, so it works across any SDK-based chain without chain-specific configuration.

The main risk was database corruption. Tendermint and the app database have separate internal structures — they use LevelDB or RocksDB under the hood with specific key schemas — and you can't just delete arbitrary heights without breaking the state root hash chain. We had to understand the internal key layout well enough to prune safely: which keys could be removed, which had dependencies, and what the minimum safe retention window was to avoid consensus failures on restart.

The result is a reliable pruner that operators can run against a stopped node, configure once, and trust. Open-sourced under Cakra Labs and used across the Cosmos ecosystem by node operators who'd rather reclaim disk space automatically than wait for a storage crisis.