Polygon PoS node requirements in 2026: Heimdall-v2, Bor and archive

A Polygon PoS full node runs two clients, Heimdall-v2 and Bor. Polygon’s docs ask for 8 cores and 32 GB of RAM (16 cores and 64 GB recommended), 4–6 TB of fast storage and 1 Gbit/s; an archive node needs 16 cores, 64 GB and 16 TB. In October 2026, a full-history Bor snapshot extracts to about 7.3 TB.

The requirement figures come from Polygon’s developer documentation (which now calls the network Polygon Chain), checked on October 15, 2026. Two changes date most older guides: Heimdall-v2 replaced the original Heimdall on July 10, 2025, and Polygon Labs ended Erigon support on August 1, 2026, so archive nodes now run on Bor.

The short version

“In practice” figures are snapshot sizes from PublicNode, a community provider listed in Polygon’s docs; the disk section explains the gap.

Official Polygon PoS node hardware requirements

Polygon’s prerequisites page gives each figure as minimum/recommended. A node is one machine running both clients: Heimdall-v2, the consensus layer built on Cosmos SDK and CometBFT, and Bor, the block-producing execution layer built on Go Ethereum. The install guides start Bor only once Heimdall has synced.

Other official pages differ. The troubleshooting page on slow Bor sync recommends 6,000 IOPS and doubling the specs of a node that cannot keep up; the Bor README still lists a minimum of 4 cores, 8 GB of RAM and 1 TB, far below the table and today’s chain data.

How much disk does a Polygon full node need?

Polygon’s snapshot page sizes a mainnet node like this:

These numbers do not fit together: at 105 GB a day, the 3.5 TB left on an 8 TB disk after a 4.5 TB restore would last about a month. Snapshot providers show what the data weighs today. Here is PublicNode’s listing on October 15, 2026, converted from its byte counts to decimal units; its page shows binary units, so its “6.0 TB” full snapshot is 6.63 TB here.

What that means for sizing:

• A full-history node needs more than 8 TB. Bor’s full datadir already exceeds the docs’ 6 TB recommendation and nearly fills their 8 TB suggestion. Bor’s snapshot prune-block command “only works with hash based storage scheme”, while Bor now defaults to the path scheme with PebbleDB, so block history accumulates.
• Growth is uncertain. By our arithmetic, the newer part of the full snapshot, covering blocks produced since September 2, 2025, holds 4.13 TB: about 10 GB a day on average, a tenth of the docs’ rate. Block time and gas limit both changed in June 2026, so measure your own growth and plan with 105 GB a day as the cautious bound.
• Pruned nodes are small but undocumented. The pruned Bor snapshot reaches the same height in 109 GB; the difference is mostly old block data. Polygon’s docs only tell validators to “prune nodes regularly to reduce disk usage”, so ask the provider what history it keeps before serving RPC from one.
• Heimdall is light. Since June 2026 its shipped configuration disables the CometBFT transaction index and prunes every 10 minutes, which Polygon says frees about 23 GB on a mainnet RPC node. Its full history since the 2025 migration takes 3.7 TB; the mainnet genesis file alone is about 3 GB.
• Use local NVMe. Disk IOPS governs extraction, sync and compaction, the docs say; they call direct-attached storage ideal, ask AWS users to provision 16,000 IOPS and want 20,000+ for archive. Hard-drive arrays fall far short.

The snapshot page lists six community providers plus the All4nodes aggregator. With a snapshot, a node syncs in “hours rather than days”; from the network, the full-node guide warns, it takes several days.

Polygon archive node: Bor with PBSS, not Erigon

The prerequisites table still labels its archive row Erigon, and the Polygon Chain overview still calls Erigon “also supported”. Both are out of date:

• September 17, 2025: Erigon v3.1.0 handed support for the Polygon PoS client from the Erigon team to Polygon Labs.
• May 12, 2026: Polygon Labs announced the end of Erigon support “by 1st August” and recommended “Bor w/ PBSS”, the path-based state scheme, for archive nodes.
• August 3, 2026: the 0xPolygon/erigon repository was archived. Its README rules out further releases and security updates, and warns that existing deployments would keep syncing only until the next Bor hard fork; Austin followed on August 13.

The announcement includes a mainnet config.toml. Its essential lines:

chain = "mainnet"
datadir = "/var/lib/bor/data"
"db.engine" = "pebble"
"state.scheme" = "path"
syncmode = "full"
gcmode = "archive"

[history]
  transactions = 0   # 0 = index the entire chain
  logs = 0
  state = 0          # 0 = keep state history back to genesis

[cache]
  cache = 24576
  gomemlimit = "55GB"

