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.)[Not required for Testnet] sufficient ETH balance in Wallet
for Testnet, we will fund your wallet with Sepolia ETH. More details coming soon
[Not required for Testnet] EARTHFAST token balance, used for staking
for Testnet, we will fund your wallet. More details coming soon
[Not required for Testnet] 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)
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 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 project create --help
.
Where to run CLI
This is intended to run in your dev environment, not your node VM, although you can run it wherever you like. 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 wallet 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.
2 – Operator Setup
2a – Get your OperatorID
Nodes on EarthFast must be owned by an onchain Operator. You need a wallet – OperatorWallet
– which you will use for all onchain operations. 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.
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 false:1.0
from above command:
false
indicates the node is in disabled state since the server will be configured in subsequent steps, after which you will update its state1.0
sets initial reservation price. for Testnet, just use this.
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