How to Run a Polygon RPC Node: Step-by-Step [With Examples]

A Polygon RPC node gives our applications a private, reliable gateway to the Polygon PoS network. Instead of depending on shared public endpoints that often throttle requests under heavy load, we can take control of the endpoint, the performance, and the uptime ourselves. In this guide, we'll walk through everything needed to set up and run a private Polygon RPC node on a dedicated server.

#What is a Polygon RPC Node?

A Polygon RPC node is a full node that exposes JSON-RPC endpoints over HTTP and WebSocket, allowing our applications to read blockchain data and submit transactions. To do this, it runs two distinct services: Heimdall, a consensus layer built on CometBFT, and Bor, an execution layer that functions as a dedicated RPC node to process transactions.

Unlike a validator node, an RPC node doesn't participate in consensus or require us to stake tokens. Its primary purpose is to serve data quickly and handle high request volumes. This makes it the ideal choice if we're building dApps, running trading bots, or powering analytics dashboards where we need a private, unthrottled connection.

Because Polygon is EVM-compatible, the JSON-RPC methods we'll use are familiar to any Ethereum developer. Standard methods like eth_getBalance, eth_call, and eth_blockNumber work exactly as expected, which means we can migrate existing Ethereum-based tools to our new node with minimal friction.

#Polygon RPC Node vs. Validator Node

It's important to make this distinction before we start our Polygon RPC node setup.

A validator node stakes POL tokens and participates in block production to earn rewards. This requires a more complex sentry node architecture and a constant connection to Ethereum L1. On the other hand, our Polygon RPC node focuses entirely on serving read and write requests. We don't need to worry about staking or block production, which simplifies our maintenance and removes the need for a separate Ethereum RPC connection.

If our goal is simply to power our own backend services with fast, private blockchain access, an RPC node is the way to go.

#Polygon RPC Node Requirements

Before we begin deployment, let's make sure our server meets the necessary Polygon node hardware and software requirements and benchmarks. Using the right specs ensures we don't run into synchronization delays later on.

#Polygon Node Hardware Requirements

Polygon Node Mainnet (Recommended)

• CPU: 16 cores

• RAM: 64 GB

• Storage: 8 TB NVMe SSD (Polygon’s snapshot documentation references 9TB block devices, and keeps the chain growing.)

• Network: 1 Gbit/s symmetric

Polygon Node Testnet (Amoy)

• CPU: 8 cores

• RAM: 16 GB

• Storage: 2 TB NVMe SSD

• Network: 1 Gbit/s

Polygon nodes are incredibly I/O-intensive. Bor maintains a massive state database that requires fast, consistent NVMe speeds. We've found that dedicated bare metal servers generally outperform virtualized cloud instances here because we aren't competing for shared I/O resources, which prevents our node from falling behind the network tip.

#Polygon Node Software Requirements

Running a Polygon node requires meeting specific software requirements to ensure stable performance, reliable synchronization, and network participation, we recommend:

• Ubuntu 22.04 LTS or newer

• SSH access and a sudo user

• build-essential package installed

#Ports

Pro Tip: We should only open ports 8545, 8546, and 1317 if we intend to expose the RPC publicly. For most private setups, we recommend keeping them bound to localhost and using an SSH tunnel or a reverse proxy for better security.

#How to Run a Polygon RPC Node: Step-by-Step

Follow the below steps to successfully run a Polygon RPC node.

#Step 1: Prepare the Server

Let's start by connecting to our server and ensuring all system packages are up to date.

sudo apt-get update && sudo apt-get upgrade \-y
sudo apt-get install build-essential \-y

#Step 2: Configure the Firewall

Before we enable the firewall, we need to allow the required P2P and SSH ports so we don't lock ourselves out or prevent the node from finding peers.

sudo ufw allow 22/tcp
sudo ufw allow 26656/tcp
sudo ufw allow 30303/tcp
sudo ufw allow 30303/udp
sudo ufw enable

#Step 3: Install Heimdall

Heimdall serves as our consensus layer. We'll use the official install script to install a sentry node on the mainnet network. The mainnet flag sets the network, and sentry sets the node type (as opposed to a validator). Make sure to replace <version> with the latest release tag from the official Polygon repository.

curl -L https://raw.githubusercontent.com/0xPolygon/install/heimdall-v2/heimdall-v2.sh | bash -s -- <version> mainnet sentry

We can verify that everything is installed correctly by checking the version:

heimdalld version --long

#Step 4: Configure Heimdall

The install script from Step 3 handles initialization and creates the config directory at /var/lib/heimdall. What we need to do now is download the correct genesis file and configure our seeds.

