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
Node types
- Pruned — keeps recent state and bootstraps fast from a published snapshot. Best for RPC serving.
- Archive — keeps all historical state; syncs from genesis (the published snapshot is pruned, so an archive node doesn’t use it).
Ports
Ports are managed for you and aren’t user-overridable.
Snapshot bootstrap
A Pruned node seeds from a published snapshot on first deploy to cut sync time. An Archive node keeps every historical state, so it syncs from genesis instead of using the (pruned) snapshot.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).