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 Homebrew or 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.