Skip to main content
Monad is a high-throughput, EVM-compatible chain. Every Monad node runs three roles — more than any other chain Novacula manages — deployed and managed together:
  • monad-bft — the BFT consensus role.
  • monad-execution — the execution-layer state engine.
  • monad-rpc — the Ethereum-compatible JSON-RPC / WebSocket front-end.
Monad runs only on a bare-metal executor (Agent). It is not available on the Kubernetes (Operator) backend — the host needs hugepages, a dedicated monad user, and a metrics collector that the Agent sets up for you during install. To provision a host, see Provision on bare metal. To deploy a node, open Deploy node, pick Monad, then choose a network. The three roles are deployed as one unit on a single version — you pick one version and all three roles use it. The wizard offers exactly the networks and versions your target executor declares; if a version isn’t listed, that executor can’t run it.

Networks and resources

Network
mainnet
testnet
Defaults are pre-filled in the deploy wizard. A Monad node is heavy, and the execution role dominates. CPU and RAM are sized per role; disk is one shared data volume — the three roles’ defaults are summed into a single total you size in one input. Lower the defaults only if you know your workload fits.
Rolemainnet CPU / RAMtestnet CPU / RAM
monad-bft4 cores / 12 GiB4 cores / 8 GiB
monad-execution10 cores / 18 GiB4 cores / 4 GiB
monad-rpc2 cores / 4 GiB1 core / 2 GiB
The shared data volume defaults to 2510 GiB on mainnet (500 + 2000 + 10) and 605 GiB on testnet (100 + 500 + 5); the execution role drives most of it. Size it correctly — it matters more than for any other chain.

Clients

All three roles use a single client version, picked once in the wizard. The roles are versioned in lock-step — there is no “upgrade execution without consensus” path.
RoleClientVersions
consensusmonad-bft0.14.4, 0.14.3, 0.14.2, 0.14.1
executionmonad-execution0.14.4, 0.14.3, 0.14.2, 0.14.1
rpcmonad-rpc0.14.4, 0.14.3, 0.14.2, 0.14.1

Ports

NamePortRoleNotes
Consensus P2P (TCP / UDP)8000monad-bft
Peer auth8001monad-bft
JSON-RPC (HTTP)8080monad-rpc
WebSocket RPC8081monad-rpcEnabled by default; set WS_PORT to change
Metrics (Prometheus)8889metrics collector
Only monad-rpc serves HTTP; the consensus and execution roles have no public endpoint and are observed through metrics.

Configuration overrides

Set overrides at deploy time in the wizard’s config step, or later from a node’s detail page on the Configuration tab. For the full editing flow, see Edit node configuration. The toggles you’ll commonly set:
KeyTypeDescription
BENEFICIARYstringReward beneficiary. Full nodes may use the burn address
ENABLE_WEBSOCKETbooleanEnable WebSocket RPC (default true)
WS_PORTnumberWebSocket port when ENABLE_WEBSOCKET=true (default 8081)
ENABLE_TRACE_CALLSbooleanEnable execution-layer call tracing (default false)
Settings the platform owns — chain selection, ports, identity paths, and the metrics endpoint — are protected: typing one flags the row as managed by Novacula and blocks the save until you remove it.

Monitoring

The node page surfaces per-role status, block height, peers, sync progress, disk usage, and Monad-specific consensus and sync counters. See Node monitoring.

What you can build

  • Public RPC node — accept the defaults and expose :8080 (HTTP) and :8081 (WebSocket) behind your own proxy.
  • Test-network sandbox — deploy a testnet node first; it’s far cheaper than mainnet and lets you rehearse the bare-metal setup before committing mainnet-sized storage.