Skip to main content
Bootstrap a Celestia celestia mainnet node in minutes instead of a multi-day full sync.

​
What’s inside

  • data/ folder from a live celestia-appd v9.0.6 mainnet node running on PebbleDB with aggressive pruning (custom / keep-recent=100 / interval=19, min-retain-blocks=3000, indexer=null).
  • snapshots/ sub-dir included so your node can immediately serve state-sync to peers.
Download: snapshots.unitynodes.com/celestia-mainnet/latest.tar.lz4 - refreshed every 4 hours. Full archive listing: snapshots.unitynodes.com/celestia-mainnet/ Also available: genesis.json · addrbook.json
This is a pruned snapshot. It is meant for validators, full nodes and RPC endpoints that only need recent state. It cannot serve historical queries - for that you need an archive node.

​
Restore

Each step runs only if the previous one succeeded, so a failed or cut download never restarts celestia-appd on a partial data/. Your signing state then stays in ~/.celestia-app/priv_validator_state.json.backup: fix the cause and run the command again starting from the rm -rf line.
Do not skip the priv_validator_state.json backup step. That file records the last height and round your validator signed. Restoring somebody else’s signing state - or an older copy of your own - is the classic way to double-sign and get slashed.

​
Verify (optional)

The .sha256 file is fetched first: it names the dated archive it belongs to, so the file you download is always the one the checksum is for, even if a new snapshot is published during a long download. The last line should read <archive name>: OK.

​
FAQ

Every 4 hours. The last 2 snapshots are kept online.
pebbledb - Celestia’s default since v9.
Yes. The tarball contains only data/. There is no config/ directory in it, so no priv_validator_key.json, no node_key.json and no keyring - your identity files are never overwritten by a restore. data/priv_validator_state.json is deliberately excluded too.
Yes. After restore, your node can also serve state-sync to downstream peers (snapshot-interval=1500, snapshot-keep-recent=2).
Yes, briefly. The archive is a cold tar taken with celestia-appd stopped, so the database is never copied mid-write. Downtime is around 10-15 seconds per cycle.