• Disk. PublicNode’s path-based Bor archive takes 12.95 TB, inside the docs’ 16 TB. Add 10 GB for a pruned Heimdall or 3.7 TB for an archive one.
• Memory. A 24 GB cache and a 55 GB Go memory limit imply at least 64 GB of RAM, as the archive row says.
• APIs. Bor serves eth_getProof only for the latest 128 blocks. Its Parity-style trace_* namespace is off by default and needs an archive node and --rpc.enabletrace; trace_block omits state-sync transactions before block 80,084,800.
• Installer. The mainnet archive template in Bor’s packaging still sets state.scheme = "hash". Change it to the settings above before the first start.

Polygon validator requirements: sentry plus validator

A validator is two nodes, each meeting the full-node specification: a public sentry, and a validator “accessible only through its sentry node”. Polygon’s docs add:

• Extra pieces. RabbitMQ on the validator; an Ethereum RPC endpoint, from a provider or your own node (see our Ethereum node hardware guide); and, since Heimdall-v2, the signing key imported into the keyring.
• Stake and slots. At least 100,000 POL of self-stake for new validators (PIP-70) and at most 105 active validators, so newcomers wait for a slot to free up; applying does not guarantee one.
• Ethereum costs. A checkpoint to sign roughly every 15–20 minutes, and 0.5 to 1 ETH kept on the signer address to submit them.
• A performance floor. Signing is measured over the last 700 checkpoints against 98% of the validator set’s median; below it come two grace periods of 700 checkpoints each, then forced unstaking.
• Single purpose. Only Bor, Heimdall and RabbitMQ, no public RPC and no port reachable from the internet: 30303 and 26656 open to the sentry only, SSH through a VPN.

If the median validator signs every checkpoint, 98% of 700 allows about 14 misses: three and a half to nearly five hours of downtime per window, by our arithmetic. That favors mirrored disks, and quick restarts. Bor v2.10.3, released on October 15, 2026, reworked the trie preload that runs on restart and can persist its address cache (off by default, about 9 GB on mainnet); Polygon reports the preload on a mainnet sentry falling from about 1 h 25 min to about 4 s.

CPU and RAM: why 16 cores and 64 GB

Polygon’s docs give core counts, not clock speeds, but the chain’s pace explains the 16-core tier. Since June 3, 2026, mainnet has produced a block every 1.5 seconds, and a June gas-limit increase to 160 million lifted capacity to about 106.66 Mgas/s, according to Polygon’s changelog. Bor executes transactions in parallel with BlockSTM v2, on by default since v2.9.1, and its default configuration gives the parallel EVM 8 workers.

Catching up is where speed shows. The troubleshooting page wants block import above 2 blocks a second; at that floor, a node restored from a day-old snapshot needs about 12 hours to reach the head, because the chain keeps adding a block every 1.5 seconds (our arithmetic).

On memory, the 32 GB minimum and 64 GB recommendation leave room for Bor’s caches: its mainnet sentry template allots 4 GB, the archive configuration above six times that.

Ports and bandwidth

The table combines the prerequisites and network configuration pages. Without both TCP and UDP on 30303, Polygon warns, a node “will struggle to find peers”.

Every node type asks for 1 Gbit/s, and the docs give no monthly traffic figure. The first download dominates: the 6.6 TB of full-node snapshots take about 15 hours at a sustained 1 Gbit/s, the 11.9 TB archive about 26. A 10 Gbit/s port cuts that to roughly 1.5 and 2.6 hours if the mirror keeps up, and on an unmetered 10 Gbps port the volume never reaches the bill.

Which PowerDedi server for a Polygon node

RAID is chosen when you order or reinstall: RAID 1 (default), RAID 0 or no RAID on two-drive servers, plus RAID 10 (default there) and RAID 5 on four-drive NVMe servers; our software RAID guide has the details.

The caveats, stated plainly:

• No two-drive server holds a full-history mainnet node any more. Striped, the largest pairs give 7.68 TB, about 0.4 TB above today’s data. The EPYC 9555P is the smallest configuration that fits; its 4.2 TB of RAID 5 headroom lasts over a year at the 13-month average, but only about 40 days at the docs’ 105 GB a day.
• Mirror validators, stripe archives. A validator’s downtime budget is a few hours, so keep RAID 1 on both machines. Polygon’s archive row itself specifies RAID 0, and a striped archive that loses a drive can be restored from snapshots in about a day of downloading at 1 Gbit/s. RAID 5 sits in between: it survives one failed drive, with parity overhead on writes.
• Archive on a tighter budget. The EPYC 9555P in RAID 0 holds today’s 12.95 TB Bor archive with about 2.4 TB to spare, under the docs’ 16 TB. The EPYC 9965 meets that figure with room left; its 2.25 GHz base clock is the lowest of our EPYCs, so choose it for the drives, not the cores.
• Not a fit. Our storage servers, whose hard-drive arrays cannot deliver the IOPS Polygon asks for; and anyone who only reads the chain, whom the docs point to RPC endpoints instead.

