Skip to main content
This guide covers the details of running a Sei node, including configuration management, maintenance procedures, and best practices for stable, high-performance operation.

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 on top of the defaults. For the full unmodified app.toml, config.toml, and client.toml files from the latest tagged seid release, see Default configurations at the bottom of this section.

Essential configuration parameters

Network settings (config.toml)

Application settings (app.toml)

pebbledb (also called pebble) is the only supported receipt-store backend. The setting rs-backend = "parquet" (or RECEIPT_BACKEND=parquet) is rejected with the error unsupported receipt-store backend "parquet"; supported: pebbledb. In the localnode and rpcnode configuration scripts, if you enable Giga Storage (GIGA_STORAGE=true) and RECEIPT_BACKEND is not set, the receipt backend defaults to pebble. The former receipt-store.tx-index-backend config field has been removed.

Default configurations

This section shows the full unmodified app.toml, config.toml, and client.toml files that seid init produces with the latest tagged seid release. Use them as the canonical reference for every available setting and its default value.
Do not use RocksDB for new or resynced nodes. The generated app.toml below mirrors the latest tagged release and may still list RocksDB as a state-store option. 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, and other settings.
The generated comments above do not describe two behaviors. First, min-retain-blocks also controls receipt store retention. The receipt store’s KeepRecent is derived from min-retain-blocks, and 0 means keep everything. Second, when evm-ss-db-directory is unset, nodes with an existing <home>/data/evm_ss directory keep using that legacy path. New nodes default to <home>/data/state_store/evm/{backend}.

Database management

Architecture

Sei uses SeiDB to store chain data. SeiDB is a two-layer design that replaces the legacy single-database IAVL store with separate tiers for hot and historical data:
  1. State Commit (SC): the active chain state. It is 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 also be routed through FlatKV, an EVM-tuned PebbleDB store with per-type sub-databases (account, code, storage, legacy, metadata). The sc-write-mode setting controls the routing, and its default is memiavl_only. FlatKV is used only when sc-write-mode is set to a migration mode or flatkv_only.
  2. State Store (SS): versioned raw key-value pairs for historical queries. It is 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 has been fully removed, and every node runs on SeiDB. If you set sc-enable = false, the node panics at startup with SeiDB state-commit (SC) must be enabled; IAVL backend has been fully deprecated.

SeiDB configuration

The full set of settings is in the auto-generated Default configurations above. The block below covers the values that most node operators tune in practice.
Small (more frequent) pruning intervals may collide with snapshot creation. Intervals that are too large (less frequent) make pruning take longer overall. This can cause missed blocks and excessive resync time.

PebbleDB version encoding

New 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. To adopt descending encoding, rebuild the state store through state sync with a current seid release. A filesystem snapshot preserves the source store’s encoding, so confirm its encoding with the snapshot provider.

Move off RocksDB

Check the Sei release notes before every upgrade. RocksDB support for the SeiDB state store will be removed. No target release has been published.
RocksDB and PebbleDB use different on-disk formats. Changing ss-backend = "rocksdb" to ss-backend = "pebbledb" on the same data does not convert the store. Rebuild the state store instead. For a non-archive node:
  1. Stop seid. Then 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. 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 that the startup log reports "SeiDB SS is enabled" with the PebbleDB backend. Before you delete the old RocksDB backup, test the RPC methods that your node serves.
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 get 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. Before you cut over, benchmark the replacement under your trace workload.

Giga Storage and Giga Executor

These are two separate features that ship in newer seid releases. Giga Storage repartitions SeiDB so that EVM state lives in its own databases at both the SC and SS layers. This frees non-EVM modules from EVM write amplification.
For step-by-step instructions, see the Giga SS Store Migration Guide. The guide includes the full state sync flow, startup verification, safety checks, and rollback. The snippet below shows only the resulting app.toml shape.
The SC layer has its own, separate migration path (sc-write-mode and the FlatKV drain). It has different coordination requirements and its own warnings. Do not combine the two flips in one restart. Before you change sc-write-mode, see the FlatKV EVM SC migration flow. Enabling Giga Storage requires a fresh state sync. If you flip evm-ss-split on a node with existing data, the node fails the startup safety checks. This is 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. The procedure is currently supported on RPC nodes only. Validators and archive nodes are not yet covered. Giga Executor is independent of Giga Storage. From the v6.6 release line, newly generated configurations and configurations that omit these fields default to the Giga execution path with OCC enabled. To opt out, set both fields explicitly to false. Before you change either setting, follow the release-specific operator instructions:

Database maintenance

The database is typically stable and can be left alone. However, it may need some attention:
After you run the wipe command above, resync the node from a snapshot or through state sync. Until then, the node cannot serve traffic. The command deletes the entire local database (everything except priv_validator_state.json) and the wasm folder. It does not compact data in place.

Service management

Systemd commands

Log management

To stop logs from using too much disk space, enable log rotation:

Update procedures

Upgrade with the same method that you used for the original install. The make install command writes seid to $(go env GOPATH)/bin, but the prebuilt-binary flow installs to /usr/local/bin. If you mix the two, separate binaries stay on your PATH, and your service unit may keep running the old version. The which -a seid command lists every copy.

Minor updates

For minor updates that do not break consensus:

Major updates

For major upgrades that introduce state-breaking changes:
  1. Wait for the designated upgrade block height. You can find it in the upgrade proposal under ‘plan’.
  2. The node halts automatically.
  3. Update or replace the binary.
  4. Restart the node.
Download the release archive (or build the new binary) before the halt height. The swap then takes only seconds at upgrade time.

Performance optimization

The results of performance optimizations can vary with your system’s hardware, workload, and network conditions. Before you make any changes, research them and test them in a controlled environment. Make sure that they fit your specific configuration and requirements. Always back up important data before you make changes.

Memory management (sysctl tuning)

Tuning 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 improve packet processing efficiency and throughput, particularly for nodes that handle many peers and high transaction volume.

Storage optimization

Tuning storage settings can significantly reduce write latency and improve database performance, especially for nodes that use NVMe SSDs.

Backup and recovery

Regular backups

Automate backups to avoid data loss:

Recovery procedure

If data is corrupted or accidentally deleted, restore it from a backup:

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 detailed system and configuration guidelines, see the Advanced Configuration and Monitoring Guide.