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 -sa
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. 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