Skip to main content
This guide covers the detailed operational aspects of running a Sei node, including configuration management, maintenance procedures, and best practices for stable and performant operations.

Configuration Management

Directory Structure

The Sei node configuration is stored in $HOME/.sei/config/:
The state-store databases live outside the config directory:
  • Cosmos SS uses $HOME/.sei/data/{backend} in the legacy layout and $HOME/.sei/data/state_store/cosmos/{backend} in the current layout.
  • EVM SS uses $HOME/.sei/data/evm_ss in the legacy layout and $HOME/.sei/data/state_store/evm/{backend} in the current layout.
  • Non-empty ss-db-directory and evm-ss-db-directory settings override those locations.
The snippets below are opinionated tuning recommendations layered on top of the defaults. For the full unmodified app.toml, config.toml, and client.toml shipped by the latest tagged seid release, jump to Default Configurations at the bottom of this section.

Essential Configuration Parameters

Network Settings (config.toml)

Application Settings (app.toml)

Default Configurations

The full unmodified app.toml, config.toml, and client.toml produced by seid init against the latest tagged seid release. Use these as the canonical reference for every available knob and its default value.
The generated app.toml below mirrors the latest tagged release and may still list RocksDB as a state-store option. Do not use RocksDB for new or resynced nodes. RocksDB support for the SeiDB state store will be removed. No target release has been published.
Application-layer configuration: gas, API, gRPC, pruning, SeiDB, EVM, etc.

Database Management

Architecture

Sei stores chain data through SeiDB, a two-layer design that replaces the legacy single-database IAVL store with separate hot- and historical-data tiers:
  1. State Commit (SC) — the active chain state used for transaction execution and to compute the per-block app hash. Cosmos modules sit on a memory-mapped Merkle tree (memiavl) ported from Cronos. EVM state can additionally be routed through FlatKV, an EVM-tuned PebbleDB store with per-type sub-databases (account, code, storage, legacy, metadata). Routing is controlled by sc-write-mode / sc-read-mode and defaults to memiavl-only — FlatKV is only opened when one of those modes is set to a non-default value.
  2. State Store (SS) — versioned raw key/value pairs used for historical queries. Required for any node that serves RPC. The default backend is PebbleDB. Do not use RocksDB for new nodes. If you already use RocksDB, follow Move off RocksDB before support is removed.
The legacy IAVL backend is still selectable via sc-enable = false but is deprecated and slated for removal — new deployments and existing nodes should run on SeiDB.

SeiDB Configuration

The full set of knobs is in the auto-generated Default Configurations above. The block below covers the values most node operators tune in practice.
Setting small (more frequent) pruning intervals may collide with snapshot creation. Too-large (less frequent) intervals mean pruning takes longer overall, which can cause missed blocks and excessive resync time.

PebbleDB version encoding

Fresh PebbleDB state stores use descending-version MVCC encoding. Sei includes the version in each key and sorts newer versions first. This lets latest-version reads reach the newest visible value without scanning older versions. The store records this format with the s/_mvcc_descending sentinel key, which seid detects automatically when it opens the database. PebbleDB state stores created by older builds use ascending-version encoding. seid detects these stores and opens them in compatibility mode without an error. They remain on the slower ascending read path. Rebuild the state store through state sync with a current seid release to adopt descending encoding. A filesystem snapshot preserves the source store’s encoding, so confirm its encoding with the snapshot provider.

Move off RocksDB

RocksDB support for the SeiDB state store will be removed. No target release has been published. Check the Sei release notes before every upgrade.
RocksDB and PebbleDB use different on-disk formats. Changing ss-backend = "rocksdb" to ss-backend = "pebbledb" against the same data does not convert the store. Rebuild the state store instead. For a non-archive node:
  1. Stop seid and back up the validator key, validator state, node key, configuration, and genesis file that you need to preserve.
  2. Check ss-db-directory and evm-ss-db-directory in app.toml. An empty value uses a path under $HOME/.sei/data. If either setting points elsewhere, move the old RocksDB data out of the active path and keep it with the backup. Clearing $HOME/.sei/data does not clear a custom directory.
  3. Set ss-backend = "pebbledb", then rebuild through state sync or a provider-confirmed PebbleDB snapshot.
  4. Confirm the startup log reports "SeiDB SS is enabled" with the PebbleDB backend. Test the RPC methods your node serves before you delete the old RocksDB backup.
