When to use Solonet
Solonet gives node operators a fast feedback loop without depending on a public network:- Practice node operations: rehearse upgrades, recoveries, and configuration changes against a disposable local chain.
- Test validator workflows: run
staking-clioperations against your own validator without spending testnet MON or waiting for finality. - Develop tooling: validate scripts, monitoring dashboards, or block-delivery integrations against a chain whose state you fully control.
- Reproduce issues: spin up a multi-validator topology to investigate consensus or block-sync edge cases.
anvil --monad starts faster and is usually sufficient. Reach for Solonet when you need full node behavior: consensus, staking, archive RPC, or production-like timing.
Prerequisites
- Linux x86_64 host, or macOS (Apple Silicon)
- 4+ CPU cores and 16 GB RAM
- Docker on Linux; Homebrew on macOS (used to install the Lima + Colima setup below)
macOS setup (Apple Silicon)
Solonet’s containers are x86_64 Linux, so on Apple Silicon you need a small Linux VM to host Docker. Lima and Colima handle this:Architecture: x86_64):
docker compose command below works identically on macOS and Linux.
To tear everything down later:
Quick start
Clone the repository and bring up a single-validator network:- RPC:
http://localhost:8080 - WebSocket:
ws://localhost:8081 - CORS RPC:
http://localhost:8082/rpc/ - Dashboard:
http://localhost:8082
Other network configurations
Multi-validator network:Included tooling
The Solonet containers come with the tools most commonly used for node operations:forgeandcast(Foundry)staking-clifor validator staking operationsmonad-statusfor inspecting node health
Notes
- Solonet boots a fresh chain from genesis. State and validator sets are independent of testnet and mainnet, so it is suited for verifying your operational processes against a chain you control.
- Because the chain is local, finality is fast and gas is effectively free. Realistic latency or load tests still require a deployed network.

