Simple Solo Setup

• 1: System Readiness
• 2: Quickstart
• 3: Managing Your Network
• 4: Upgrade Your Network
• 5: Upgrading an existing Solo installation
• 6: Cleanup

1 - System Readiness

Overview

Before you deploy a local Hiero test network with solo one-shot single deploy, your machine must meet specific hardware, operating system, and tooling requirements.

This page covers the minimum and recommended memory, CPU, and storage; supported platforms (macOS, Linux, and Windows — natively with PowerShell, or via WSL2); and the required versions of Docker/Podman, Node.js, and Kubernetes tooling.

By the end of this page, your container runtime will be installed and your platform environment configured. Then proceed to Quickstart to install Solo and deploy.

Hardware Requirements

Solo’s resource requirements depend on your deployment size:

Note: If you are using Docker Desktop, ensure the resource limits under Settings → Resources are set to at least these values - Docker caps usage independently of your machine’s total available memory.

Software Requirements

Solo sets up most of the tools it needs for you. The table below shows what each install method provides, what Solo provisions automatically, and what you must install yourself.

Note: Solo’s provisioned copies of kubectl, Kind, and Helm live in ~/.solo/bin, which is not necessarily on your PATH. If you want to run kubectl, kind, or helm commands yourself (some guides do), install kubectl, Kind, and Helm on your PATH separately.

Windows (WSL2) prerequisite

Kind (which Solo provisions automatically) requires WSL2 to be enabled on Windows, but you do not need a WSL2 Linux distro installed — only the WSL2 feature itself. Enable it with:

wsl --install --no-distribution

WSL2 requires hardware virtualization and the Virtual Machine Platform Windows feature. If virtualization is unavailable (for example, wsl --install reports HCS_E_HYPERV_NOT_INSTALLED), use the native Windows (PowerShell) path instead, which does not require WSL2.

Docker

Solo requires Docker Desktop (macOS, Windows) or Docker Engine / Podman (Linux) with sufficient resources:

• Memory: at least 12 GB available for containers.
• CPU: at least 6 cores available for containers.

Configure Resources by Platform

macOS and Windows (Docker Desktop)

To allocate the required resources in Docker Desktop:

1. Open Docker Desktop.

2. Go to Settings > Resources > Memory and set it to at least 12 GB.

3. Go to Settings > Resources > CPU and set it to at least 6 cores.

4. Click Apply & Restart.

   

Note: If Docker Desktop does not have enough memory or CPU allocated, the one-shot deployment will fail or produce unhealthy pods.

Linux

Docker Engine on Linux uses system memory directly and does not have a resource allocation interface like Docker Desktop.

Resource Check:

• Ensure your machine has at least 12 GB of free RAM available before running solo one-shot single deploy.
• Check available memory with: free -h
• If you have insufficient RAM, the deployment may fail or pods may become unhealthy.

Podman on Linux: If using Podman instead of Docker Engine, ensure your system has at least 12 GB of free RAM available.

Platform Setup

Solo supports macOS, Linux, and Windows (natively with PowerShell, or via WSL2). Select your platform below to install the required container runtime and configure your environment, before proceeding to Quickstart:

⚠️ Homebrew support is being deprecated. Solo will stop publishing updates to Homebrew after August 31, 2026. New users should install via npm. Existing Homebrew users should migrate before August 31.

• macOS
• Linux
• Windows
• Windows (WSL2)

Optional Tools

The following tools are not required but are recommended for monitoring and managing your local network:

• k9s (>= v0.27.4): A terminal-based UI for managing Kubernetes clusters. Install it with:

  brew install k9s
  

  Run k9s to launch the cluster viewer.

Version Compatibility Reference

To see a list of legacy releases, please check the legacy versions documentation page.

Troubleshooting Installation

If you experience issues installing or upgrading Solo - for example, conflicts with a previous installation - clean up your environment and reinstall:

• To remove a legacy npm install or perform a full environment reset (delete Solo-managed Kind clusters and your ~/.solo directory), see the Cleanup guide.

• To upgrade an existing install, install a specific version, or switch between Homebrew and npm, see Upgrading an existing Solo installation.

