> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sui

> Run a Sui node — networks, resource defaults, and config overrides

A Sui node runs as a single `sui-node` process. Genesis, seed peers, and a formal-snapshot bootstrap are set up for you on first start, so the node restores from a recent snapshot instead of replaying from genesis. Supported networks: `mainnet`, `testnet`.

When you deploy, the wizard offers the versions available for the network you pick — Sui client versions are network-scoped, and more than one may be on offer, newest first. Current coverage: `mainnet-v1.76.1` on `mainnet`; `testnet-v1.76.1` and `testnet-v1.76.0` on `testnet`. A `mainnet` deploy requires `1.76.1` or newer, so older mainnet builds aren't offered. Sui ships no supported update path, so changing version means redeploying — see [Update a node's version](/docs/nodes/upgrade-node).

Indexing is enabled by default — both the REST index store and the gRPC index — so the node can resolve gas coins and **submit transactions** out of the box. These index settings are managed for you (see [Config overrides](#config-overrides)).

## Networks and resources

| Network   | CPU     | RAM     | Disk     |
| --------- | ------- | ------- | -------- |
| `mainnet` | 8 cores | 128 GiB | 4000 GiB |
| `testnet` | 8 cores | 64 GiB  | 2500 GiB |

These defaults are pre-filled in the deploy wizard. They are heavy because Sui state grows fast and pruning is configurable rather than aggressive. Lower with caution. Sui is one of the chains where a fast NVMe-backed [storage class](/recipes/provision-on-kubernetes) matters most (see the performance note below).

## Node types

**Full** only. Sui has no separate archive node type; for archival use cases, retain more history through overrides (see below).

## Config overrides

Config overrides are set when you deploy — see [Edit a running node](/docs/nodes/edit-configuration). Networking, data path, genesis location, and the index settings (`enable-index-processing` and `rpc.enable-indexing`) are managed for you and rejected if you try to set them — they're what keep transaction submission working. Seed peers are set on first start but remain overridable.

These common tuning keys are surfaced in the editor with type hints and descriptions:

| Key                                                                   | Type    | Description                              |
| --------------------------------------------------------------------- | ------- | ---------------------------------------- |
| `enable-event-processing`                                             | boolean | Enable event indexing/processing         |
| `authority-store-pruning-config.num-epochs-to-retain`                 | number  | Epochs of history to retain in the store |
| `authority-store-pruning-config.num-epochs-to-retain-for-checkpoints` | number  | Epochs of checkpoints to retain          |
| `authority-store-pruning-config.periodic-compaction-threshold-days`   | number  | Days between RocksDB compactions         |

Other `fullnode.yaml` keys are accepted as-is.

## Metrics

Sui reports progress by **checkpoint** rather than block. The node page surfaces the verified checkpoint (height), the network's highest known checkpoint (tip), peer count, sync progress, and resource usage. Beyond those, Sui nodes report a fuller set of chain metrics:

| Group           | What you get                                                                                                                                     |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Checkpoints** | Current epoch, highest known / last executed / highest synced / highest verified checkpoint, and synced and verified progress as separate series |
| **Throughput**  | Checkpoint execution sync TPS, and the age of the last executed checkpoint at p50, p95, and p99                                                  |
| **Consistency** | Checkpoint errors, remote checkpoint forks, and split-brain checkpoint forks — non-zero fork counters are worth investigating                    |
| **Index store** | RocksDB write activity behind the index: batch commit bytes and count, commit latency, and very-slow batch writes with their duration            |

The index-store series are the ones to watch when a node stalls periodically — they show storage, not CPU, as the bottleneck (see the [performance note](#performance-note)). See [Node monitoring](/docs/nodes/monitoring).

## Common patterns

* **Public RPC node** — accept defaults; expose `:9000` through your own reverse proxy.
* **Long-history node** — raise `num-epochs-to-retain` and `num-epochs-to-retain-for-checkpoints` substantially; expect proportional disk growth.
* **Lean node (events off)** — set `enable-event-processing: false`; the node won't index events but uses materially less disk.

## Performance note

Sui benefits more from fast NVMe than from raw CPU count — the bottleneck is RocksDB. If your storage doesn't deliver consistent low-latency writes (cloud burst-credit volumes, network filesystems), expect periodic stalls regardless of CPU/RAM headroom.