Content Node Setup
Prerequisites
Infrastructure Requirements
Ubuntu Linux
2 dedicated vCPUs (2015+ vintage from AMD/Intel)
4GB RAM
100GB SSD storage
Datacenter-quality internet connection
Static public IP
Network Requirements
Fully qualified domain name (FQDN) for each node (eg.
content4.us-east-2.operator.com) that accepts HTTPs traffic (See Setup Step 3)
Ethereum Prerequisites
Note – Our Testnet currently runs on Sepolia
Ethereum wallet (
OperatorWallet)to manage EarthFast resources on-chain (staking, node registration, etc.)Sufficient ETH balance in Wallet. On Testnet, we have a faucet that will fund your wallet with Sepolia ETH.
EARTHFAST token balance, used for staking. On Testnet, we have a faucet that will fund your wallet with Sepolia test EARTHFAST tokens.
[Optional] Ethereum RPC provider capable of serving up to 100,000 requests per day (e.g. Chainstack, Blockdaemon, Infura, Alchemy, Quicknode or your own Ethereum node). We have a default RPC built into the CLI but for better performance it's recommended to use a custom RPC.
Operational requirements
Ensure operations support for high uptime and availability
Setup
If you have previously setup a node, skip to 3 – Node Setup
Step 1 – Setup Wallet with earthfast-cli
https://github.com/earthfast/earthfast-cli – You will use this CLI to manage all EarthFast resources.
Below commands instruct you to use this cli via npx, which means you don't have to install anything.
For all available commands and options run npx earthfast-cli --help. For help on individual commands append --help to a command, eg. npx earthfast-cli node create --help.
Where to run CLI
This is intended to run on your local machine, although you can run on your content node VM if you choose to. Currently supported on MacOS + Debian.
If running on Debian, install deps
[Optional] Alias
For brevity, consider setting up a shell alias like alias ef="npx earthfast-cli"
Decide how you will sign Eth transactions
The CLI can sign transactions for you if you import your OperatorWallet into its keystore. This is done locally using keytar – you can see the code here.
Alternatively, you can set the optional signer flag to --signer=ledger for use with a Ledger, or --signer=raw to export transaction info for external signing.
Fund your wallet from our testnet fauce
2 – Operator Setup
2a – Get your OperatorID
Nodes on EarthFast must be owned by an onchain Operator. After registering your Operator onchain with your OperatorWallet, you'll get a unique OperatorID which you will later use to register and manage your nodes.
This should output an operatorId, use that in the steps below
2b – Stake EARTHFAST Tokens for your Operator
For Testnet, just use the below command, which stakes 100 tokens by default.
3 – Node Setup
Repeat this setup for each Content Node
Each Content Node must be addressable by a unique FQDN.
Be prepared to serve HTTPS traffic at these hostnames, provisioning SSL certificates as necessary. If you use our provided node-operator-tooling it can provision SSL certificates.
Since you will likely run multiple nodes, we recommend a naming convention of content<number>.<location>.testnet-sepolia.example.com.
3a – Register a Node onchain
Register your Node onchain before setting up the server so you can get the unique network NodeID . This will be passed during Content Node container setup (see Step 5 below).
Explanation of <RegionCode>:false:1.0 from above command:
<RegionCode>United States -us, Africa -af, Asia -as, Australia -au, Europe -eu, North America -na, South America -safalseindicates the node is in disabled state since the server will be configured in subsequent steps, after which you will update its state1.0sets initial reservation price. This is a fine default for Testnet.
If the transaction was successful, your new node's NodeID will be logged. Save this; you'll need it later.
3b – Configure & run the Content Node on each VM
Follow the instructions in the node-operator-tooling repo to configure your node with Docker Compose: https://github.com/earthfast/node-operator-tooling/tree/main/content-node
3c – Enable your Node onchain
Once you've successfully configured the node, it needs to be enabled on-chain before a project can reserve it.
Monitoring
You should monitor the container health of content nodes that are running in production, including:
CPU utilization
Memory utilization
Disk utilization
Network utilization
Additionally, the content node exposes a /metrics endpoint that exports internal metrics in Prometheus format. These include, for instance, HTTP request latency distributions. The endpoint is exposed on HTTP_PORT, and is therefore publicly accessible - this is intentional as projects themselves should be able to monitor the performance of their reserved content node fleet.
Last updated