Run a PFN from Source Code

You can run your own public fullnode (PFN) to synchronize the state of the Aptos blockchain and stay up-to-date. PFNs replicate the entire state of the blockchain by syncing from other Aptos VFNs and PFNs. PFNs can be run by anyone. This tutorial explains how to deploy a PFN and connect to an Aptos network.

Do I have to run a PFN? If you do not wish to run a PFN, but still want to interact with the Aptos blockchain, you can use the REST API provided by the Aptos Labs’ PFNs (see Aptos APIs). Note, however, that Aptos Labs-provided PFNs have rate limits, which can impede your development. If you want to avoid such rate limits, you can deploy your own PFN and synchronize with the Aptos blockchain directly.

Choose a network This document describes how to start a public fullnode in the Aptos mainnet network, but it can easily be used to do the same in the devnet or testnet networks. To do so, check out the desired network branch and use the genesis.blob and waypoint.txt node files for the respective branches: mainnet, devnet, and testnet.

Hardware requirements

For running a production-grade PFN, we recommend that your hardware meet the same requirements as a validator or VFN. You can see the hardware requirements for these nodes, here: validator and VFN hardware requirements.

If you wish to run a PFN for development or testing only, lower hardware specs can be used. But, it should not be used in production. For example:

• CPU: 8 cores, 16 threads (Intel Xeon Skylake or newer).

• Memory: 32GB RAM.

Minimum hardware requirements Failing to meet the minimum hardware requirements for a production-grade PFN mean that your PFN will likely experience degradation under load and general instability in production environments.

Network requirements and ports

When you are running a PFN, you are required to open network ports on your nodes to allow other nodes (i.e., peers) to connect to you. There are different Aptos network types, and each network type uses a different port. However, the only network type that a PFN uses is the public network, where PFNs to connect to other PFNs and VFNs.

Your PFN can be configured so that the public network operates using a specific port on your node. You can configure the port settings using the node configuration YAML file. Here is an example configuration file for a PFN that configures the public network to use port 6180.

Port settings

The recommendations described below assume the default port settings used by PFNs. If you have changed the default port settings in your configuration file, then you should adjust the recommendations accordingly.

Exposing ports Unless explicitly required, we recommend that you do not expose any other ports while operating a PFN. This is because exposing additional ports can increase the attack surface of your node and make it more vulnerable to adversaries.

Running a PFN:

Assuming default ports are used, the following should be configured for PFNs:

• Open the following TCP ports:

  • 6182 – Public network: Open this port publicly to enable PFNs to connect to your VFN.

• Close the following TCP ports:

  • 9101 – Inspection service: Close this port to prevent unauthorized metric inspection.

  • 9102 – Admin service: Close this port to prevent unauthorized admin service interaction.

  • 80/8080 REST API: Close this port to prevent unauthorized REST API access.

Exposing services We note that the inspection service port (9101), admin service port (9102) and the REST API port (80 or 8080) are likely useful for your internal network, e.g., application development and debugging. However, the inspection service port and the admin service port should never be exposed publicly as they can be easily abused. Similarly, if you choose to expose the REST API endpoint publicly, you should deploy an additional authentication or rate-limiting mechanism to prevent abuse.

Default network settings You may also need to update the 127.0.0.1 with 0.0.0.0 in the fullnode.yaml for the fields listen_address and address field in the api list.

Storage requirements

The amount of data stored by Aptos depends on the ledger history (length) of the blockchain and the number of on-chain states (e.g., accounts and resources). Both the ledger history and the number of on-chain states depend on several additional factors, including the age of the blockchain, the average transaction rate over time, and the configuration of the ledger database pruner.

Note that because archival nodes store the entire history of the blockchain, the database size on archival nodes will continue to grow unbounded. As a result, we cannot provide a recommendation for archival node storage sizes.

Devnet blockchain storage The Aptos devnet is currently reset on a weekly basis. If you are deploying a devnet PFN, this means that the storage will be reset (i.e., wiped) every week. See the #devnet-release channel on the Aptos Discord.

Deploying a PFN

You can deploy a PFN in one of two ways: (i) building and running aptos-core from source code; or (ii) using Docker. This document describes how to deploy your PFN using both methods.

Method 1: Building and running from source

First, see Building Aptos From Source for instructions on how to download the aptos-core repository and build the binary. Then, follow the steps below:

1. Make sure your current working directory is aptos-core.

2. Check out the mainnet branch using git checkout --track origin/mainnet; remember, you may instead use devnet or testnet if you wish to run your PFN in a different network.

3. Next, download the genesis.blob and waypoint.txt files for the network your PFN will connect to:

   • Run this command to download the genesis blob (for mainnet):

     curl -O https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/genesis.blob

   • Run this command to download the waypoint file (for mainnet):

     curl -O https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/waypoint.txt

Don’t want to connect to mainnet? To connect to other networks (e.g., devnet and testnet), you can find the genesis and waypoint here ➜ https://github.com/aptos-labs/aptos-networks. Be sure to download the genesis.blob and waypoint.txt for those networks, instead of using the genesis and waypoint pointed to by the curl commands above.

1. Next, run the command below to create a copy of the PFN configuration YAML template:

cp config/src/config/test_data/public_full_node.yaml fullnode.yaml

1. Finally, edit the fullnode.yaml configuration file to ensure that your PFN: (i) contains the genesis blob and waypoint file you just downloaded; and (ii) saves the synchronized blockchain data to the location of your choice (on your local machine). To do this:

2. Specify the correct path to the genesis.blob file you just downloaded by editing execution.genesis_file_location in the fullnode.yaml configuration. By default, it points to genesis.blob in the current working directory. fullnode.yaml

   execution: 
     genesis_file_location: "./genesis.blob"

3. Specify the correct path to the waypoint.txt file you just downloaded by editing base.waypoint.from_file in the fullnode.yaml configuration. By default, it points to waypoint.txt in the current working directory. For example: fullnode.yaml

   base:  waypoint:    
     from_file: "./waypoint.txt"

4. Specify the directory on your local machine that you want to store the blockchain database by editing the base.data_dir in the fullnode.yaml configuration. For example, you can create a directory my-full-node/data in your home directory and specify it as: fullnode.yaml

   base:  data_dir: "</path/to/my/homedir/my-full-node/data>"

5. Start your local public fullnode by running the below command:

cargo run -p aptos-node --release -- -f ./fullnode.yaml

You have now successfully configured and started running a PFN in the Aptos mainnet.

Debugging? The command above will build a release binary for aptos-node at: aptos-core/target/release/aptos-node. The release binaries tend to be substantially faster than debug binaries but lack debugging information useful for development. To build a debug binary, omit the --release flag from the command above.