Skip to main content

Running a Node

Four roles, and picking the right one is most of the decision. They differ in what they serve, not in the software — every role runs the same orbinum-node image.

Which node do you want?​

RoleWhat it doesPublic RPCRuns consensus
Development nodeA chain on your laptop, instant seal, pre-funded accountslocal onlyno
Public RPCServes wallets and dApps over HTTPS/WSS, acts as a bootnodeyes, behind Cloudflareno
Indexer archiveFull history for an explorer or indexer, on the same hostno — loopback onlyno
ValidatorProduces and finalizes blocks, relays private transactionsneveryes

If you are evaluating Orbinum, start with the development node — it needs no credentials and no open ports. If you want to support the network, the validator path is its own section.

Sizing​

This table is the authority for every role. No other page states hardware numbers.

RoleCPURAMStorage
Development node2 cores4 GB40 GB SSD
Public RPC4 cores8 GB500 GB NVMe
Indexer archive4 cores8 GB2+ TB NVMe
Validator4 dedicated cores8 GB200 GB NVMe

Two of these deserve a sentence:

The indexer archive is a storage decision, not a compute one. Archive mode keeps every historical state, and that grows without bound. It is the only role where the disk is the constraint.

A validator wants dedicated cores, not more of them. It verifies ZK proofs inside block execution, so a burstable or shared-vCPU instance throttles exactly when a proof-heavy block arrives. See Validator Requirements for why that matters more than the core count.

Telemetry​

Every node reports to telemetry.orbinum.network by default — block height, finalized height, peer count, transaction pool, propagation time, version and approximate location. Your node appears within a few seconds of starting, under the name in VALIDATOR_NAME / RPC_NAME.

It is an outbound connection: no port to open, no firewall rule, and it works on a node whose RPC is loopback-only.

Validators must stay on telemetry

For RPC and development nodes telemetry is optional. For validators it is a requirement, not a default you may turn off: it is how the team confirms your node is synced and authoring before approving you, and how anyone can see the set is healthy afterwards. A validator that disappears from the dashboard is indistinguishable from one that is down.

Validators also report at level 1, not 0 — level 1 sends afg.authority_set, the only message carrying your validator address, which is what fills the Address column. Level 0 leaves it blank.

The value is already set in node-deploy's .env.example:

TELEMETRY_URL=--telemetry-url "wss://telemetry.orbinum.io/submit/ 1"   # validators
TELEMETRY_URL=--telemetry-url "wss://telemetry.orbinum.io/submit/ 0"   # RPC and archive nodes

Three details in that string are load-bearing:

  • The quotes stay. The node parses "<url> <level>" as a single argument. Without them the level is read as a separate flag and startup fails.
  • The trailing slash stays. /submit without it does not upgrade.
  • The digit is the verbosity level, not a placeholder.

To opt out on a non-validator, set the variable empty. That genuinely silences the node — the chain spec carries no telemetry endpoint of its own, so there is no fallback destination.

Editing this needs a recreate, not a restart

A container's command line is fixed when it is created, so docker compose restart brings the node back with its old arguments and the edit appears to do nothing:

docker compose up -d --force-recreate orbinum-validator

To see what a running node actually received:

docker inspect orbinum-validator --format '{{join .Config.Cmd " "}}'

What every role needs​

  • Docker with the Compose plugin — the only dependency. See Installation.
  • A GHCR token to pull the image, which is private.
  • TCP 30333 reachable for anything that joins the testnet. A development node needs nothing open.

The compose files, the chain spec and the .env templates all live in the node-deploy repository, one directory per <network>/<role>. You pull a pre-built image; nobody compiles from source.

Next Steps​