hl-visor process as a non-validating node. It exposes one HTTP port that serves two APIs — the Ethereum-compatible HyperEVM JSON-RPC at /evm and the HyperLiquid info API at /info. It joins the network over gossip from published root peers — there’s no snapshot bootstrap.
HyperLiquid runs only on a bare-metal executor (Agent) — it is not available on the Kubernetes (Operator) backend. An Agent hosts one HyperLiquid node. To provision a host, see Provision on bare-metal.
To deploy, open Deploy Node, pick HyperLiquid, then choose a network. The hl-visor binary is x86_64-only and its signature is GPG-verified on download.
Networks and resources
Defaults are pre-filled in the deploy wizard; lower them with caution.
Node type
Full, non-validating only — the node serves RPC and follows the chain, but takes no part in consensus.Ports
Ports are managed for you and aren’t user-overridable.
RPC endpoints
The node serves both APIs on the same HTTP port (3001), split by path:
The node’s RPC exposure panel shows a single Direct endpoint on
:3001 — append /evm or /info to reach the API you want (for example, http://<host>:3001/evm).
Configuration
HyperLiquid runs with a managed, network-pinned configuration — there are no client config overrides to set when you deploy. Novacula writes the visor config and the mainnet peer set for you.Metrics
HyperLiquid exposes no direct sync-progress signal, so Novacula judges sync from head freshness: it reads the latest block over the HyperEVM RPC (eth_getBlockByNumber) each cycle. While the head is stale but still advancing it reports Syncing; once the head stays fresh it flips to Running. Block height is surfaced in the node view — see Node monitoring.
What you can build
- Public RPC node — accept the defaults and expose
:3001(HTTP) behind your own proxy; route/evmfor the EVM JSON-RPC and/infofor the info API.