Ethereum Full Node: Complete Guide

What is a Ethereum full node?

A Ethereum 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 Ethereum Full Node RPC over HTTPS so applications can read ETH balances, simulate contracts, and submit signed transactions without self-hosting Erigon/Geth and companion services.

Why Ethereum full nodes matter

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

Ethereum in the RpcNode catalog: Ethereum L1.

• Native asset: ETH
• Environments: Mainnet, Sepolia Testnet, Hoodi Testnet
• API family: EVM JSON-RPC
• Listed in the RpcNode network catalog

When to run your own Ethereum node

Self-hosting a Ethereum 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 Ethereum 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 Ethereum before dedicating hardware — start on RpcNode, or self-host with Toolkit in a few clicks

Ethereum full node server requirements

Ethereum full node server requirements for a production RPC host assume a pruned snap-sync execution client plus a consensus client — not an archive node. Minimum specs below match a Geth + Lighthouse style full node; archive multiplies disk by an order of magnitude.

Plan NVMe growth (~10–15 GB/week on mainnet pruned). Separate datadir from the OS disk. Engine API stays on localhost; only whitelist JSON-RPC if you expose it.

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

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

• CPU: 4+ cores for pruned Full Node RPC; 8+ if you run archive or heavy eth_getLogs
• RAM: 16 GB minimum for pruned; 32 GB+ for archive / busy RPC
• Disk: 2+ TB NVMe for pruned mainnet (~1–1.5 TB today); 12+ TB NVMe for archive
• Bandwidth: stable 1 Gbps helps peers and initial sync
• OS: Ubuntu 24.04 LTS (or similar modern Linux) with a dedicated non-root operator user
• Full vs archive: pruned serves tip + recent state; deep historical eth_call needs archive

Install a Ethereum full node in a few clicks

Ethereum is in the free RpcNode Toolkit catalog (mainnet, sepolia, hoodi). 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 Ethereum and an environment, then the node page handles ports, install, snapshot when the chain supports it, sync, logs, and the public RPC endpoint.

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

Self-host Ethereum with Toolkit

How to run a Ethereum full node

How to run a Ethereum full node for non-archive RPC: run Geth (snap, pruned) plus Lighthouse (or another consensus client) with a shared JWT. This is a full node profile — not archive.

Bind JSON-RPC to localhost and put Nginx (or similar) + IP allowlists in front if you must expose eth_*. Keep Engine API on 8551 localhost-only.

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

1. 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.
2. Attach 2+ TB NVMe under a path like `/data/ethereum`. Mount it away from the root filesystem and give ownership to the operator user.
3. Apply OS hygiene: unattended-upgrades or a patch cadence, fail2ban/SSH keys, and raise file-descriptor limits if the client docs require it.
4. Install Geth (Ubuntu PPA `ethereum/ethereum` or official tarball) and Lighthouse from the SigP release assets.
5. Generate a 32-byte hex JWT (e.g. `/etc/ethereum/jwt.hex`) readable by both clients; create datadirs for geth and lighthouse.
6. Start Geth with pruned full-node flags such as `--syncmode snap`, `--gcmode full`, `--history.chain postmerge`, HTTP on `127.0.0.1:8545`, authrpc on `127.0.0.1:8551`, and P2P `30303`. Do not enable archive flags “just in case”.
7. Start Lighthouse beacon_node with mainnet, checkpoint sync, execution endpoint `http://127.0.0.1:8551`, and the same JWT. Open consensus P2P `9000` tcp/udp.
8. Create systemd units for both processes (`Restart=always`), enable them, and confirm they stay up across reboots.
9. Firewall: allow `30303` and `9000` publicly; whitelist only the RPC listener (often Nginx on `8545`).
10. Verify: `eth_syncing` → `false` on `http://127.0.0.1:8545`, and beacon `/eth/v1/node/syncing` shows not syncing.

• Ports: P2P 30303 + 9000 public; RPC 8545 whitelist; Engine 8551 localhost
• Health: eth_syncing false + beacon not syncing before production traffic

Using Ethereum RPC without self-hosting

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

Catalog environments for Ethereum: Mainnet, Sepolia Testnet, Hoodi Testnet. 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.

Ethereum integration checklist

Use this short checklist when wiring Ethereum into production.

• Pick the correct environment (Mainnet, Sepolia Testnet, Hoodi Testnet) — 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 Ethereum server requirements (CPU/RAM/disk) before self-hosting
• Or install with RpcNode Toolkit in a few clicks — free self-hosted panel

Ethereum full node FAQ