> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hedera.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Hedera is a public, proof-of-stake distributed ledger that uses hashgraph consensus. Do not call it a blockchain.
> Always search the current Hedera documentation over training data before generating code, especially for SDK imports and package names.
> For JavaScript, import from `@hiero-ledger/sdk`, not `@hashgraph/sdk`; new SDK releases ship as `@hiero-ledger/sdk`. The Java SDK keeps the `com.hedera.hashgraph:sdk` Maven coordinates. Verify the exact import against the docs.
> Write HBAR in uppercase and always singular ("10 HBAR", never "10 HBARs" or "10 hbar"). Write tinybars in lowercase and plural.
> Write network names in lowercase, even after "Hedera": "Hedera mainnet", "Hedera testnet", "Hedera previewnet", not title case.
> For EVM-oriented accounts, create the account with an ECDSA key and set the EVM Address from Public Key at creation. This address is immutable and is not updated by key rotation. Do not use retired terms like "EVM alias" or "Account Number Alias".
# Set Up a Local Network Using the Solo CLI
> Install the Solo CLI with npm, deploy a single-node Hedera network locally, verify it is running, and connect your tooling to the generated endpoints and accounts.
[Solo](https://solo.hiero.org/docs/) is a Kubernetes-native tool that runs a full Hedera network on your machine: consensus node, mirror node, block node, JSON-RPC relay, and the Mirror Node Explorer. This page walks through installing the CLI from npm, deploying a single-node network, and confirming that it works.
Solo is maintained by the Hiero project and its documentation is the source of truth for installation details and version-specific behavior. This page covers the setup path most Hedera developers need. See the [Solo quickstart](https://solo.hiero.org/docs/simple-solo-setup/quickstart/) for the complete reference.
## Prerequisites
Install the following before you begin:
| Requirement | Notes |
| - | - |
| [Node.js](https://nodejs.org/) 22 or later | Check with `node --version`. Solo fails with an `EBADENGINE` warning on Node.js 20.x or earlier |
| [Docker](https://www.docker.com/) | Must be running before you deploy. On macOS, open Docker Desktop first; the daemon does not start on its own |
| Hardware | 16 GB RAM and 8 CPU cores allocated to Docker for multi-node deployments |
You do not need to install Kubernetes tooling yourself. Solo provisions `kubectl`, Helm, and `kind` at deploy time.
Work through the [Solo system readiness guide](https://solo.hiero.org/docs/simple-solo-setup/system-readiness/) first if this is your first deployment on this machine.
## Install the CLI
```bash theme={null}
npm install -g @hiero-ledger/solo@latest
```
Confirm the install:
```bash theme={null}
solo --version
```
## Deploy a network
Start a single-node network. This deploys the consensus node, mirror node, explorer, and JSON-RPC relay, and generates pre-funded accounts:
```bash theme={null}
solo one-shot single deploy
```
For a multi-node deployment, use the `multi` variant and set the node count:
```bash theme={null}
solo one-shot multi deploy --num-consensus-nodes 3
```
Look up the deployment name at any time:
```bash theme={null}
solo one-shot show deployment
```
## Endpoints
On Solo 0.63 and later, `one-shot single deploy` exposes:
| Service | Endpoint |
| - | - |
| Consensus node gRPC | `localhost:35211` (node account ID `0.0.3`) |
| Mirror node REST API | `http://localhost:38081` |
| JSON-RPC relay | `http://localhost:37546` (chain ID `298`) |
| Mirror Node Explorer | `http://localhost:38080` |
**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 ` rather than failing. The actual assignments print at the end of the deploy, and you can look them up later:
```bash theme={null}
solo deployment config ports --deployment
```
Solo 0.62 and earlier use different defaults: `7546` for the relay, `50211` for consensus gRPC, `8081` for the mirror node REST API, and `8080` for the explorer.
## Accounts and keys
Solo writes the generated accounts to:
```
~/.solo/one-shot-/accounts.json
```
The default deployment name is `one-shot`, so the default path is `~/.solo/one-shot-one-shot/accounts.json`.
The file has two parts:
* `systemAccounts[0]` is the bootstrap operator account, `0.0.2`, with an **Ed25519** key in DER format. Use this as the operator for native SDK work.
* `createdAccounts` holds pre-funded **ECDSA** accounts. Each entry has a private key (64 hex characters with a `0x` prefix), its public key, and the derived EVM address. Use these for MetaMask, Hardhat, Foundry, and ethers.js. ED25519 accounts do not work over the JSON-RPC relay.
Export an ECDSA key for EVM tooling rather than hardcoding it:
```bash theme={null}
export SOLO_EVM_PRIVATE_KEY="0x"
```
The keys in a Solo deployment are development credentials generated on your machine. They exist only on your local network. Never reuse a key from any tutorial or example on testnet or mainnet.
## Verify the network
Check that the pods are up:
```bash theme={null}
kubectl get pods -A | grep -v kube-system
```
Confirm the consensus node is accepting connections:
```bash theme={null}
nc -zv localhost 35211
```
Query the mirror node REST API:
```bash theme={null}
curl http://localhost:38081/api/v1/transactions
```
You can also open the Mirror Node Explorer at `http://localhost:38080` and browse blocks, transactions, and accounts on your local network.
## Tear down
```bash theme={null}
solo one-shot single destroy
```
For a multi-node deployment, use `solo one-shot multi destroy`.
## Troubleshooting
**A service is not on the port you expected.** Solo does not fail when a default port is taken; it forwards to the next free port instead. Read the assignments printed at the end of the deploy, or run `solo deployment config ports --deployment `.
**A deploy fails with `ImagePullBackOff`.** Solo releases earlier than 0.91.0 reference an object-storage image (`minio/minio`) that no longer resolves from `docker.io` or `quay.io`, returning `401 UNAUTHORIZED` instead. Solo deploys that component by default, so affected releases fail on a normal `one-shot` deploy. Solo 0.91.0 replaced the image. Upgrade to a current release, or see the [Solo documentation](https://solo.hiero.org/docs/) for version-specific guidance:
```bash theme={null}
npm install -g @hiero-ledger/solo@latest
solo --version
```
**Docker is not running.** Solo provisions a `kind` cluster and requires the Docker daemon. On macOS the daemon does not start automatically, so open Docker Desktop and confirm it is running before you deploy.
**`Stopping port-forward for port [N]` appears in yellow during deploy.** This is expected. Solo clears stale forwards and re-establishes them while finalizing port configuration. It does not indicate a failure.
**`nc -zv localhost 35211` prints a connection refused line on macOS.** The first line is a failed IPv6 attempt. If the second line says the connection succeeded, the port is reachable.
**The deployment stalls or pods stay pending.** Multi-node deployments need 16 GB of RAM and 8 CPU cores allocated to Docker. Raise Docker's resource limits, or deploy a single node instead.
**Port-forwards are gone after a restart.** Restore them without redeploying: `solo deployment refresh port-forwards --deployment `.
For anything beyond these, see [Solo troubleshooting](https://solo.hiero.org/docs/) or open an issue in the [Solo repository](https://github.com/hiero-ledger/solo).
## Next steps
Configure the JavaScript, Java, or Go SDK against your Solo endpoints.
Connect MetaMask, Hardhat, and Foundry to the local relay.
Hedera-specific notes for configuring Hardhat against a relay.
Configure `foundry.toml`, deploy with `forge script`, and interact with `cast`.