• macOS “mounts denied” error on Apple Silicon: If solo one-shot single deploy fails immediately with a “mounts denied” or “path is not shared from the host” error, add /opt/homebrew to Docker Desktop’s File Sharing list: Settings → Resources → File Sharing → + → add /opt/homebrew → Apply & Restart. This can occur on Apple Silicon Macs (M1/M2/M3/M4) when Homebrew’s install path (/opt/homebrew) is not included in Docker Desktop’s shared directories. Intel Mac users (Homebrew path /usr/local) are not affected.

• WSL2 fails to install (for example, wsl --install reports HCS_E_HYPERV_NOT_INSTALLED): WSL2 requires hardware virtualization and the Virtual Machine Platform feature. See Microsoft’s Install WSL guide, or use the native Windows (PowerShell) path, which does not require WSL2.

• First deploy fails with a PostgreSQL startup timeout: If solo one-shot single deploy fails during mirror node setup with a PostgreSQL startup timeout, this is a known intermittent issue on first deploy. Destroy the deployment and retry:

  solo one-shot single destroy
  solo one-shot single deploy
  

2 - Quickstart

Overview

Solo Quickstart provides a single, one-shot command path to deploy a running Hiero test network using the Solo CLI tool. This guide covers installing Solo, running the one-shot deployment, verifying the network, and accessing local service endpoints.

Note: This guide assumes basic familiarity with command-line interfaces and Docker.

Prerequisites

Before you begin, ensure you have completed the following:

• System Readiness:
  • Prepare your local environment (Docker, Kind, Kubernetes, and related tooling) by following the System Readiness guide.

macOS prerequisite: Docker Desktop must be installed and open before running solo one-shot single deploy. The Docker daemon is not started automatically on macOS, so confirm Docker Desktop is running from your menu bar before you begin.

Apple Silicon: If solo one-shot single deploy fails with a “mounts denied” error, see Troubleshooting Installation.

Windows (PowerShell): Complete the System Readiness Windows tab first, then run the commands on this page from a PowerShell terminal. The solo and kubectl commands are identical in PowerShell; only shell-specific commands (pipes, port checks, and ~/.solo paths) differ, and those show a PowerShell tab.

Note: Quickstart only covers what you need to run solo one-shot single deploy and verify that the network is working. Detailed version requirements, OS-specific notes, and optional tools are documented in the System Readiness.

Step 1: Install Solo CLI

Install the latest Solo CLI globally using one of the following methods:

• npm (recommended for all platforms):

  npm install -g @hiero-ledger/solo@latest
  

  Note: npm requires Node.js >= 22.0.0 to already be present (check with node --version; upgrade via nvm or nodejs.org if needed — Solo will fail with an EBADENGINE warning on Node.js 20.x or earlier). Solo provisions kubectl, Helm, and Kind automatically at deploy time.

• Homebrew (deprecated — macOS/Linux/WSL2 only):

  brew install hiero-ledger/tools/solo
  

  ⚠️ Homebrew support is being deprecated. Solo will stop publishing updates to Homebrew after August 31, 2026. New users should install via npm. Existing Homebrew users should migrate before August 31.

Verify the installation

Confirm that Solo is installed and available on your PATH:

solo --version

Expected output (version may be different):

******************************* Solo *********************************************
Version			: 0.84.0
**********************************************************************************

If you see a similar banner with a valid Solo version, your installation is successful.

Step 2: Deploy a local network (one-shot)

Use the one-shot command to create and configure a fully functional local Hiero network:

solo one-shot single deploy

This command performs the following actions:

• Creates or connects to a local Kubernetes cluster using Kind.
• Deploys the Solo network components.
• Sets up and funds default test accounts.
• Exposes gRPC and JSON-RPC endpoints for client access.

⏱ First-run time: solo one-shot single deploy typically takes 3–5 minutes when container images are already cached locally, or 10–20 minutes on the very first run while Solo pulls images over the network (longer on slower connections). Long pauses with no visible output change are normal — the deploy is still running. Later deployments reuse the local image cache and complete faster. See Solo Image Cache.

Note: During deployment you may see Stopping port-forward for port [N] printed in yellow. This is expected - as it sets up the network, Solo stops and re-establishes port-forwards to finalize the port configuration (clearing stale forwards and migrating ports as needed). It does not indicate a failure.

