Hyperliquid Full Node Guide: Server Requirements & Setup

What is a Hyperliquid full node?

A Hyperliquid full node syncs an execution client (and, where applicable, the L1/L2 stack behind it), verifies blocks, and serves standard Ethereum JSON-RPC: eth_blockNumber, eth_getBalance, eth_call, eth_getLogs, and eth_sendRawTransaction.

RpcNode offers managed Hyperliquid Full Node RPC over HTTPS so applications can read HYPE balances, simulate contracts, and submit signed transactions without self-hosting Erigon/Geth and companion services.

Why Hyperliquid full nodes matter

Every wallet balance, payment confirmation, and contract read ultimately depends on nodes that agree on Hyperliquid state. Public endpoints rate-limit and flake; your product’s reliability tracks the quality of the full nodes behind your RPC URL.

Hyperliquid in the RpcNode catalog: Hyperliquid HyperEVM.

Native asset: HYPE
Environments: Mainnet (HyperEVM), Testnet (HyperEVM)
API family: EVM JSON-RPC
Listed in the RpcNode network catalog

When to run your own Hyperliquid node

Self-hosting a Hyperliquid full node makes sense when you need custom indexing, ultra-low latency next to your app, or compliance constraints that forbid third-party RPC. For most product teams, managed Full Node RPC is faster to ship and cheaper to operate.

Building wallets, payments, or address watchers that need reliable Hyperliquid reads and writes
Avoiding multi-terabyte disks, peer tuning, and 24/7 pager duty for chain upgrades
Preferring HTTPS JSON-RPC with allowlists, keys, and usage metering
Evaluating Hyperliquid before dedicating hardware — start on RpcNode, or self-host with Toolkit in a few clicks

Hyperliquid full node server requirements

Hyperliquid full node server requirements for non-validator RPC are closer to trading infra than a light eth node: 16 vCPU, 128 GB RAM, and about 1 TB SSD headroom.

Run `hl-visor run-non-validator` with eth/info RPC enabled. Avoid `recent-actions` ultra-prune if you care about action history for debugging.

Looking up "Hyperliquid server requirements", "Hyperliquid hardware requirements", or "Hyperliquid minimum specs"? Use the checklist below as the planning baseline for a self-hosted full node.

If you mainly need HTTPS Hyperliquid RPC for wallets or backends, prefer RpcNode managed Full Node RPC instead of sizing and babysitting this hardware yourself.

CPU: 16 vCPU non-validator RPC (32 for validators)
RAM: 128 GB
Disk: 1 TB SSD planned (≈500 GB practical minimum)
Bandwidth: 1 Gbps; gossip 4001–4002 tcp public; HTTP RPC 3001 whitelist only
OS: Ubuntu 24.04 LTS
Role: non-validator — do not run validator keys for an RPC-only host

Install a Hyperliquid full node in a few clicks

Hyperliquid is in the free RpcNode Toolkit catalog (mainnet, testnet). Skip the manual binary hunt: the self-hosted panel walks Add server → Add node → the node page.

On Linux (amd64/arm64) you install the host agent once, register the server, pick Hyperliquid and an environment, then the node page handles ports, install, snapshot when the chain supports it, sync, logs, and the public RPC endpoint.

Install the host agent on the Linux server (curl one-liner from rpcnode.dev).
Add server: paste IP and AGENT_API_TOKEN, Check connection, then add.
Add node: network Hyperliquid → environment (mainnet, testnet) → that server.
Open the node page — install, sync %, logs, restart, client update, fullnode RPC.

Self-host Hyperliquid with Toolkit

How to run a Hyperliquid full node

How to run a Hyperliquid full node for RPC: `hl-visor run-non-validator` with eth/info RPC enabled. Do not run validator mode for an RPC-only server.

If you mainly need HTTPS Hyperliquid RPC for wallets or backends, prefer RpcNode managed Full Node RPC instead of sizing and babysitting this hardware yourself.

