stabled process that serves both the Ethereum JSON-RPC and the CometBFT RPC, so it’s modeled as one component rather than an execution/consensus split.
Stable runs only on a bare-metal executor (Agent) — it isn’t offered on the Kubernetes (Operator) backend. To provision a host, see Provision on bare-metal.
To deploy, open Deploy Node, pick Stable, then choose a network and a node type.
Networks and resources
Both networks are offered in the deploy wizard.
Node types
- Pruned — keeps recent state and bootstraps fast from a published snapshot. Best for RPC serving.
- Archive — keeps all historical state, and bootstraps from its own published archive snapshot rather than the pruned one.
Ports
Ports are managed for you and aren’t user-overridable.
Snapshot bootstrap
Both node types seed from a published snapshot on first deploy to cut sync time, each from the one that matches it — a Pruned node from the pruned snapshot, an Archive node from the full archive snapshot. Both are published per network.Configuration
Stable runs with a managed configuration —config.toml, app.toml, and the pinned genesis are rendered for you; there are no client config overrides at deploy time.
Metrics
Block height, peers, and sync progress are surfaced in the node view — see Node monitoring.What you can build
- Public RPC node — accept the defaults (Pruned) and expose
:8545(HTTP) /:8546(WS) behind your own proxy. - Archive node — choose Archive for full historical state (heavier disk).