Managing Your Network

Overview

This guide covers day-to-day management operations for a running Solo network, including starting, stopping, and restarting nodes, capturing logs, and troubleshooting.

Prerequisites

Before proceeding, ensure you have completed the following:

• System Readiness - your local environment meets all hardware and software requirements.
• Quickstart - you have a running Solo network deployed using solo one-shot single deploy.

Note: If you need to upgrade an existing Solo network, see Upgrade Your Network.

solo one-shot show deployment

Expected output — the deployment name you passed to solo one-shot single deploy, or the default one-shot if you did not specify --deployment:

Deployment Name: one-shot (default)

Most management commands require your deployment name. Find it with solo one-shot show deployment — see Capture your deployment name. It defaults to one-shot unless you passed --deployment. Use it as <deployment-name> in all commands on this page.

Stopping and Starting Nodes

Important: The solo consensus node stop/start/restart commands act on consensus nodes only. They do not stop the mirror node, Hiero Explorer, JSON-RPC relay, block node, or the shared services (PostgreSQL, Redis, MinIO) - those keep running. Solo has no stop/start command for the non-consensus components (their lifecycle is add/destroy). To pause the whole network without deleting any pods, see Stop the entire network.

Stop consensus nodes

Pause the consensus node(s) without destroying the deployment:

solo consensus node stop --deployment <deployment-name>

Start consensus nodes

Bring stopped consensus node(s) back online:

solo consensus node start --deployment <deployment-name>

Restart consensus nodes

Stop and start all consensus nodes in a single operation:

solo consensus node restart --deployment <deployment-name>

To verify pod status after any of the above commands, see Verify the network in the Quickstart guide.

Stop the entire network

To pause the entire network while preserving all state — for example, to free up memory while working on other tasks — stop the Kind cluster’s Docker container. This suspends every pod without deleting them, so all in-memory and on-disk state (including consensus node state) is preserved.

Find the Kind cluster container name and stop it:

docker ps --filter name=solo-cluster --format '{{.Names}}'
docker stop <container-name>

The container name is typically solo-cluster-control-plane. On macOS and Windows you can also do this from the Docker Desktop dashboard: find the container and click Stop.

To bring the network back online, start the container and restore port-forwards:

docker start <container-name>
solo deployment refresh port-forwards --deployment <deployment-name>

Warning: Do not use kubectl scale --replicas=0 to stop the entire network. Scaling pods to zero deletes them, which wipes consensus node in-pod state (emptyDir volumes). The consensus node will fail to restart correctly after scaling back up. Use docker stop/docker start instead.

Note: To remove the network entirely (cluster, volumes, and configuration), use solo one-shot single destroy — see the Cleanup guide.

Verify Network is Working

To confirm your Hedera network is fully operational, create a test account using the Ledger account creation command:

solo ledger account create --deployment <deployment-name>

Expected output:

 *** new account created ***
-------------------------------------------------------------------------------
{
  "accountId": "0.0.1001",
  "publicKey": "302a300506032b6570032100439379b330f3b57b5deffda196c7c0c3387f3330a838c021954303e260606f24",
  "balance": 100
}

Once the account is created, verify it in the web-based Explorer UI:

1. Open your browser to http://localhost:38080
2. In the search bar, enter the account ID (e.g., 0.0.1001)
3. View the account details, balance, and transaction history

This confirms that:

• The network is processing transactions
• The consensus node is responding correctly
• The mirror node is indexing transactions
• The explorer is displaying data properly

Reset the ledger to genesis

To return a running deployment to a clean genesis state without tearing it down and redeploying, reset the ledger system. This clears the saved consensus state and ledger-related secrets, returning the ledger to genesis - with no accounts, files, or balances beyond the genesis defaults:

solo ledger system reset --deployment <deployment-name>

solo ledger system reset is the counterpart to solo ledger system init (which initializes a new deployment). Use it when you want a fresh ledger - for example, to rerun a scenario from a known starting point - while keeping the same Kind cluster and deployment.

Note: This discards on-ledger state created since genesis and cannot be undone. It does not delete the cluster or deployment - to remove those entirely, use solo one-shot single destroy (see the Cleanup guide).

Viewing Logs

To capture logs and diagnostic information for your deployment:

solo deployment diagnostics all --deployment <deployment-name>

Logs are saved to ~/.solo/logs/ (on native Windows, $env:USERPROFILE\.solo\logs\).

Expected output:

******************************* Solo *********************************************
Version : 0.59.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : deployment diagnostics all --deployment <deployment-name>
**********************************************************************************

✔ Initialize [0.3s]
✔ Get consensus node logs and configs [15s]
✔ Get Helm chart values from all releases [2s]
✔ Downloaded logs from 10 Hiero component pods [1s]
✔ Get node states [10s]

Configurations and logs saved to /Users/<username>/.solo/logs
Log zip file network-node1-0-log-config.zip downloaded to /Users/<username>/.solo/logs/<deployment-name>
Helm chart values saved to /Users/<username>/.solo/logs/helm-chart-values

You can also retrieve logs for a specific pod directly using kubectl:

kubectl logs -n <namespace> <pod-name>

Important: Solo deploys each network into a Kubernetes namespace. For one-shot deployments, the namespace defaults to one-shot (matching the default deployment name). You can override it by passing --namespace to solo one-shot single deploy.

To find your deployment namespace, use any of:

# Look up the namespace Solo recorded for this deployment
solo deployment config info --deployment <deployment-name>

# Or list all namespaces and pick the one matching your deployment
kubectl get ns

# Or inspect pods and use the NAMESPACE column
kubectl get pods -A | grep -v kube-system

For one-shot deployments the namespace matches the deployment name, which defaults to one-shot unless you passed --deployment (retrieve it with solo one-shot show deployment).

Replace <namespace> and <pod-name> with the values from your deployment.