Polygon’s docs do not tie node placement to a region, so pick the city closest to your users: the 9950X3D is in Amsterdam, Frankfurt, New York and Los Angeles, the 9555P in Amsterdam, Frankfurt, New York and Tokyo, the 9965 in Amsterdam, Frankfurt and New York.

How to run a Polygon full node: setup outline

These steps use the package installers and commands from Polygon’s full-node guides, with the latest releases as of October 15, 2026; snapshot file names are placeholders.

# 1. Install Heimdall-v2 and Bor ("sentry" is the full-node profile)
curl -L https://raw.githubusercontent.com/0xPolygon/install/heimdall-v2/heimdall-v2.sh | bash -s -- v0.12.2 mainnet sentry
curl -L https://raw.githubusercontent.com/0xPolygon/install/main/bor.sh | bash -s -- v2.10.3 mainnet sentry

# 2. Initialize Heimdall for mainnet and fetch the migrated genesis (about 3 GB)
sudo -u heimdall heimdalld init my-node --chain-id=heimdallv2-137 --home /var/lib/heimdall
cd /var/lib/heimdall/config
curl -fsSL https://storage.googleapis.com/mainnet-heimdallv2-genesis/migrated_dump-genesis.json -o genesis.json

# 3. Restore community snapshots into the data directories (follow the provider's steps)
lz4 -dc HEIMDALL_SNAPSHOT.tar.lz4 | tar -x

# 4. Start Heimdall; start Bor only once "catching_up" is false
sudo service heimdalld start
curl localhost:26657/status
sudo service bor start
journalctl -u bor.service -f

Set Heimdall’s seeds and Bor’s bootnodes from the docs’ seed list if your templates lack them. Three cautions:

• Upgrades come often. Mainnet went through hard forks on June 2, June 25 (Zurich), July 29 (Ithaca), August 13 (Austin, requiring Bor v2.10.0 or later) and October 1, 2026 (Lugano, Heimdall v0.12.1). Heimdall nodes still on v0.11.0 or older stopped at the Lugano height.
• Skip the Docker guide for now. It pins Bor 1.1.0 and Heimdall-v2 0.2.16 images from Docker Hub, versions that cannot follow mainnet past those forks, and Bor v2.10.2 and Heimdall v0.12.2 stopped publishing images there.
• Check file ownership after a restore. The snapshot page’s permissions tip swaps the two directories: the bor user should own Bor’s datadir, and heimdall Heimdall’s.

Before opening anything beyond 26656 and 30303, work through our first-hour hardening checklist.

Common questions

Do I need my own Polygon node? Not to send transactions or read the chain now and then: the prerequisites page sends users who only need a connection to Polygon’s list of RPC endpoints. Your own node makes sense for validators, indexers and applications whose request volume outgrows shared endpoints.

Can I run a Polygon validator on PowerDedi? Yes: nodes and validators are permitted under our acceptable use policy; mining is not. Stock, locations and crypto payment options are on the blockchain node hosting page.

Sources

• Prerequisites and Known issues and errors — Polygon Developer Docs (checked October 15, 2026)
• Sync node using snapshots — Polygon Developer Docs
• Using binaries, Using packages and Using Docker — Polygon Developer Docs
• Network configuration, Polygon Chain overview and Changes from v1 — Polygon Developer Docs
• Becoming a validator, Validator best practices and Validator performance requirements — Polygon Developer Docs
• Changelog — Polygon Developer Docs (entries from June 1 to October 12, 2026)
• Sunsetting Erigon Support (May 12, 2026) and Erigon Update and future plans (September 30, 2025) — Polygon Labs on the Polygon Forum
• 0xPolygon/erigon — GitHub (archived August 3, 2026)
• Bor README, default_config.toml, snapshot prune-block, mainnet archive template and release notes for v2.10.2 and v2.10.3 — 0xPolygon/bor on GitHub
• Release notes for v0.12.1 (Lugano) and v0.12.2 — 0xPolygon/heimdall-v2 on GitHub
• Planned Migration – Heimdall V1 → V2 — Polygon Status
• Fast Node Snapshots for 100+ Blockchains — PublicNode by Allnodes (checked October 15, 2026)