PostgreSQL startup timeout: If the first deployment fails during mirror node setup with a PostgreSQL startup timeout, destroy the deployment and retry — this is a known intermittent issue on first deploy:

solo one-shot single destroy
solo one-shot single deploy

What gets deployed

solo one-shot multi deploy --num-consensus-nodes 3

Capture your deployment name

solo one-shot single deploy (and multi deploy) assigns a unique name to each deployment. Subsequent Solo commands and SDK guides reference it as <your-deployment-name> — substitute your actual value when you run them.

Retrieve the most recent deployment’s name with:

solo one-shot show deployment

The output includes a Deployment Name: line - use that value as <deployment-name> in other commands.

Verify the network

After the one-shot deployment completes, verify that the Kubernetes workloads are healthy.

You can monitor the Kubernetes workloads with standard tools:

• Bash
• PowerShell

kubectl get pods -A | grep -v kube-system

kubectl get pods -A | Select-String -Pattern 'kube-system' -NotMatch

Confirm that all Solo-related pods are in a Running or Completed state.

Tip: The Solo testing team recommends k9s for managing Kubernetes clusters. It provides a terminal-based UI that makes it easy to view pods, logs, and cluster status. Install it with brew install k9s and run k9s to launch.

Step 3: Access your local network

After the one-shot deployment completes and all pods are running, Solo sets up port-forwards so you can reach your local services. For the full endpoint reference — default ports for Solo 0.63+ and Solo 0.62 and earlier, verification commands, and port lookup — see Service Endpoints.

Open http://localhost:38080 in your browser to explore your network.

Step 4: Tear down your network

When you are finished, destroy the network to free up resources:

solo one-shot single destroy

For a full teardown procedure including failure recovery, see the Cleanup guide. For granular stop/start and management options, see Managing Your Network.

Next Steps

With your network running, connect your application or explore Solo further:

• Using Solo with Hiero SDKs — Submit transactions using the JavaScript, Java, or Go SDK.
• Using Solo with EVM Tools — Connect MetaMask, Hardhat, Foundry, or ethers.js to your local network.
• Managing Your Network — Stop, start, and reset nodes without redeploying.
• Service Endpoints — Quick reference for all default ports and connection details.

3 - 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.

4 - Upgrade Your Network

Overview

This guide explains how to upgrade an existing local Solo network deployment to a newer Hiero version. It is intended for networks that were already deployed with solo one-shot single deploy.

Note: If you just completed Quickstart with the latest Solo release, you do not need to upgrade unless you are intentionally moving an older deployment to a newer version.

Prerequisites

Before upgrading, ensure you have completed the following:

• Quickstart - you have already deployed a running Solo network using solo one-shot single deploy.
• System Readiness - your local environment meets Solo requirements.
• A currently running Solo deployment to upgrade.

Step 1: Find your deployment name

The default for one-shot deployments is one-shot. If you used a different name, find it with solo one-shot show deployment (see Capture your deployment name). Use that value as <deployment-name> in the upgrade command.

Step 2: Upgrade the network

Run the following command to upgrade an existing Solo network deployment to a newer Hiero version:

solo consensus network upgrade --deployment <deployment-name> --upgrade-version <version>

Replace <version> with the target Hiero version, for example v0.59.0.

Important: This command is only for networks already deployed with Solo. Do not run it immediately after Quickstart unless you are moving an older deployment to a newer version.

Step 3: Verify the upgrade

After upgrading, confirm the network is healthy by checking pod status:

kubectl get pods -n <namespace>

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).

5 - Upgrading an existing Solo installation

Overview

If you already have Solo installed, upgrade to the latest release using the same package manager you originally installed with. This page covers the Homebrew and npm upgrade paths, switching between them, and a clean-reinstall recipe for when an upgrade leaves Solo in a broken state.

⚠️ Homebrew support is being deprecated. Solo will stop publishing updates to Homebrew after August 31, 2026. Existing Homebrew users should migrate to npm before August 31. See Switching between Homebrew and npm.

Tip: Check your current version first with solo --version, and compare it against the latest release on the Solo releases page.

Upgrade a Homebrew install

