Skip to main content
A HyperLiquid node runs a single 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. The RAM default is 64 GiB — enough for a healthy hl-visor node; raise it in the wizard if your workload needs more. The deploy wizard currently offers mainnet only — testnet is hidden from new deployments in this release.

​
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 endpoint on :3001 — append /evm or /info to reach the API you want (for example, http://<host>:3001/evm).
hl-visor takes no bind address, so it always listens on every interface. The Agent therefore keeps 3001 closed on the host firewall unless that node’s RPC exposure is set to Direct — with any other exposure the port is reachable over loopback only, which is what the pool gateway and the platform’s own probes use. Set Direct to open it to callers — restricting who may reach it is then yours to do at the host firewall. The two gossip ports stay open either way; the node needs them to reach the network.

​
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 — set the node’s RPC exposure to Direct so :3001 is opened, and put your own proxy in front; route /evm for the EVM JSON-RPC and /info for the info API.

​
Where to next