On this page 11 sections
- The short version
- Official Aptos validator and VFN hardware requirements
- Public fullnode requirements
- How much storage an Aptos node needs
- Network bandwidth and ports
- Bootstrapping: fast sync, backups or snapshots
- Validator-specific requirements
- Which PowerDedi server for an Aptos node
- How to run an Aptos fullnode: setup outline
- Common questions
- Sources
An Aptos validator, validator fullnode (VFN) or production public fullnode (PFN) needs 48 CPU threads on a 5th-generation AMD EPYC (Turin) or 6th-generation Intel Xeon (Granite Rapids), 128 GB of RAM, a 3 TB enterprise NVMe SSD rated for 60,000 IOPS and 600 MiB/s, and 1 Gbps of bandwidth, according to Aptos’s documentation as of October 2026.
Those figures date from March 18, 2026, when Aptos replaced a reference of 32 cores, 64 GB of RAM and 200 MiB/s that older guides still quote. A validator also needs a second machine of the same class for its VFN, and at least 1 million APT of stake. This guide covers hardware and setup, not staking or financial advice.
The short version
| Node | Role | Hardware, per machine | Data on disk | Open to the internet |
|---|---|---|---|---|
| Validator | Consensus; at least 1M APT staked | 48 threads (Turin or Granite Rapids), 128 GB, 3 TB NVMe at 60K IOPS and 600 MiB/s, 1 Gbps | Pruned database, plus 4.9 GB of trusted-setup files | TCP 6180; 6181 to your VFN only |
| VFN | Serves the validator’s data to the public network | The same, on a separate machine | Pruned database | TCP 6182; 6181 to your validator only |
| PFN, production | Your own API for apps, wallets and indexers | The same as a validator or VFN | “Several 100’s of GB”, pruned | TCP 6182, optional |
| PFN, development or testing | Testnet, devnet, experiments | “Lower hardware specs”, no figure given | Devnet is wiped weekly | TCP 6182, optional |
| Archival PFN | All history since genesis | Deprecated by Aptos | Grows without bound; no size recommended | TCP 6182, optional |
Official Aptos validator and VFN hardware requirements
Aptos sizes nodes for throughput: hardware should be “performant enough to maintain ~30,000 transactions per second (TPS)”, proven either by matching the reference specifications or by passing Aptos’s benchmark. The reference from the Node Requirements page, last updated September 14, 2026:
| Component | Aptos reference for mainnet |
|---|---|
| CPU | 48 threads, 5th Gen AMD EPYC (Turin) or 6th Gen Intel Xeon (Granite Rapids) |
| Memory | 128 GB RAM |
| Storage | 3.0 TB enterprise NVMe SSD with at least 60K IOPS and 600 MiB/s |
| Network | 1 Gbps |
The table applies to each machine. Aptos “strongly” recommends running the validator and the VFN on two separate, independent machines, isolated from each other for security and performance. Its overview calls the VFN optional but “highly recommended”; its operator checklist says both are required on mainnet, so plan for two servers. Aptos’s cloud examples (AWS c8a.16xlarge, GCP c4d-standard-48, Azure Standard_F48as_v7, Latitude.sh f4.metal.large) all come with 60K IOPS of storage.
What changed in March 2026
Aptos raised the reference on March 18, 2026, in a documentation change titled “Update validator node requirements and examples”:
| Component | Until March 18, 2026 | Since then |
|---|---|---|
| CPU | 32 cores, 2.8 GHz or faster, AMD Milan EPYC or Intel Xeon Platinum | 48 threads, 5th Gen AMD EPYC (Turin) or 6th Gen Intel Xeon (Granite Rapids) |
| Memory | 64 GB | 128 GB |
| Storage | 3.0 TB SSD, 60K IOPS, 200 MiB/s | 3.0 TB enterprise NVMe SSD, 60K IOPS, 600 MiB/s |
| Network | 1 Gbps | 1 Gbps |
On thread count the new line is lower, since 32 cores with simultaneous multithreading meant 64 threads; what changed is the processor generation, twice the memory and three times the disk bandwidth. Aptos’s own Helm chart has not caught up: in aptos-core v1.49.5, released October 7, 2026, it still reserves 30 CPUs and 60 GiB of memory per validator and VFN. A guide quoting “32 cores and 64 GB” predates March 2026.
Checking a machine with Aptos’s benchmark
If your processor is from another family, measure it. From a clone of aptos-core with its build dependencies installed:
TABULATE_INSTALL=lib-only pip install tabulate
./testsuite/performance_benchmark.sh --short
The script prints a “t/s” column with the throughput reached and warns if the hardware falls short. The 30,000 TPS target is headroom, not today’s load: by our reading of the Aptos Labs API, mainnet averaged about 13.5 million transactions a day, roughly 156 per second, between October 6 and 15, 2026. Aptos asks operators to provision for “the most demanding transaction workloads”, and says its figures “may be subject to change”.
Public fullnode requirements
The PFN Requirements page publishes no numbers of its own. For a production-grade PFN, Aptos recommends “the same requirements as a validator or VFN” and warns that an under-provisioned one will “experience degradation under load and general instability”. Lower specifications are acceptable for development or testing only, with no figure given.
Consensus observer, which Aptos credits with cutting end-to-end transaction latency on mainnet by 10% to 50% depending on load, is on by default for validators and VFNs but off for PFNs, “because it requires nodes to meet the minimum hardware requirements”: it uses more CPU than traditional state sync. A PFN that meets the table can enable it in its configuration.
Check first that you need a PFN. Aptos Labs’ public fullnodes serve a REST API with rate limits; higher limits come with a Geomi account and a payment method. Your own node removes the limits and the third-party dependency, which matters for wallet and exchange back ends and for indexers.
How much storage an Aptos node needs
Aptos asks for 3 TB but expects far less data on a pruned node: “At the time of writing, we estimate that testnet and mainnet require several 100’s of GB of storage.” The estimate is undated, and we found no dated mainnet database size in October 2026. Two other official reference points:
- Aptos’s Helm charts in aptos-core v1.49.5 allocate 2,048 GiB to each validator and VFN volume, and 1,000 GiB to a standalone fullnode.
- Validators also load two trusted-setup files for distributed key generation (DKG),
digest_key.binandpp.bin: 4,002,048,590 and 889,521,361 bytes on mainnet, about 4.9 GB, per checksums current as of July 7, 2026. VFNs and PFNs do not need them.
The 3 TB line is also about speed: 60,000 IOPS and 600 MiB/s, from local NVMe or from network storage provisioned to that level. Aptos notes that local SSDs usually offer lower latency and cost relative to IOPS, while network storage handles backups and node failures better.
The ledger pruner: how much history a node keeps
Every Aptos node prunes its transaction history by default, and two official sources disagree on the window:
- The Data Pruning page says the default keeps “only the most recent 150 million transactions” and that a window under 100 million “can lead to runtime errors”.
- The node’s source code at aptos-node v1.49.5, the latest mainnet release with published source when we checked, sets a default
prune_windowof 90,000,000 and logs a warning only below 50,000,000.
Aptos Labs’ public API nodes kept 149.8 million transactions when we queried them on October 15, 2026, matching the documented 150 million: about 11 days of history at October’s rate, against under 7 days for 90 million. Set the window explicitly rather than rely on either default:
storage:
storage_pruner_config:
ledger_pruner_config:
prune_window: 150000000
A wider window keeps more history at the cost of disk space. Disabling the pruner (enable: false) makes the node archival, with “unbounded storage growth”.
Archival nodes
Archival nodes “have officially been deprecated”, Aptos says; for full history it recommends an indexer, and it declines to recommend an archival disk size. The backup-restore guide still lists 1 TB of disk and 32 GB of RAM for a full mainnet restore. That undated table sits oddly beside a 3 TB reference for pruned nodes and a ledger past 7.6 billion transactions, so we would not size an archival machine from it.
Network bandwidth and ports
Aptos asks for 1 Gbps per node and gives no monthly traffic figure. Validators talk to each other on the validator network, each validator to its VFN on a private VFN network, and VFNs and PFNs on the public network, each on its own TCP port. With default settings:
| Port (TCP) | Network or service | Validator | VFN | PFN |
|---|---|---|---|---|
| 6180 | Validator network | Open publicly | Not used | Not used |
| 6181 | VFN network | Open to your VFN only | Open to your validator only | Not used |
| 6182 | Public network | Closed | Open publicly | Open publicly, if you accept inbound peers |
| 9101 | Inspection service (metrics) | Closed | Closed | Closed |
| 9102 | Admin service | Closed | Closed | Closed |
| 80 or 8080 | REST API | Closed | Closed | Closed, or behind authentication and rate limiting |
Aptos asks operators to expose nothing else, and never the inspection or admin ports, which “can be easily abused”. Its examples are less tidy: the PFN page’s sample configuration listens on 6180, bound to 127.0.0.1 so it accepts no inbound connections, and the PFN Docker guide configures 6182 but its docker run line publishes 6180, 8080 and 9101. Publish only the public port your fullnode.yaml uses and keep the API and metrics on 127.0.0.1; a PFN that wants no inbound peers can listen on /ip4/127.0.0.1/tcp/6182.
# Validator (on the VFN: allow 6182/tcp, and 6181 from VALIDATOR_IP only)
ufw default deny incoming
ufw allow 22/tcp
ufw allow 6180/tcp
ufw allow from VFN_IP to any port 6181 proto tcp
ufw enable
With Aptos’s Docker Compose files, test from another machine that only the intended ports answer. Keep the clock synchronized too: Aptos highly recommends NTP, warning that with inconsistent system time validators “may even fail to propose blocks”. PowerDedi’s always-on network DDoS mitigation sits in front of these ports but does not replace the firewall; our first-hour hardening checklist covers the rest.
Bootstrapping: fast sync, backups or snapshots
A new node has three documented ways to catch up with mainnet:
- Fast sync, the default on mainnet and testnet, downloads the latest state, skips historical transactions and then follows the chain. Aptos says it “usually completes within a few hours” on well-provisioned nodes, depending on bandwidth and disk speed.
- Backups. Aptos Labs’ public backups, on Amazon S3 and Google Cloud Storage for mainnet (Google Cloud only for testnet), carry cryptographic proofs.
aptos node bootstrap-db, in Aptos CLI 1.0.14 or later, restores the latest state or a range of history; it is Aptos’s recommended route to full history, and a restore from genesis needs an open-file limit of at least 999,999. - Community snapshots are discouraged on mainnet because “snapshots are not verified by the Aptos software”; use one only if you made it or trust its source, after verifying checksums. BWareLabs, the one provider the docs list, did not load when we tried on October 15, 2026.
Syncing from genesis needs seed peers added by hand, since most mainnet nodes no longer hold old data. For validators, the VFN syncs first, and the validator neither syncs nor joins consensus until its stake pool is in the validator set.
Validator-specific requirements
- Stake. Joining the validator set takes at least 1 million APT; above 50 million, voting power and rewards are calculated on 50 million. A delegation pool can gather stake from several delegators to reach the minimum. On mainnet, stake sits in a 14-day recurring lockup, and changes take effect at the next epoch, every two hours.
- Keys. Generate them once with the Aptos CLI, back up
private-keys.yamland copy the files to the VFN; a second set generated there “will not be recognized by the network”. Aptos recommends DNS names over IP addresses for easier migrations. - Trusted-setup files. Download
digest_key.binandpp.binfrom GitHub’s/raw/URLs, not raw.githubusercontent.com, which returns a 135-byte Git LFS pointer, then check them withaptos node validate-digest-keyandaptos node validate-public-parameters. Aptos warns that the wrong URL “will silently break consensus”. - Storage sharding. The deployment guide sets
storage.rocksdb_configs.enable_storage_shardingtotrueon both nodes.
Which PowerDedi server for an Aptos node
Every PowerDedi server has its own 10 Gbps unmetered port, ten times the 1 Gbps Aptos asks for and with no traffic quota, and is billed month to month.
| Use | Configuration | Against Aptos’s reference | Price |
|---|---|---|---|
| Validator, VFN or production PFN | EPYC 9355P: 32 cores, 64 threads, 384 GB DDR5 ECC, 2 × 3.84 TB NVMe Gen5 | Meets the CPU, memory and disk-size lines: an EPYC 9005, the series AMD calls its 5th generation; 64 threads; three times the memory; 3.84 TB mirrored. Built in 24 hours; AMS, FRA, NYC, TYO | $519/mo |
| Production PFN, delivered in minutes | EPYC 9454P: 48 cores, 96 threads, 256 GB DDR5 ECC, 2 × 3.84 TB NVMe | Twice the threads and memory, 3.84 TB mirrored, but a 4th-generation EPYC 9004 launched in 2022: benchmark it first. About 15 minutes; AMS, FRA, NYC, LAX, SIN | $489/mo |
| PFN with a wider history window, or an indexer beside it | EPYC 9555P: 64 cores, 128 threads, 768 GB DDR5 ECC, 4 × 3.84 TB NVMe Gen5 | 7.68 TB in RAID 10, the four-drive default. Built in 24 hours; AMS, FRA, NYC, TYO | $949/mo |
| Testnet or development PFN | Ryzen 9 9950X3D: 16 cores, 32 threads, 192 GB DDR5, 2 × 3.84 TB NVMe | Under 48 threads, so not for production. About 15 minutes; AMS, FRA, NYC, LAX | $219/mo |
A validator needs two of the first configuration, one per node. Aptos gives no location guidance and we have no reliable data on where its validator set runs, so choose the city by where your users and team are. Four caveats:
- Disk layout. Two-drive servers default to RAID 1, which leaves 3.84 TB on the 9355P, 9454P and 9950X3D: more than the 3 TB reference, and a mirror that survives a drive failure. RAID 0 doubles capacity without redundancy; a dead drive then means a new fast sync of a few hours. Keep the mirror on a validator.
- Disk speed. Aptos asks for enterprise NVMe with 60K IOPS and 600 MiB/s. Check the drive models with
nvme list, measure the array withfio, and run Aptos’s benchmark before staking on the machine. - Smaller servers. The Ryzen 9 9950X ($159/mo) and EPYC 4585PX ($179/mo) have 32 threads and 2 × 1.92 TB NVMe; a 1.92 TB mirror holds “several 100’s of GB” but not the 3 TB reference. Fine for testnet, not for mainnet production.
- What we do not offer. No Intel Granite Rapids, and no managed Kubernetes for Aptos’s Terraform and Helm templates; for that model, use the cloud machine types in Aptos’s docs.
How to run an Aptos fullnode: setup outline
These steps condense Aptos’s source-code guide for a mainnet PFN. Validators follow the longer guide, which adds keys, trusted-setup files and stake pool operations.
# 1. Clone aptos-core, switch to the mainnet branch, install build tools
git clone https://github.com/aptos-labs/aptos-core.git
cd aptos-core
git checkout --track origin/mainnet
./scripts/dev_setup.sh
source ~/.cargo/env
# 2. Genesis, waypoint and the PFN configuration template
curl -O https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/genesis.blob
curl -O https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/waypoint.txt
cp config/src/config/test_data/public_full_node.yaml fullnode.yaml
# Edit base.data_dir, the genesis and waypoint paths, and the prune_window shown above
# 3. Build and start; fast sync is the default on mainnet
cargo run -p aptos-node --release -- -f ./fullnode.yaml
# 4. Follow progress: synced_states rises during fast sync, then synced
curl 127.0.0.1:9101/metrics 2> /dev/null | grep "aptos_state_sync_version"
Aptos tests its Linux builds on Ubuntu 20.04 and 22.04, and its Docker images run only on x86-64 processors, which every PowerDedi server has. For a long-running node, move the release binary to /usr/local/bin and run it under systemd; Aptos’s unit template sets LimitNOFILE=500000 and restarts the process on failure.
Common questions
Can a validator and its VFN share one server? Aptos “strongly” recommends against it: two separate machines, each meeting the full specification, so that load on one cannot degrade the other.
What does an Aptos validator cost to run? Two machines that meet the reference, two EPYC 9355P at $519/mo each on PowerDedi, plus at least 1 million APT staked on a 14-day recurring lockup. We do not estimate rewards.
For another high-throughput chain, see our Solana RPC node hardware guide. Current stock for every configuration above is on our blockchain node hosting page, payable in BTC, ETH, XMR, USDT on TRON or SOL.
Sources
- Node Requirements — Aptos Documentation (last updated September 14, 2026)
- PFN Requirements and Deploy a PFN — Aptos Documentation
- State Synchronization, Data Pruning and Consensus Observer — Aptos Documentation
- Bootstrap from a Backup and Bootstrap from a Snapshot — Aptos Documentation
- Run a Validator and VFN, Operator, Connect to a Network and Node Health — Aptos Documentation
- Using Source Code (validator and VFN), Using Source Code (PFN), Using Docker (PFN) and Building Aptos From Source — Aptos Documentation
- Update Trusted Setup — Aptos Documentation (checksums current as of July 7, 2026)
- Staking and Delegated Staking — Aptos Documentation
- Update validator node requirements and examples (#368) — aptos-labs/aptos-docs on GitHub (March 18, 2026)
- storage_config.rs, aptos-node Helm values and fullnode Helm values at aptos-node-v1.49.5 — aptos-labs/aptos-core on GitHub (release of October 7, 2026)
- Aptos mainnet REST API, ledger information and transactions by version — Aptos Labs (queried October 15, 2026)
- AMD EPYC 9355P and AMD EPYC 9454P specifications — AMD




