Skip to main content
Hiero Local Node is deprecatedHiero Local Node reached the end of its deprecation period in September 2026. It is no longer supported and receives no further updates or bug fixes. Existing setups that pinned a consensus node release earlier than Release 74 may still run, but nothing about them is maintained.Solo is the supported replacement for local development and CI. Read the announcement for the full timeline.
A local network gives you a complete Hedera stack on your own machine. You get instant feedback, no faucet or portal account, no testnet rate limits, and no periodic resets. It is also the fastest way to run integration tests in CI.
If you are testing EVM contracts against state that already exists on testnet or mainnet, fork testing may suit you better than a fresh local network. Forking with Hardhat or Foundry lets you run against deployed contracts and Hedera System Contracts without redeploying them locally.
Solo is the recommended way to run that network. It is a Kubernetes-native tool that deploys the same components you find on mainnet and testnet, so you develop against the same services and APIs you will use in production.

​
What Solo runs

​
Start a local network

Solo requires Docker, Node.js 22 or later, and npm 9.8.1 or later. It provisions kubectl, Helm, and kind for you at deploy time, so you do not need to install those yourself. On macOS, Docker Desktop must be running before you deploy, because the daemon does not start on its own. Review the Solo system readiness guide for the full requirements.
The first deploy is slower while Solo pulls and caches container images. Later deploys reuse the cache. To run more than one consensus node, for testing consensus scenarios, deploy the multi-node variant instead. This needs 16 GB of memory and 8 CPU cores allocated to Docker:
Tear the network down when you are finished:
Multi-node deployments are removed with solo one-shot multi destroy.

​
Default endpoints

The one-shot single deploy command exposes the following endpoints on Solo 0.63 and later: Generated accounts and their keys are written to ~/.solo/one-shot-<deployment-name>/accounts.json. The default deployment name is one-shot, so the default path is ~/.solo/one-shot-one-shot/accounts.json. Run solo one-shot show deployment to look up your deployment name.
These are defaults, not guarantees. Solo reaches these services through kubectl port-forward. If a port is already taken, Solo picks the next free one and logs Using available port <port>. The actual assignments print at the end of solo one-shot single deploy, and you can look them up later with:
Port assignments also changed in Solo 0.63. Deployments on 0.62 or earlier use 7546 for the relay, 50211 for consensus gRPC, 8081 for the mirror node REST API, and 8080 for the explorer.

​
Next steps

Set up the Solo CLI

Install Solo with npm, start a network, and verify it is running.

Point an SDK at your network

Configure the JavaScript, Java, or Go SDK against local endpoints.

Solo quickstart

The full installation and deployment reference maintained by the Solo team.

Using Solo with EVM tools

Connect MetaMask, Hardhat, and Foundry to a local Solo network.

Fork testing

Test EVM contracts against existing testnet or mainnet state instead of a fresh network.