If you installed Solo with brew install hiero-ledger/tools/solo, update Homebrew’s formula list and upgrade:

brew update
brew upgrade hiero-ledger/tools/solo

brew update refreshes Homebrew’s formulae; brew upgrade then installs the latest Solo (and Node.js, its only Homebrew dependency). Verify the new version:

solo --version

Upgrade an npm install

If you installed Solo with npm, re-run the global install with the @latest tag to move to the newest release:

npm install -g @hiero-ledger/solo@latest

Note: Unlike the Homebrew formula, npm does not install Node.js - make sure Node.js is present before upgrading. (Solo provisions kubectl, Helm, and Kind automatically at deploy time regardless of install method.) After a major-version upgrade, re-check the required tool versions in System Readiness.

Resolving an EEXIST package-name conflict

Solo is published to npm under two package names - @hiero-ledger/solo and @hashgraph/solo - that are mirrors of the same tool. Both install the same solo command-line binary, so only one can be globally installed at a time. If you already installed Solo under one name and then install it under the other, npm refuses to overwrite the existing binary and the install fails with EEXIST:

npm error code EEXIST
npm error path /Users/user/.nvm/versions/node/v22.14.0/bin/solo
npm error EEXIST: file already exists
npm error File exists: /Users/user/.nvm/versions/node/v22.14.0/bin/solo
npm error Remove the existing file and try again, or run npm with --force to overwrite files recklessly.

This is expected npm behavior - npm will not overwrite a binary owned by a different package name. To resolve it, uninstall the other package first, then install the one you want:

# Switching to the @hiero-ledger namespace
npm uninstall -g @hashgraph/solo
npm install -g @hiero-ledger/solo@latest

Note: If you installed under @hiero-ledger/solo and want to move to @hashgraph/solo, swap the names in the commands above.

If the install still reports EEXIST after uninstalling - for example because an orphaned solo binary was left behind - remove the leftover binary and reinstall:

rm "$(which solo)"
npm install -g @hiero-ledger/solo@latest

Tip: To remove every npm copy of Solo regardless of namespace, see Clean up legacy npm installations.

Install a specific version

To install a specific (non-latest) Solo release - for example, to reproduce a bug, run a regression test, or pin a version across a team - use a versioned Homebrew formula or npm tag instead of latest.

Note: A versioned brew formula or npm tag pins Solo to that release - it will not move when you run brew upgrade or npm update. To change versions later (including returning to the latest release, or downgrading), switching in place is not supported: uninstall Solo first (brew uninstall hiero-ledger/tools/solo, or npm uninstall -g @hiero-ledger/solo), then run the versioned install command below for the version you want. This keeps your ~/.solo data - only a Clean reinstall removes it. If you are switching package managers, see also Switching between Homebrew and npm.

• Homebrew (deprecated)
• npm

brew install hiero-ledger/tools/solo@0.76.0

npm install -g @hiero-ledger/solo@0.76.0

Note: On Solo v0.74.0 and later, a global install - including a pinned version - automatically pre-pulls that version’s container images into the image cache (~/.solo/cache/images/), which can take a few minutes and several GB on first run. Set SOLO_NO_CACHE=true (npm) or HOMEBREW_NO_SOLO_CACHE (Homebrew) to skip it.

Confirm the installed version:

solo --version

Tip: Installing a versioned formula or npm tag pins Solo to that release - it will not move when you run brew upgrade or npm update. To return to the latest release, follow Upgrade a Homebrew install or Upgrade an npm install above. If you hit a “two solo binaries on PATH” conflict when switching, remove the other install first (see Switching between Homebrew and npm).

Switching between Homebrew and npm

To migrate from Homebrew to npm, remove the Homebrew copy first so you do not end up with two solo binaries on your PATH:

# Remove the Homebrew copy before installing via npm
brew uninstall hiero-ledger/tools/solo

Then install via npm following the steps in System Readiness.

Clean reinstall

If an upgrade leaves Solo in a broken state - for example, conflicts from an older install or a partially migrated ~/.solo - remove Solo and its configuration, then reinstall.

Warning: This deletes your Solo home directory (~/.solo), including the image cache, cached configuration, and logs. The reinstall step below re-pulls the image cache (a few minutes, several GB) on Solo v0.74.0 and later. Destroy any running deployments first with solo one-shot single destroy - see the Cleanup guide.