Provision Ubuntu 24.04 LTS (or the OS your client documents) on bare metal or a dedicated VM. Create a system user such as `nodeop` — do not run the node as root.
Attach 1 TB SSD (500 GB minimum) for Hyperliquid data. Mount it away from the root filesystem and give ownership to the operator user.
Apply OS hygiene: unattended-upgrades or a patch cadence, fail2ban/SSH keys, and raise file-descriptor limits if the client docs require it.
Install `hl-visor` from the official hyperliquid-dex/node releases and follow current non-validator docs.
Configure `run-non-validator` with `--serve-eth-rpc` / `--serve-info`; keep default `actions` retention (avoid `recent-actions` ultra-prune for full RPC usefulness).
Install the provided systemd unit pattern; run as the operator user.
Open gossip `4001-4002/tcp`; whitelist HTTP RPC `3001` only.
Verify eth/info RPC on localhost `:3001` and confirm the node is near tip.

Role: `run-non-validator` + serve eth/info RPC
Ports: 4001–4002 gossip; 3001 RPC whitelist

Using Hyperliquid RPC without self-hosting

RpcNode exposes managed EVM JSON-RPC for Hyperliquid. Create an endpoint in the cabinet, restrict IPs if needed, and call the same methods your stack already uses.

Catalog environments for Hyperliquid: Mainnet (HyperEVM), Testnet (HyperEVM). Create an endpoint in the RpcNode cabinet for the environment you need, or use this guide to plan a self-hosted deployment.

Typical methods teams start with: eth_blockNumber, eth_getBalance, eth_call, eth_getLogs, eth_sendRawTransaction.

Self-hosting vs managed Full Node RPC

Self-hosting gives maximum control and can reduce per-request cost at huge scale, but you own upgrades, peers, disk growth, and incident response. RpcNode Toolkit cuts the install to a few clicks (agent → Add server → Add node → node page) while you still run the hardware.

Managed RpcNode Full Node RPC trades that ops burden for a stable HTTPS endpoint, usage visibility, and the same method surface your SDK already speaks. If you are comparing providers, also see RpcNode’s comparison page.

Hyperliquid integration checklist

Use this short checklist when wiring Hyperliquid into production.

Pick the correct environment (Mainnet (HyperEVM), Testnet (HyperEVM)) — never mix testnet keys with mainnet funds
Store RPC URLs and keys in secrets management; rotate on staff changes
Add IP allowlisting for server-side backends
Alert on tip lag / getHealth (or equivalent) failures
Load-test eth_getLogs / getProgramAccounts-style heavy calls before launch
Decide full vs archive needs early — RpcNode is Full Node oriented
Confirm Hyperliquid server requirements (CPU/RAM/disk) before self-hosting
Or install with RpcNode Toolkit in a few clicks — free self-hosted panel

Hyperliquid full node FAQ

Can I install a Hyperliquid full node in a few clicks?

Yes. Hyperliquid is in the free RpcNode Toolkit catalog. Install the Linux host agent, Add server, Add node (Hyperliquid → environment → server), then finish install and sync on the node page. See rpcnode.dev/toolkit.

What is a Hyperliquid full node?

A Hyperliquid full node verifies and stores blockchain data for Hyperliquid, then serves queries about blocks, accounts, and transactions. RpcNode runs Full Node RPC so apps can use that data over HTTPS.

Is RpcNode Hyperliquid RPC available now?

Yes — Hyperliquid is available on RpcNode. Create an endpoint for the environment you need (Mainnet (HyperEVM), Testnet (HyperEVM)) and start sending EVM JSON-RPC requests.

Full node vs archive node for Hyperliquid?

A full node serves recent state and standard JSON-RPC. An archive node keeps historical state so old eth_call / eth_getLogs ranges remain answerable. RpcNode positions as Full Node RPC, not archive.

Can I accept HYPE payments on Hyperliquid?

RpcNode also ships crypto payment infrastructure and address watching on supported networks. When Hyperliquid RPC is active for your account, you can combine payments with the same Full Node-backed data plane.

What are the Hyperliquid full node server requirements?

See the “Hyperliquid full node server requirements” section for CPU, RAM, disk, bandwidth, and OS minimum specs. If you only need HTTPS RPC, managed RpcNode Full Node endpoints avoid buying that hardware.