cd /var/lib/heimdall/config
sudo curl -fsSL https://storage.googleapis.com/mainnet-heimdallv2-genesis/migrated_dump-genesis.json -o genesis.json

We also need to update our "seeds", these are the initial peers our node will talk to so it can discover the rest of the network. The latest mainnet seeds are listed in the official Polygon documentation. Open the configuration file and set the seeds value to the current:

sudo nano /var/lib/heimdall/config/config.toml

#Step 5: Install Bor

With Heimdall ready, let's install Bor, the execution layer. Again, we'll use the official script and ensure we use the latest valid version tag.

curl \-L https://raw.githubusercontent.com/0xPolygon/install/main/bor.sh | bash \-s \-- \<version\> mainnet sentry

#Step 6: Configure Bor for RPC Access

Now we need to tell Bor how to handle our RPC requests. Let's open the configuration file:

sudo nano /var/lib/bor/config.toml

To enable HTTP and WebSocket access, we'll update the [jsonrpc] section as follows. Note that we're binding to 127.0.0.1 by default to keep the node private and secure.

chain \= "mainnet"
\[jsonrpc\]
ipcpath \= "/var/lib/bor/bor.ipc"
\[jsonrpc.http\]
enabled \= true
host \= "127.0.0.1"
port \= 8545
api \= \["eth", "net", "web3", "txpool", "bor"\]
corsdomain \= \["\*"\]
\[jsonrpc.ws\]
enabled \= true
host \= "127.0.0.1"
port \= 8546
api \= \["eth", "net", "web3", "txpool", "bor"\]
origins \= \["\*"\]

#Step 7: Download Snapshots (Highly Recommended)

If we were to sync from scratch, it could take several days—or even weeks. By using community snapshots, we can reduce this time to just a few hours.

Warning: Before extracting snapshots, always double-check that you have enough disk space. If the extraction fails due to a full disk, it can corrupt the data, forcing us to restart the download from scratch.

Stop any running services, download the Heimdall and Bor snapshots, and extract them into their respective directories. Once finished, let's ensure the file ownership is correct so the services have the right permissions to run:

sudo chown \-R heimdall:nogroup /var/lib/heimdall
sudo chown \-R bor:nogroup /var/lib/bor

#Step 8: Start Heimdall

It's time to go live. We'll start Heimdall first and monitor the logs to ensure it's syncing correctly.

sudo systemctl daemon-reload
sudo systemctl enable heimdalld
sudo systemctl start heimdalld

We can follow the logs in real-time with this command:

sudo journalctl \-u heimdalld.service \-f

Before moving to Bor, we must check the sync status. Heimdall exposes a local status endpoint on port 26657, this is its CometBFT RPC port, used only for local health checks and doesn’t need to be opened in the firewall. Bor depends on Heimdall for checkpoint and span data, so we need `catching_up` to return `false` before we proceed.

curl localhost:26657/status

#Step 9: Start Bor

Once Heimdall is fully synced, we can start Bor.

sudo systemctl enable bor
sudo systemctl start bor

#Step 10: Verify the RPC is Working

Once Bor catches up to the current block, let's test our endpoint. We'll query the current block number to see if our node responds correctly.

curl \-s http://127.0.0.1:8545 \\
\-H "Content-Type: application/json" \\
\-d '{"jsonrpc":"2.0", "method": "eth\_blockNumber", "params": \[\], "id":1}'

If we see a hexadecimal block number in the result, our node is live! We can cross-reference this number with PolygonScan to ensure we're at the tip of the chain.

Verification Result{"jsonrpc":"2.0","id":1,"result":"0x3d0e9a7"}

#Securing Our Endpoint

If we decide to access this node remotely, we need to be careful. Exposing Bor's HTTP RPC directly to the internet (0.0.0.0) is a major security risk.

Instead, let's keep Bor on 127.0.0.1 and put an NGINX reverse proxy in front of it. This allows us to add TLS encryption and basic authentication. Furthermore, we should use firewall rules to allowlist only the specific IP addresses of our backend servers. This ensures that even if someone finds our endpoint, they can't flood it with requests or attempt to exploit it.

#Conclusion

We now have a fully functional Polygon RPC node, giving us unthrottled access to the network through infrastructure we control. By running our own node, we've eliminated our reliance on third-party Ethereum RPC providers and gained full control over our dApp's request volume. Remember to monitor your disk usage as the chain grows, and always ensure Heimdall is healthy before troubleshooting Bor. With this private gateway, our applications are now ready for production-grade performance on the Polygon network.