Do not use state sync or a pruned snapshot to migrate an archive node. Both start from a recent height and discard the earlier state-store versions that an archive node must retain.
There is no documented in-place migration for a RocksDB archive node. Build a separate replacement from a trusted full-history PebbleDB source. Keep the RocksDB node on a compatible seid release until the replacement has caught up and you have tested historical queries at old heights. If you cannot obtain a full-history PebbleDB source, do not wipe the existing archive data. Contact the Sei Tech Chat before you upgrade. PebbleDB can be slower for iteration-heavy historical queries, including debug_trace* requests. Descending-version encoding improves recent reads, but it does not remove the cost of long-history iteration. Benchmark the replacement under your trace workload before you cut over.

Giga Storage and Giga Executor

These are two separate opt-in features that ship in newer seid releases. Both default to off; only enable them deliberately and after following the relevant migration guide. Giga Storage repartitions SeiDB so EVM state lives in its own databases at both the SC and SS layers, freeing non-EVM modules from EVM write amplification.
For step-by-step instructions — including the full state-sync flow, startup verification, safety checks, and rollback — see the Giga SS Store Migration Guide. The snippet below is just the resulting app.toml shape.
Enabling Giga Storage requires a fresh state sync — flipping the EVM SS modes on a node with existing data fails the startup safety checks because the new EVM SS DB starts empty while Cosmos SS already has history. The full procedure is in the Giga SS Store Migration Guide and is currently supported on RPC nodes only; validators and archive nodes are not yet covered. Giga Executor is independent of Giga Storage. It swaps the EVM interpreter from go-ethereum’s geth to an evmone-based executor for higher throughput, with optional OCC parallelism on top:

Database Maintenance

The database is typically stable and can be left alone, although some attention may be required:
The wipe command above deletes the entire local database (everything except priv_validator_state.json) and the wasm folder. It does not compact data in place — after running it, the node must be re-synced from a snapshot or via state sync before it can serve traffic again.

Service Management

Systemd Commands

Log Management

Prevent logs from consuming excessive disk space by enabling rotation:

Update Procedures

Upgrade with the same method you originally installed with: make install writes seid to $(go env GOPATH)/bin, while the prebuilt-binary flow installs to /usr/local/bin. Mixing the two leaves separate binaries on your PATH, and your service unit may keep running the old version — which -a seid lists every copy.

Minor Updates

For minor updates that are non-consensus-breaking:

Major Updates

For major upgrades that introduce state-breaking changes:
  1. Wait for the designated upgrade block height [this can be seen in the upgrade proposal under ‘plan’]
  2. The node will halt automatically.
  3. Update/replace the binary
  4. Restart the node.
Download the release archive (or build the new binary) ahead of the halt-height so the swap takes seconds at upgrade time.

Performance Optimization

Performance optimizations can yield different results depending on your system’s hardware, workload, and network conditions. Before implementing any changes, research and test them in a controlled environment to ensure they align with your specific configuration and requirements. Always back up important data before making modifications.

Memory Management (sysctl tuning)

Optimizing memory management settings can help improve performance and stability, particularly for high-load nodes. These settings control swap usage and the handling of dirty (unwritten) pages in RAM.

Network Stack Optimization

Tuning the network stack can enhance packet processing efficiency and throughput, particularly for nodes handling a large number of peers and high transaction volume.

Storage Optimization

Optimizing storage settings can significantly reduce write latency and improve database performance, especially for nodes using NVMe SSDs.

Backup and Recovery

Regular Backups

Automate backups to avoid data loss:

Recovery Procedure

Restoring from backup in case of corruption or accidental deletion:

Security Considerations

  • Use firewalls and rate-limiting to prevent attacks
  • Keep your system and node software updated
  • Secure SSH access with key-based authentication
  • Protect validator keys with offline storage or hardware security modules (HSMs)
For more in-depth system and configuration guidelines, refer to the Advanced Configuration and Monitoring Guide.