Managing Your Network

Overview

This guide covers day-to-day management operations for a running Solo network, including starting, stopping, and restarting nodes, resetting the ledger to genesis, 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, 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/start vs. ledger reset: stop/start/restart pause and resume consensus nodes without touching ledger state — accounts, balances, and transaction history are preserved. To return the ledger to genesis and discard all on-ledger state, see Reset the ledger to genesis.

Stop the entire network

Solo does not provide a single command to stop every component. To pause the entire network - consensus, mirror, Explorer, relay, block node, and shared services - while preserving its data, scale every workload in the deployment namespace to zero with kubectl. For one-shot deployments the namespace matches your deployment name.

kubectl scale deployment  --all --replicas=0 -n <namespace>
kubectl scale statefulset --all --replicas=0 -n <namespace>

This stops all pods but keeps the Kind cluster, persistent volumes, and configuration intact. To bring the network back online, scale the workloads back up (Solo’s default deployments run a single replica each):

kubectl scale statefulset --all --replicas=1 -n <namespace>
kubectl scale deployment  --all --replicas=1 -n <namespace>

Note: Scaling to zero pauses the network without deleting it. 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.