• Homebrew (deprecated)
• npm

brew uninstall hiero-ledger/tools/solo
rm -rf ~/.solo
brew install hiero-ledger/tools/solo

npm uninstall -g @hiero-ledger/solo
rm -rf ~/.solo
npm install -g @hiero-ledger/solo@latest

Confirm the reinstall:

solo --version

For additional cleanup options - removing a legacy npm install, Solo-managed Kind clusters, and other artifacts - see the Cleanup guide.

6 - Cleanup

Overview

This guide covers how to tear down a Solo network deployment, understand resource usage, and perform a full reset when needed.

Prerequisites

Before proceeding, ensure you have completed the following:

• Quickstart — you have a running Solo network deployed using solo one-shot single deploy.

Destroying Your Network

Important: Always destroy your network before deploying a new one to avoid conflicts and errors.

To remove your Solo network:

solo one-shot single destroy

For multi-node one-shot deployments, use:

solo one-shot multi destroy

This command performs the following actions:

• Uninstalls all component Helm releases (consensus, mirror, relay, explorer).
• Removes the Solo cluster chart and disconnects the cluster reference.
• Deletes the deployment from Solo’s local configuration and clears the cache.
• Does NOT delete the Kind cluster - the cluster persists after destroy.

Failure modes and rerunning destroy

If solo one-shot single destroy fails part-way through (for example, due to an earlier deploy error), some resources may remain:

• The Solo namespace or one or more PVCs may not be deleted, which can leave Docker volumes appearing as “in use”.
• The destroy commands are designed to be idempotent, so you can safely rerun solo one-shot single destroy to complete cleanup.

If rerunning destroy does not release the resources, use the Full Reset procedure below to force a clean state.

Remove the Kind cluster

solo one-shot single destroy intentionally leaves the Kind cluster in Docker so you can redeploy quickly. If you want a completely clean slate, delete the cluster after destroying the deployment:

kind delete cluster --name solo-cluster

solo-cluster is Solo’s default Kind cluster name; run kind get clusters to confirm yours if you used a custom name. To also remove Solo’s local configuration and cache, use the Full Reset procedure.

Resource Usage

Solo deploys a fully functioning mirror node that stores the transaction history generated by your local test network. During active testing, the mirror node’s resource consumption will grow as it processes more transactions. If you notice increasing resource usage, destroy and redeploy the network to reset it to a clean state.

Full Reset

Warning: This is a last resort procedure. Only use the Full Reset if solo one-shot single destroy fails or your Solo state is corrupted. For normal teardown, always use solo one-shot single destroy instead.

# Delete only Solo-managed Kind clusters (names starting with "solo")
kind get clusters | grep '^solo' | while read cluster; do
  kind delete cluster -n "$cluster"
done

# Remove Solo configuration and cache
rm -rf ~/.solo

Warning: The commands above will delete all Solo-managed Kind clusters and remove your Solo home directory (~/.solo). Always use the grep '^solo' filter when listing clusters - omitting it will delete every Kind cluster on your machine, including any unrelated to Solo.

After deleting the Kind cluster, Kubernetes resources (including namespaces and PVCs) and their associated volumes should be released. If Docker still reports unused volumes that you want to remove, you can optionally run:

# Optional: remove all unused Docker volumes
docker volume prune

Warning: docker volume prune removes all unused Docker volumes on your machine, not just those created by Solo. Only run this command if you understand its impact.

• To redeploy after a full reset, follow the Quickstart guide.

Clean up legacy npm installations

If you previously installed Solo via npm (for example, from older workshops or documentation), remove the global package to avoid conflicts with a newer npm install. Solo has been published under two npm names — @hiero-ledger/solo and @hashgraph/solo — so remove both to be sure no copy is left behind:

# Remove any npm-based Solo install (safe to run even if not present)
npm uninstall -g @hiero-ledger/solo
npm uninstall -g @hashgraph/solo

Then reinstall using the Quickstart, or follow Upgrading an existing Solo installation to move to a specific or latest version.

Tip: If an install failed with EEXIST: file already exists because both package names were present, see Resolving an EEXIST package-name conflict.