This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Documentation

Comprehensive guide to Solo: deploy Hiero consensus networks locally with one command or full manual control. Covers setup, deployment methods, operations, advanced features, integration, and troubleshooting.

This documentation provides a comprehensive guide to using Solo to launch a Hiero Consensus Node network, including setup instructions, usage guides, and information for developers. It covers everything from installation to advanced features and troubleshooting.

1 - Simple Solo Setup

Get started with Solo quickly. This section guides you through prerequisites, one-command deployment, network management, and cleanup. Perfect for developers and testers getting their first Hiero network running locally.

1.1 - System Readiness

Verify hardware and software requirements before deploying a local Hiero test network with Solo. Check system prerequisites, install Docker/Podman, configure platform-specific settings, and ensure your machine is ready.

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 walks you through 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, you will have your container runtime installed, platform-specific settings configured, and all Solo prerequisites in place so you can move on to the Quickstart and create a local network with a single command.

Hardware Requirements

Solo’s resource requirements depend on your deployment size:

ConfigurationMinimum RAMRecommended RAMMinimum CPUMinimum Storage
Single-node12 GB16 GB4 cores20 GB free
Multi-node (3+ nodes)16 GB24 GB8 cores20 GB free

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.

ToolRequired versionHow it is installed
Sololatestbrew install hiero-ledger/tools/solo, or npm install -g @hiero-ledger/solo
Node.js>= 22.0.0 (lts/jod)Homebrew installs it for you; with npm you install it yourself
Container runtime (Docker / Podman)See Docker belowYou install it — Docker Desktop (macOS/Windows) or Docker Engine (Linux). Solo auto-installs Podman on Linux/macOS/WSL2 if Docker Engine is not found. Not supported on native Windows.
kubectl>= v1.32.2Solo provisions it at deploy time - reuses a compatible copy already on your system, or downloads one into ~/.solo/bin
Helmv3.14.2Solo provisions it at deploy time
Kind>= v0.29.0Solo provisions it at deploy time
Kubernetes>= v1.32.2Installed automatically by Kind
k9s (optional)>= v0.27.4You install it

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.

    Docker Desktop resource allocation settings

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:

  1. Install Homebrew (if not already installed):

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

  2. Install Docker Desktop:

    macOS prerequisite: Docker Desktop must be 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.

  3. Install Solo:

    brew install hiero-ledger/tools/solo

  4. Verify the installation:

    solo --version

  1. Install Homebrew for Linux:

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

    Add Homebrew to your PATH:

    echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

  2. Install Docker Engine (for Ubuntu/Debian):

    sudo apt-get update
sudo apt-get install -y docker.io
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker ${USER}

    Log out and back in for the group changes to take effect.

  3. Install Solo:

    brew install hiero-ledger/tools/solo

  4. Verify the installation:

    solo --version

Run Solo natively from Windows PowerShell. Run every command below in a PowerShell terminal.

  1. Install Docker Desktop for Windows:

    Windows prerequisite: Docker Desktop must be running before you run solo one-shot single deploy.

  2. Install Node.js (>= 22.0.0):

    winget install OpenJS.NodeJS.LTS

    Or download the installer from nodejs.org.

  3. Install Solo via npm.

    npm installs the Solo CLI only; Solo provisions kubectl, Helm, and Kind automatically at deploy time:

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

  4. Verify the installation:

    solo --version

Note: Open a new PowerShell window after installing tools so updated PATH entries take effect.

Note: Make sure your machine meets the Windows (WSL2) prerequisite first. If WSL and a Linux distribution are already installed, skip step 1 (and you may use a distribution other than Ubuntu).

  1. Run the following command in Windows PowerShell (as Administrator), then reboot and open the Ubuntu terminal. All subsequent commands must be run inside the Ubuntu (WSL2) terminal.

    wsl --install Ubuntu

  2. Install build tools required by Homebrew:

    sudo apt-get install build-essential procps curl file git

    Note: These are the Linux prerequisites for Homebrew. Without build-essential, brew install hiero-ledger/tools/solo fails with Error: ... must be built from source. Install Clang or run brew install gcc. Only run this command on a trusted system.

  3. Install Homebrew for Linux:

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

    Add Homebrew to your PATH:

    echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

  4. Install Docker Desktop for Windows:

  5. Install Solo:

    brew install hiero-ledger/tools/solo

  6. Verify the installation:

    solo --version

Alternative Installation: npm (for contributors and advanced users)

If you need more control over dependencies or are contributing to Solo development, you can install Solo via npm instead of Homebrew.

Note: Node.js >= 22.0.0 and Kind must be installed separately before using this method.

npm install -g @hiero-ledger/solo

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

Solo VersionNode.jsConsensus NodeKubernetesDocker ResourcesRelease DateEnd of Support
0.81.0>= 22.0.0 (lts/jod)v0.74.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-07-072026-08-07
0.80.0 (LTS)>= 22.0.0 (lts/jod)v0.74.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-06-302026-09-30
0.79.0>= 22.0.0 (lts/jod)v0.74.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-06-232026-07-23
0.78.0 (LTS)>= 22.0.0 (lts/jod)v0.74.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-06-162026-09-16
0.76.0 (LTS)>= 22.0.0 (lts/jod)v0.73.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-06-022026-09-02
0.74.0 (LTS)>= 22.0.0 (lts/jod)v0.73.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-05-262026-08-26
0.72.0 (LTS)>= 22.0.0 (lts/jod)v0.71.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-05-052026-08-05
0.70.0 (LTS)>= 22.0.0 (lts/jod)v0.71.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-04-282026-07-28
0.68.0 (LTS)>= 22.0.0 (lts/jod)v0.71.0>= v1.32.2Memory >= 12GB, CPU cores >= 62026-04-072026-07-07

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.

1.2 - Quickstart

Deploy a local Hiero test network with a single command using the Solo CLI. This guide covers installation, one-shot deployment, network verification, and accessing local service endpoints.

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.

Install Solo CLI

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

  • Homebrew (recommended for macOS/Linux/WSL2):

    brew install hiero-ledger/tools/solo

  • npm (required for native Windows PowerShell; alternative on macOS/Linux/WSL2):

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

    Note: On macOS, Linux, and WSL2, Homebrew is recommended — it installs Node.js for you, whereas 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). On native Windows (PowerShell), npm is the only available option. Regardless of installation method, Solo provisions kubectl, Helm, and Kind automatically at deploy time.

Verify the installation

Confirm that Solo is installed and available on your PATH:

solo --version

Expected output (version may be different):

** Solo **
Version : 0.77.0
**

If you see a similar banner with a valid Solo version (for example, 0.59.1), your installation is successful.

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.

Tip: Solo caches the container images it pulls, so your first deployment may take longer while images download; later deployments reuse the local cache and start 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.

What gets deployed

ComponentDescription
Consensus NodeHiero consensus node for processing transactions.
Mirror NodeStores and serves historical transaction data.
Explorer UIWeb interface for viewing accounts and transactions.
JSON RPC RelayEthereum-compatible JSON RPC interface.
Multiple Node Deployment - for testing consensus scenarios

To deploy multiple consensus nodes, pass the --num-consensus-nodes flag:

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

This deploys 3 consensus nodes along with the same components as the single-node setup (mirror node, explorer, relay).

Note: Multiple node deployments require more resources. Ensure you have at least 16 GB of memory and 8 CPU cores allocated to Docker before running this command. See System Readiness for the full multi-node requirements.

For multi-node teardown, run solo one-shot multi destroy.

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:

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.

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. The endpoints below are the default ports for Solo 0.63 and later:

ServiceEndpointDescriptionVerification
Explorer UIhttp://localhost:38080Web UI for inspecting the network.Open URL in your browser
Consensus node (gRPC)localhost:35211gRPC endpoint for transactions.nc -zv localhost 35211
Mirror node REST APIhttp://localhost:38081REST API for queries.curl http://localhost:38081/api/v1/transactions
JSON RPC relayhttp://localhost:37546Ethereum-compatible JSON RPC endpoint.curl -X POST http://localhost:37546 -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

macOS note: Running nc -zv localhost 35211 may print two lines:

nc: connectx to localhost port 35211 (tcp) failed: Connection refused
Connection to localhost port 35211 [tcp/*] succeeded!

The first line is a failed IPv6 attempt - this is expected on macOS. The second line confirms the IPv4 connection succeeded. The port is reachable.

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

The Verification commands above use bash tools (nc, curl). On native Windows, run the PowerShell equivalents instead:

# Consensus node (gRPC)
Test-NetConnection localhost -Port 35211

# Mirror node REST API
Invoke-RestMethod http://localhost:38081/api/v1/transactions

# JSON RPC relay
Invoke-RestMethod -Method Post -Uri 'http://localhost:37546' -ContentType 'application/json' -Body '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Note: In PowerShell, curl is an alias for Invoke-WebRequest, so the bash curl flags above will not work. Use curl.exe explicitly if you prefer the bash-style syntax.

Port availability

The ports above are Solo’s defaults. Solo uses kubectl port-forward to tunnel traffic from your machine to services running inside Kubernetes. Before opening each tunnel, Solo tries the configured port:

  • If the port is free, Solo logs: Using requested port <port>.
  • If the port is already occupied (by another process, or by a previous Solo session that did not clean up its port-forwards), Solo finds the next available port and logs: Using available port <port>.

The actual ports used are printed at the end of solo one-shot single deploy. You can also look them up at any time with the Solo CLI, using your deployment name (see Capture your deployment name).

To view the active port assignments:

solo deployment config ports --deployment <deployment-name>

cat ~/.solo/one-shot-$(cat ~/.solo/cache/last-one-shot-deployment.txt)/forwards

Get-Content "$env:USERPROFILE\.solo\one-shot-$(Get-Content $env:USERPROFILE\.solo\cache\last-one-shot-deployment.txt)\forwards"

*** Consensus node gRPC ***

  • component 1: localhost:35211 -> pod:50211
solo deployment config info --deployment $(cat ~/.solo/cache/last-one-shot-deployment.txt)

solo deployment config info --deployment (Get-Content $env:USERPROFILE\.solo\cache\last-one-shot-deployment.txt)

To restore port-forwards after a system restart without redeploying:

solo deployment refresh port-forwards --deployment $(cat ~/.solo/cache/last-one-shot-deployment.txt)

solo deployment refresh port-forwards --deployment (Get-Content $env:USERPROFILE\.solo\cache\last-one-shot-deployment.txt)

Endpoints for Solo 0.62 and earlier

If you are using Solo 0.62 or earlier, the default port-forward targets differ:

ServiceEndpointDescription
Explorer UIhttp://localhost:8080Web UI for inspecting the network.
Consensus node (gRPC)localhost:50211gRPC endpoint for transactions.
Mirror node REST APIhttp://localhost:8081REST API for queries (via mirror-ingress).
JSON RPC relayhttp://localhost:7546Ethereum-compatible JSON RPC endpoint.

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

Note: localhost:5551 is the direct Mirror Node REST service, accessible only via manual kubectl port-forward, and is being phased out. Always use the ingress-based port (8081 for Solo 0.62 and earlier, 38081 for Solo 0.63+).

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.

1.3 - Managing Your Network

Learn how to start, stop, and restart consensus nodes, capture logs and diagnostics, and troubleshoot a running Solo network. Master day-to-day network operations and troubleshooting.

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.

cat ~/.solo/cache/last-one-shot-deployment.txt

Get-Content $env:USERPROFILE\.solo\cache\last-one-shot-deployment.txt

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

one-shot%

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

FlagDescription
--deploymentThe deployment to reset.
--node-aliasesComma-separated consensus node aliases to reset. Defaults to all nodes in the deployment.
--cluster-refThe cluster reference, for a deployment that spans multiple clusters.

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 in ~/.solo/cache/last-one-shot-deployment.txt (on native Windows, $env:USERPROFILE\.solo\cache\last-one-shot-deployment.txt; default: one-shot).

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

1.4 - Upgrade Your Network

Learn how to upgrade an existing Solo network deployment to a newer Hiero version using the Solo CLI and verify compatibility before you begin.

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.

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.

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.

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 typically matches the deployment name in ~/.solo/cache/last-one-shot-deployment.txt.

1.5 - Upgrading an existing Solo installation

Upgrade an existing Solo installation to the latest release - whether you installed via Homebrew or npm - and perform a clean reinstall when an upgrade leaves a broken or conflicting state.

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.

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.

brew install hiero-ledger/tools/solo@0.76.0

The tap publishes a versioned formula (solo@<version>) for each release.

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

If you want to switch package managers (for example, from an older npm install to Homebrew), remove the existing copy first so you do not end up with two solo binaries on your PATH:

# Remove the npm copy before installing via Homebrew (or vice versa)
npm uninstall -g @hiero-ledger/solo

Then follow the install 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.

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.

1.6 - Cleanup

Learn how to properly destroy a Solo network deployment, manage resource usage, and perform a full reset when the standard destroy command fails along with how to clean up resources safely and completely.

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.

2 - Advanced Solo Setup

Deep-dive into advanced deployment methods, network customization, and operational management. This section covers YAML-driven deployments, manual component orchestration, dynamic node management, and CI/CD integration. Ideal for DevOps engineers and system administrators requiring full control.

2.1 - Using Environment Variables

A comprehensive reference of all environment variables supported by Solo, including their purposes, default values, and expected formats. Configure Solo deployments through environment variable tuning.

Overview

Solo supports a set of environment variables that let you customize its behaviour without modifying command-line flags on every run. Variables set in your shell environment take effect automatically for all subsequent Solo commands.

Setting environment variables

How you set a variable depends on your shell. Use the tab for your platform:

# For a single command only
CONSENSUS_NODE_VERSION=v0.73.0 solo one-shot single deploy

# For the current session
export CONSENSUS_NODE_VERSION=v0.73.0

# Persist across sessions (add to ~/.bashrc or ~/.zshrc)
echo 'export CONSENSUS_NODE_VERSION=v0.73.0' >> ~/.zshrc

# For the current session
$env:CONSENSUS_NODE_VERSION = 'v0.73.0'

# Persist for your user (all future sessions)
[System.Environment]::SetEnvironmentVariable('CONSENSUS_NODE_VERSION', 'v0.73.0', 'User')

# Or add it to your PowerShell profile
Add-Content $PROFILE '$env:CONSENSUS_NODE_VERSION = "v0.73.0"'

Tip: Variables set in your shell environment (or persisted as shown above) take effect automatically for all subsequent Solo commands.

General

Environment VariableDescriptionDefault Value
SOLO_HOMEPath to the Solo cache and log files~/.solo
SOLO_CACHE_DIRPath to the Solo cache directory~/.solo/cache
SOLO_LOG_LEVELLogging level for Solo operations. Accepted values: trace, debug, info, warn, errorinfo
SOLO_DEV_OUTPUTTreat all commands as if the --dev flag were specifiedfalse
SOLO_CHAIN_IDChain ID of the Solo network298
FORCE_PODMANForce the use of Podman as the container engine when creating a new local cluster. Accepted values: true, falsefalse

Network and Node Identity

Environment VariableDescriptionDefault Value
DEFAULT_START_ID_NUMBERRaw node ID number for the first consensus node. The first node account ID is resolved as 0.0.<DEFAULT_START_ID_NUMBER>3
SOLO_NODE_INTERNAL_GOSSIP_PORTInternal gossip port used by the Hiero network50111
SOLO_NODE_EXTERNAL_GOSSIP_PORTExternal gossip port used by the Hiero network50111
SOLO_NODE_DEFAULT_STAKE_AMOUNTDefault stake amount for a node500
GRPC_PORTLocal port-forward for consensus node gRPC. Default is 35211 for Solo 0.63+ (changed from 50211 to avoid Windows ephemeral-port conflicts). See Port availability.35211
LOCAL_NODE_START_PORTLocal node start port for the Solo network30212

Operator and Key Configuration

Environment VariableDescriptionDefault Value
SOLO_OPERATOR_IDOperator account ID for the Solo network0.0.2
SOLO_OPERATOR_KEYOperator private key for the Solo network302e020100...
SOLO_OPERATOR_PUBLIC_KEYOperator public key for the Solo network302a300506...
FREEZE_ADMIN_ACCOUNTFreeze admin account ID for the Solo network0.0.58
GENESIS_KEYGenesis private key for the Solo network302e020100...

Note: Full key values are omitted above for readability. Refer to the source defaults for complete key strings.

Node Client Behaviour

Environment VariableDescriptionDefault Value
NODE_CLIENT_MIN_BACKOFFMinimum wait time between retries, in milliseconds1000
NODE_CLIENT_MAX_BACKOFFMaximum wait time between retries, in milliseconds1000
NODE_CLIENT_REQUEST_TIMEOUTTime a transaction or query retries on a “busy” network response, in milliseconds600000
NODE_CLIENT_MAX_ATTEMPTSMaximum number of attempts for node client operations600
NODE_CLIENT_SDK_PING_MAX_RETRIESMaximum number of retries for node health pings5
NODE_CLIENT_SDK_PING_RETRY_INTERVALInterval between node health ping retries, in milliseconds10000
NODE_COPY_CONCURRENTNumber of concurrent threads used when copying files to a node4
LOCAL_BUILD_COPY_RETRYNumber of retries for local build copy operations3
ACCOUNT_UPDATE_BATCH_SIZENumber of accounts to update in a single batch operation10

Pod and Network Readiness

Environment VariableDescriptionDefault Value
PODS_RUNNING_MAX_ATTEMPTSMaximum number of attempts to check if pods are running900
PODS_RUNNING_DELAYInterval between pod running checks, in milliseconds1000
PODS_READY_MAX_ATTEMPTSMaximum number of attempts to check if pods are ready300
PODS_READY_DELAYInterval between pod ready checks, in milliseconds2000
NETWORK_NODE_ACTIVE_MAX_ATTEMPTSMaximum number of attempts to check if network nodes are active300
NETWORK_NODE_ACTIVE_DELAYInterval between network node active checks, in milliseconds1000
NETWORK_NODE_ACTIVE_TIMEOUTMaximum wait time for network nodes to become active, in milliseconds1000
NETWORK_PROXY_MAX_ATTEMPTSMaximum number of attempts to check if the network proxy is running300
NETWORK_PROXY_DELAYInterval between network proxy checks, in milliseconds2000
NETWORK_DESTROY_WAIT_TIMEOUTMaximum wait time for network teardown to complete, in milliseconds120

Block Node

Environment VariableDescriptionDefault Value
BLOCK_NODE_PODS_RUNNING_MAX_ATTEMPTSMaximum number of attempts to check if block node pods are running900
BLOCK_NODE_PODS_RUNNING_DELAYInterval between block node pod running checks, in milliseconds1000
BLOCK_NODE_ACTIVE_MAX_ATTEMPTSMaximum number of attempts to check if block nodes are active100
BLOCK_NODE_ACTIVE_DELAYInterval between block node active checks, in milliseconds60
BLOCK_NODE_ACTIVE_TIMEOUTMaximum wait time for block nodes to become active, in milliseconds60
BLOCK_STREAM_STREAM_MODEThe blockStream.streamMode value in consensus node application properties. Only applies when a Block Node is deployedBOTH
BLOCK_STREAM_WRITER_MODEThe blockStream.writerMode value in consensus node application properties. Only applies when a Block Node is deployedFILE_AND_GRPC

Relay Node

Environment VariableDescriptionDefault Value
RELAY_PODS_RUNNING_MAX_ATTEMPTSMaximum number of attempts to check if relay pods are running900
RELAY_PODS_RUNNING_DELAYInterval between relay pod running checks, in milliseconds1000
RELAY_PODS_READY_MAX_ATTEMPTSMaximum number of attempts to check if relay pods are ready100
RELAY_PODS_READY_DELAYInterval between relay pod ready checks, in milliseconds1000

Mirror Node

Environment VariableDescriptionDefault Value
DISABLE_IMPORTER_SPRING_PROFILESDisable automatic configuration of Mirror Node importer Spring profiles for block-node integration.false
SPRING_PROFILES_ACTIVESpring profiles to use for the Mirror Node importer when automatic importer profile configuration is enabled.blocknode

Load Balancer

Environment VariableDescriptionDefault Value
LOAD_BALANCER_CHECK_DELAY_SECSDelay between load balancer status checks, in seconds5
LOAD_BALANCER_CHECK_MAX_ATTEMPTSMaximum number of attempts to check load balancer status60

Lease Management

Environment VariableDescriptionDefault Value
SOLO_LEASE_ACQUIRE_ATTEMPTSNumber of attempts to acquire a lock before failing10
SOLO_LEASE_DURATIONDuration in seconds for which a lock is held before expiration20

Component Versions

Environment VariableDescription
CONSENSUS_NODE_VERSIONRelease version of the Consensus Node to use
BLOCK_NODE_VERSIONRelease version of the Block Node to use
MIRROR_NODE_VERSIONRelease version of the Mirror Node to use
EXPLORER_VERSIONRelease version of the Explorer to use
RELAY_VERSIONRelease version of the JSON-RPC Relay to use
INGRESS_CONTROLLER_VERSIONRelease version of the HAProxy Ingress Controller to use
SOLO_CHART_VERSIONRelease version of the Solo Helm charts to use
MINIO_OPERATOR_VERSIONRelease version of the MinIO Operator to use
PROMETHEUS_STACK_VERSIONRelease version of the Prometheus Stack to use
GRAFANA_AGENT_VERSIONRelease version of the Grafana Agent to use

Tip: To pin component versions for a solo one-shot single deploy, prefix the command with these variables. See the One-Shot Deployment section below for an example.

Edge Component Versions

These variables only take effect when solo one-shot single deploy or solo one-shot multi deploy is invoked with the --edge flag (solo one-shot falcon deploy does not accept --edge in v0.72.0). They let you point a one-shot deploy at arbitrary component tags — release candidates, pre-releases, or any other tag the component’s registry exposes — without rebuilding Solo.

ComponentEnvironment VariableFalls back to
Consensus NodeCONSENSUS_NODE_EDGE_VERSIONCONSENSUS_NODE_VERSION
Mirror NodeMIRROR_NODE_EDGE_VERSIONMIRROR_NODE_VERSION
JSON-RPC RelayRELAY_EDGE_VERSIONRELAY_VERSION
ExplorerEXPLORER_EDGE_VERSIONEXPLORER_VERSION
Block NodeBLOCK_NODE_EDGE_VERSIONBLOCK_NODE_VERSION
Solo ChartSOLO_CHART_EDGE_VERSIONSOLO_CHART_VERSION

Set only the variables for components you want to override; the rest use their compiled-in edge defaults. Without --edge, every *_EDGE_VERSION variable is ignored.

For full usage, examples, version-format rules, and troubleshooting, see One-Shot Deploy with Custom Component Versions.

Helm Chart URLs

Environment VariableDescriptionDefault Value
JSON_RPC_RELAY_CHART_URLHelm chart repository URL for the JSON-RPC Relayhttps://hiero-ledger.github.io/hiero-json-rpc-relay/charts
MIRROR_NODE_CHART_URLHelm chart repository URL for the Mirror Nodehttps://hashgraph.github.io/hedera-mirror-node/charts
EXPLORER_CHART_URLHelm chart repository URL for the Exploreroci://ghcr.io/hiero-ledger/hiero-mirror-node-explorer/hiero-explorer-chart
INGRESS_CONTROLLER_CHART_URLHelm chart repository URL for the ingress controllerhttps://haproxy-ingress.github.io/charts
PROMETHEUS_OPERATOR_CRDS_CHART_URLHelm chart repository URL for the Prometheus Operator CRDshttps://prometheus-community.github.io/helm-charts
NETWORK_LOAD_GENERATOR_CHART_URLHelm chart repository URL for the Network Load Generatoroci://swirldslabs.jfrog.io/load-generator-helm-release-local

Network Load Generator

Environment VariableDescriptionDefault Value
NETWORK_LOAD_GENERATOR_CHART_VERSIONRelease version of the Network Load Generator Helm chart to usev0.7.0
NETWORK_LOAD_GENERATOR_PODS_RUNNING_MAX_ATTEMPTSMaximum number of attempts to check if Network Load Generator pods are running900
NETWORK_LOAD_GENERATOR_POD_RUNNING_DELAYInterval between Network Load Generator pod running checks, in milliseconds1000

One-Shot Deployment

Environment VariableDescriptionDefault Value
ONE_SHOT_WITH_BLOCK_NODEDeploy Block Node as part of a one-shot deploymentfalse
MIRROR_NODE_PINGER_TPSTransactions per second for the Mirror Node monitor pinger. Set to 0 to disable5
CONSENSUS_NODE_EDGE_VERSIONEdge (newer-than-default) consensus node version used by --edge in one-shot deploys. Falls back to CONSENSUS_NODE_VERSION.v0.74.0-rc.1
MIRROR_NODE_EDGE_VERSIONEdge mirror node version used by --edge in one-shot deploys. Falls back to MIRROR_NODE_VERSION.v0.153.1
EXPLORER_EDGE_VERSIONEdge explorer version used by --edge in one-shot deploys. Falls back to EXPLORER_VERSION.26.0.0
RELAY_EDGE_VERSIONEdge relay version used by --edge in one-shot deploys. Falls back to RELAY_VERSION.0.76.2
BLOCK_NODE_EDGE_VERSIONEdge block node version used by --edge in one-shot deploys. Falls back to BLOCK_NODE_VERSION.0.31.0

Pinning Component Versions

solo one-shot single deploy does not yet expose CLI flags for pinning individual component versions. To run a one-shot deployment against specific releases, prefix the command with the Component Versions environment variables:

CONSENSUS_NODE_VERSION=v0.73.0 MIRROR_NODE_VERSION=v0.153.1 solo one-shot single deploy

Any of the *_VERSION variables listed in Component Versions can be combined in the same command to pin multiple components at once.

Note:

  • This is the current recommended approach for version pinning in one-shot deployments.
  • CLI flags for version overrides on one-shot are planned for Q2 — tracked in hiero-ledger/solo#4242.
  • Environment variables will remain valid for one-off overrides after the CLI flags land, so the form above will continue to work.

Image Cache

Solo caches the container images it deploys as local archives to speed up repeat deployments. The cache is enabled by default; these variables disable it per context. See Solo Image Cache for the full feature and the solo cache image commands.

Environment VariableDescriptionDefault
ENABLE_IMAGE_CACHESet to false to disable the image cache during solo one-shot deploys. Requires Solo v0.78.0 or later (earlier releases have an inverted-logic bug in this flag).enabled
SOLO_NO_CACHESet to true to skip the image pull during an npm global install.enabled
HOMEBREW_NO_SOLO_CACHESet to any value to skip the image pull during a Homebrew install.enabled

Note: The cached component versions follow the same environment-variable mechanism as Pinning Component Versions above - the *_VERSION environment variables affect the images the cache pulls, but the --*-version CLI flags do not.

2.2 - Network Deployments

Step-by-step workflows and component-level customization for users who need full control over network initialization, configuration, and scaling. Explore YAML-driven deployments, manual orchestration, dynamic node management, and extensive reference documentation.

2.2.1 - One-shot Falcon Deployment

Deploy a complete Solo network from a single YAML file for repeatable advanced setups, CI pipelines, and custom component configuration. Falcon combines simplicity with full customization using the Solo values file format.

Overview

One-shot Falcon deployment is Solo’s YAML-driven one-shot workflow. It uses the same core deployment pipeline as solo one-shot single deploy, but lets you inject component-specific flags through a single values file.

Use One-shot Falcon deployment when you need a repeatable advanced setup, want to check a complete deployment into source control, or need to customise component flags without running every Solo command manually.

Falcon is especially useful for:

  • CI/CD pipelines and automated test environments.
  • Reproducible local developer setups.
  • Advanced deployments that need custom chart paths, image versions, ingress, storage, TLS, or node startup options.

Important: Falcon is an orchestration layer over Solo’s standard commands. It does not introduce a separate deployment model. Solo still creates a deployment, attaches clusters, deploys the network, configures nodes, and then adds optional components such as mirror node, explorer, and relay.

Prerequisites

Before proceeding, ensure you have completed the following:

  • System Readiness - your local environment meets the hardware and software requirements for Solo, Kubernetes, Docker, Kind, kubectl, and Helm.
  • Quickstart -you are already familiar with the standard one-shot deployment workflow.

How Falcon Works

When you run Falcon deployment, Solo executes the same end-to-end deployment sequence used by its one-shot workflows:

  1. Connect to the Kubernetes cluster.
  2. Create a deployment and attach the cluster reference.
  3. Set up shared cluster components.
  4. Generate gossip and TLS keys.
  5. Deploy the consensus network and, if enabled, the block node (in parallel).
  6. Set up and start consensus nodes.
  7. Optionally, deploy mirror node, explorer, and relay in parallel for faster startup.
  8. Create predefined test accounts.
  9. Write deployment notes, versions, port-forward details, and account data to a local output directory.

The difference is that Falcon reads a YAML file and maps its top-level sections to the underlying Solo subcommands.

Values file sectionSolo subcommand invoked
networksolo consensus network deploy
setupsolo consensus node setup
consensusNodesolo consensus node start
mirrorNodesolo mirror node add
explorerNodesolo explorer node add
relayNodesolo relay node add
blockNodesolo block node add (when ONE_SHOT_WITH_BLOCK_NODE=true)

For the full list of supported CLI flags per section, see the Falcon Values File Reference. If you set network.--application-properties, see Custom Application Properties for the difference between Solo’s default merge mode and full overwrite mode.

Prepare a Falcon values file

Instead of authoring a values file by hand, you can use the interactive prepare wizard to generate one:

solo one-shot falcon prepare

The wizard prompts for component toggles (mirror node, explorer, relay), consensus node count, component versions, ingress, storage type, developer options, and port forwarding. All prompts have sensible defaults, so you can press Enter to accept them.

To generate a values file with all defaults (no prompts):

solo one-shot falcon prepare --quiet-mode

To specify a custom output path:

solo one-shot falcon prepare --output-values-file ./my-values.yaml

Output file location

By default, the generated file is written to ~/.solo/cache/falcon-values.yaml — a deterministic absolute path regardless of how or where Solo is invoked. You can override this with --output-values-file. The success message always prints the fully resolved path so there is no ambiguity.

  • Default: ~/.solo/cache/falcon-values.yaml — always the same location.
  • Relative path: --output-values-file ./configs/my-values.yaml — resolved against the current working directory (so /tmp/configs/my-values.yaml if invoked from /tmp).
  • Absolute path: --output-values-file /tmp/falcon-values.yaml — written to that exact location regardless of the current working directory.

The generated file is ready to use with solo one-shot falcon deploy --values-file. For the full list of flags the wizard sets, see the Falcon Values File Reference.

Create a Falcon Values File

Create a YAML file to control every component of your Solo deployment. The file can have any name -falcon-values.yaml is used throughout this guide as a convention.

Note: Keys within each section must be the full CLI flag name including the -- prefix - for example, --release-tag, not release-tag or -r. Any section you omit from the file is skipped, and Solo uses the built-in defaults for that component.

Example: Single-Node Falcon Deployment

The following falcon-values.yaml example deploys a standard single-node network with mirror node, explorer, and relay enabled:

network:
  --release-tag: "v0.71.0"
  --pvcs: false

setup:
  --release-tag: "v0.71.0"

consensusNode:
  --force-port-forward: true

mirrorNode:
  --enable-ingress: true
  --pinger: true
  --force-port-forward: true

explorerNode:
  --enable-ingress: true
  --force-port-forward: true

relayNode:
  --node-aliases: "node1"
  --force-port-forward: true

Deploy with Falcon one-shot

Run Falcon deployment by pointing Solo at the values file:

solo one-shot falcon deploy --values-file falcon-values.yaml

Solo creates a one-shot deployment, applies the values from the YAML file to the appropriate subcommands, and then deploys the full environment.

Command-Line Flags (Not in YAML File)

The following flags are passed on the command line and cannot be set in the YAML file:

  • --deployment, --namespace, --cluster-ref, --num-consensus-nodes

Note: --values-file specifies which YAML file to load.

  • --values-file selects the YAML file to load.
  • --deployment, --namespace, --cluster-ref, and --num-consensus-nodes are top-level one-shot inputs.

Important: Do not rely on --deployment inside falcon-values.yaml. Solo intentionally ignores --deployment values from section content during Falcon argument expansion. Set the deployment name on the command line if you need a specific name.


Tip: When not specified, Falcon uses these defaults: --deployment one-shot, --namespace one-shot, --cluster-ref one-shot, and --num-consensus-nodes 1. Pass any of these explicitly on the command line to override them.

Example:

solo one-shot falcon deploy \
  --deployment falcon-demo \
  --cluster-ref one-shot \
  --values-file falcon-values.yaml

Multi-Node Falcon Deployment

For multiple consensus nodes, set the node count on the Falcon command and then provide matching per-node settings where required.

  • Example:

    solo one-shot falcon deploy \
  --deployment falcon-multi \
  --num-consensus-nodes 3 \
  --values-file falcon-values.yaml

  • Example multi-node values file:

    network:
  --release-tag: "v0.71.0"
  --pvcs: true

setup:
  --release-tag: "v0.71.0"

consensusNode:
  --force-port-forward: true
  --stake-amounts: "100,100,100"

mirrorNode:
  --enable-ingress: true
  --pinger: true

explorerNode:
  --enable-ingress: true

relayNode:
  --node-aliases: "node1,node2,node3"

  • The --node-aliases value in the relayNode section must match the node aliases generated by --num-consensus-nodes. Nodes are auto-named node1, node2, node3, and so on. Setting this to only node1 is valid if you want the relay to serve a single node, but specifying all aliases is typical for full coverage.

  • Use this pattern when you need a repeatable multi-node deployment but do not want to manage each step manually.

Note: Multi-node deployments require more host resources than single-node deployments. Follow the resource guidance in System Readiness, and increase Docker memory and CPU allocation before deploying.

Common Falcon Customisations

Because each YAML section maps directly to the corresponding Solo subcommand, you can use Falcon to centralise advanced options such as:

  • Custom release tags for the consensus node platform.
  • Local chart directories for mirror node, relay, explorer, or block node.
  • Local consensus node build paths for development workflows.
  • Ingress and domain settings.
  • Mirror node external database settings.
  • Node startup settings such as state files, port forwarding, and stake amounts.
  • Storage backends and credentials for stream file handling.

Example: Local Development with Local Chart Directories

setup:
  --local-build-path: "/path/to/hiero-consensus-node/hedera-node/data"

mirrorNode:
  --mirror-node-chart-dir: "/path/to/hiero-mirror-node/charts"

relayNode:
  --relay-chart-dir: "/path/to/hiero-json-rpc-relay/charts"

explorerNode:
  --explorer-chart-dir: "/path/to/hiero-mirror-node-explorer/charts"

This pattern is useful for local integration testing against unpublished component builds. For a step-by-step walkthrough of the local build workflow, see Deploying a Local Consensus Node Build.

Falcon with Block Node

Falcon can also include block node configuration.

Note: Block node workflows are advanced and require higher resource allocation and version compatibility across consensus node, block node, and related components. Docker memory must be set to at least 16 GB before deploying with block node enabled.

Block node support also requires the ONE_SHOT_WITH_BLOCK_NODE=true environment variable to be set before running falcon deploy. Without it, Solo skips the block node add step even if a blockNode section is present in the values file.

Block node deployment is subject to version compatibility requirements. Minimum versions are consensus node ≥ v0.72.0 and block node ≥ 0.29.0. Mixing incompatible versions will cause the deployment to fail. Check the Version Compatibility Reference before enabling block node.

Example:

network:
  --release-tag: "v0.72.0"

setup:
  --release-tag: "v0.72.0"

consensusNode:
  --force-port-forward: true

blockNode:
  --release-tag: "v0.29.0"
  --enable-ingress: false

mirrorNode:
  --enable-ingress: true
  --pinger: true

explorerNode:
  --enable-ingress: true

relayNode:
  --node-aliases: "node1"
  --force-port-forward: true

Use block node settings only when your target Solo and component versions are known to be compatible.

Deployment Output

After a successful Falcon deployment, Solo writes deployment metadata to ~/.solo/one-shot-<deployment>/ where <deployment> is the value of the --deployment flag (default: one-shot).

This directory typically contains:

  • notes - human-readable deployment summary
  • versions - component versions recorded at deploy time
  • forwards - port-forward configuration
  • accounts.json - predefined test account keys and IDs. All accounts are ECDSA Alias accounts (EVM-compatible) and include a publicAddress field. The file also includes the system operator account.

This makes Falcon especially useful for automation, because the deployment artifacts are written to a predictable path after each run.

To inspect deployment output, check the ~/.solo/one-shot-<deployment>/ directory directly.

If port-forwards are interrupted after deployment, restore them by rerunning the component commands (such as solo consensus node start, solo mirror node add, etc.)

Destroy a Falcon Deployment

  • Destroy the Falcon deployment with:

    solo one-shot falcon destroy

  • Solo removes deployed extensions first, then destroys the mirror node, network, cluster references, and local deployment metadata.

  • If multiple deployments exist locally, Solo prompts you to choose which one to destroy unless you pass --deployment explicitly.

    solo one-shot falcon destroy --deployment falcon-demo

When to Use Falcon vs. Manual Deployment

Use Falcon deployment when you want a single, repeatable command backed by a versioned YAML file.

Use Step-by-Step Manual Deployment when you need to pause between steps, inspect intermediate state, or debug a specific deployment phase in isolation.

In practice:

  • Falcon is better for automation and repeatability.
  • Manual deployment is better for debugging and low-level control.

Reference

Tip: If you are creating a values file for the first time, start from the annotated template in the Solo repository rather than writing one from scratch:

examples/one-shot-falcon/falcon-values.yaml

This file includes all supported sections and flags with inline comments explaining each option. Copy it, remove what you do not need, and adjust the values for your environment.

2.2.2 - Falcon Values File Reference

Comprehensive reference for all supported CLI flags per section of a Falcon values file, including defaults, types, and descriptions. Use this as your source of truth when customizing Falcon deployments.

Overview

This page catalogs the Solo CLI flags accepted under each top-level section of a Falcon values file. Each entry corresponds to the command-line flag that the underlying Solo subcommand accepts.

Sections map to subcommands as follows:

SectionSolo subcommand
networksolo consensus network deploy
setupsolo consensus node setup
consensusNodesolo consensus node start
mirrorNodesolo mirror node add
explorerNodesolo explorer node add
relayNodesolo relay node add
blockNodesolo block node add

All flag names must be written in long form with double dashes (for example, --release-tag). Flags left empty ("") or matching their default value are ignored by Solo at argument expansion time.

Note: Not every flag listed here is relevant to every deployment. Use this page as a lookup when writing or debugging a values file. For a working example file, see the upstream reference at https://github.com/hiero-ledger/solo/tree/main/examples/one-shot-falcon.

Consensus Network Deploy — network

Flags passed to solo consensus network deploy.

FlagTypeDefaultDescription
--release-tagstringcurrent Hedera platform versionConsensus node release tag (e.g. v0.71.0).
--pvcsbooleanfalseEnable Persistent Volume Claims for consensus node storage. Required for node add operations.
--load-balancerbooleanfalseEnable load balancer for network node proxies.
--chart-dirstring—Path to a local Helm chart directory for the Solo network chart.
--solo-chart-versionstringcurrent chart versionSpecific Solo testing chart version to deploy.
--haproxy-ipsstring—Static IP mapping for HAProxy pods (e.g. node1=127.0.0.1,node2=127.0.0.2).
--envoy-ipsstring—Static IP mapping for Envoy proxy pods.
--debug-node-aliasstring—Enable the default JVM debug port (5005) for the specified node alias.
--domain-namesstring—Custom domain name mapping per node alias (e.g. node1=node1.example.com).
--grpc-tls-certstring—TLS certificate path for gRPC, per node alias (e.g. node1=/path/to/cert).
--grpc-web-tls-certstring—TLS certificate path for gRPC Web, per node alias.
--grpc-tls-keystring—TLS certificate key path for gRPC, per node alias.
--grpc-web-tls-keystring—TLS certificate key path for gRPC Web, per node alias.
--storage-typestringminio_onlyStream file storage backend. Options: minio_only, aws_only, gcs_only, aws_and_gcs.
--gcs-write-access-keystring—GCS write access key.
--gcs-write-secretsstring—GCS write secret key.
--gcs-endpointstring—GCS storage endpoint URL.
--gcs-bucketstring—GCS bucket name.
--gcs-bucket-prefixstring—GCS bucket path prefix.
--aws-write-access-keystring—AWS write access key.
--aws-write-secretsstring—AWS write secret key.
--aws-endpointstring—AWS storage endpoint URL.
--aws-bucketstring—AWS bucket name.
--aws-bucket-regionstring—AWS bucket region.
--aws-bucket-prefixstring—AWS bucket path prefix.
--settings-txtstringtemplatePath to a custom settings.txt file for consensus nodes.
--application-propertiesstringtemplatePath to a custom application.properties file. Defaults to key-level merge mode; add # SOLO_ENABLE_OVERWRITE=true to the file for overwrite mode. See Custom Application Properties.
--application-envstringtemplatePath to a custom application.env file.
--api-permission-propertiesstringtemplatePath to a custom api-permission.properties file.
--bootstrap-propertiesstringtemplatePath to a custom bootstrap.properties file.
--log4j2-xmlstringtemplatePath to a custom log4j2.xml file.
--genesis-throttles-filestring—Path to a custom throttles.json file for network genesis.
--service-monitorbooleanfalseInstall a ServiceMonitor custom resource for Prometheus metrics.
--pod-logbooleanfalseInstall a PodLog custom resource for node pod log monitoring.
--quiet-modebooleanfalseSuppress confirmation prompts.
--values-filestring—Comma-separated Helm chart values file paths (not the Falcon values file).

Consensus Node Setup — setup

Flags passed to solo consensus node setup.

FlagTypeDefaultDescription
--release-tagstringcurrent Hedera platform versionConsensus node release tag. Must match network.--release-tag.
--local-build-pathstring—Path to a local Hiero consensus node build (e.g. ~/hiero-consensus-node/hedera-node/data). Used for local development workflows.
--appstringHederaNode.jarName of the consensus node application binary.
--app-configstring—Path to a JSON configuration file for the testing app.
--admin-public-keysstring—Comma-separated DER-encoded ED25519 public keys in node alias order.
--domain-namesstring—Custom domain name mapping per node alias.
--devbooleanfalseEnable developer mode.
--quiet-modebooleanfalseSuppress confirmation prompts.
--cache-dirstring~/.solo/cacheLocal cache directory for downloaded artifacts.

Consensus Node Start — consensusNode

Flags passed to solo consensus node start.

FlagTypeDefaultDescription
--force-port-forwardbooleantrueForce port forwarding to access network services locally.
--stake-amountsstring—Comma-separated stake amounts in node alias order (e.g. 100,100,100). Required for multi-node deployments that need non-default stakes.
--state-filestring—Path to a zipped state file to restore the network from.
--debug-node-aliasstring—Enable JVM debug port (5005) for the specified node alias.
--appstringHederaNode.jarName of the consensus node application binary.
--quiet-modebooleanfalseSuppress confirmation prompts.

Mirror Node Add — mirrorNode

Flags passed to solo mirror node add.

FlagTypeDefaultDescription
--mirror-node-versionstringcurrent versionMirror node Helm chart version to deploy.
--enable-ingressbooleanfalseDeploy an ingress controller for the mirror node.
--force-port-forwardbooleantrueEnable port forwarding for mirror node services.
--pingerbooleanfalseEnable the mirror node Pinger service.
--mirror-static-ipstring—Static IP address for the mirror node load balancer.
--domain-namestring—Custom domain name for the mirror node.
--ingress-controller-value-filestring—Path to a Helm values file for the ingress controller.
--mirror-node-chart-dirstring—Path to a local mirror node Helm chart directory.
--use-external-databasebooleanfalseConnect to an external PostgreSQL database instead of the chart-bundled one.
--external-database-hoststring—Hostname of the external database. Requires --use-external-database.
--external-database-owner-usernamestring—Owner username for the external database.
--external-database-owner-passwordstring—Owner password for the external database.
--external-database-read-usernamestring—Read-only username for the external database.
--external-database-read-passwordstring—Read-only password for the external database.
--storage-typestringminio_onlyStream file storage backend for the mirror node importer.
--storage-read-access-keystring—Storage read access key for the mirror node importer.
--storage-read-secretsstring—Storage read secret key for the mirror node importer.
--storage-endpointstring—Storage endpoint URL for the mirror node importer.
--storage-bucketstring—Storage bucket name for the mirror node importer.
--storage-bucket-prefixstring—Storage bucket path prefix.
--storage-bucket-regionstring—Storage bucket region.
--operator-idstring—Operator account ID for the mirror node.
--operator-keystring—Operator private key for the mirror node.
--quiet-modebooleanfalseSuppress confirmation prompts.
--values-filestring—Comma-separated Helm chart values file paths for the mirror node chart.

Explorer Add — explorerNode

Flags passed to solo explorer node add.

FlagTypeDefaultDescription
--explorer-versionstringcurrent versionHiero Explorer Helm chart version to deploy.
--enable-ingressbooleanfalseDeploy an ingress controller for the explorer.
--force-port-forwardbooleantrueEnable port forwarding for the explorer service.
--domain-namestring—Custom domain name for the explorer.
--ingress-controller-value-filestring—Path to a Helm values file for the ingress controller.
--explorer-chart-dirstring—Path to a local Hiero Explorer Helm chart directory.
--explorer-static-ipstring—Static IP address for the explorer load balancer.
--enable-explorer-tlsbooleanfalseEnable TLS for the explorer. Requires cert-manager.
--explorer-tls-host-namestringexplorer.solo.localHostname used for the explorer TLS certificate.
--tls-cluster-issuer-typestringself-signedTLS cluster issuer type. Options: self-signed, acme-staging, acme-prod.
--mirror-node-idnumber—ID of the mirror node instance to connect the explorer to.
--mirror-namespacestring—Kubernetes namespace of the mirror node.
--solo-chart-versionstringcurrent versionSolo chart version used for explorer cluster setup.
--quiet-modebooleanfalseSuppress confirmation prompts.
--values-filestring—Comma-separated Helm chart values file paths for the explorer chart.

JSON-RPC Relay Add — relayNode

Flags passed to solo relay node add.

FlagTypeDefaultDescription
--relay-releasestringcurrent versionHiero JSON-RPC Relay Helm chart release to deploy.
--node-aliasesstring—Comma-separated node aliases the relay will observe (e.g. node1 or node1,node2).
--replica-countnumber1Number of relay replicas to deploy.
--chain-idstring298EVM chain ID exposed by the relay (Hedera testnet default).
--force-port-forwardbooleantrueEnable port forwarding for the relay service.
--domain-namestring—Custom domain name for the relay.
--relay-chart-dirstring—Path to a local Hiero JSON-RPC Relay Helm chart directory.
--operator-idstring—Operator account ID for relay transaction signing.
--operator-keystring—Operator private key for relay transaction signing.
--mirror-node-idnumber—ID of the mirror node instance the relay will query.
--mirror-namespacestring—Kubernetes namespace of the mirror node.
--quiet-modebooleanfalseSuppress confirmation prompts.
--values-filestring—Comma-separated Helm chart values file paths for the relay chart.

Block Node Add — blockNode

Flags passed to solo block node add.

Important: The blockNode section is only read when ONE_SHOT_WITH_BLOCK_NODE=true is set in the environment. Otherwise Solo skips the block node add step regardless of whether a blockNode section is present. Version requirements: Consensus node ≥ v0.72.0 and block node ≥ 0.29.0. Use --force to bypass version gating during testing.

FlagTypeDefaultDescription
--release-tagstringcurrent versionHiero block node release tag.
--image-tagstring—Docker image tag to override the Helm chart default.
--enable-ingressbooleanfalseDeploy an ingress controller for the block node.
--domain-namestring—Custom domain name for the block node.
--devbooleanfalseEnable developer mode for the block node.
--block-node-chart-dirstring—Path to a local Hiero block node Helm chart directory.
--quiet-modebooleanfalseSuppress confirmation prompts.
--values-filestring—Comma-separated Helm chart values file paths for the block node chart.

Top-Level Falcon Command Flags

The following flags are passed directly on the solo one-shot falcon deploy command line. They are not read from the values file sections.

FlagTypeDefaultDescription
--values-filestring—Path to the Falcon values YAML file.
--deploymentstringone-shotDeployment name for Solo’s internal state.
--namespacestringone-shotKubernetes namespace to deploy into.
--cluster-refstringone-shotCluster reference name.
--num-consensus-nodesnumber1Number of consensus nodes to deploy.
--parallel-deploybooleantrueRun independent deploy stages in parallel (consensus+block, mirror+accounts, explorer+relay). Use --no-parallel-deploy for sequential execution.
--quiet-modebooleanfalseSuppress all interactive prompts.
--forcebooleanfalseForce actions that would otherwise be skipped.

Falcon Prepare — prepare

Flags accepted by solo one-shot falcon prepare, the interactive wizard that generates a Falcon values file. The wizard prompts for nearly every values-file field, but the following CLI flags control its output behavior directly.

FlagTypeDefaultDescription
--output-values-filestring~/.solo/cache/falcon-values.yamlPath to the generated values file. Absolute paths are written as-is. Relative paths are resolved against the current working directory.
--quiet-modebooleanfalseGenerate a values file using all defaults without prompting.

All other prepare-time flags correspond directly to the per-section values shown in the tables above and are documented under their respective network, setup, consensusNode, mirrorNode, explorerNode, relayNode, and blockNode sections.

2.2.3 - Step-by-Step Manual Deployment

Deploy each Solo network component individually for maximum control over configuration and debugging. Execute each step manually through the Solo CLI and integrate Solo into bespoke automation pipelines.

Overview

Manual deployment lets you deploy each Solo network component individually, giving you full control over configuration, sequencing, and troubleshooting. Use this approach when you need to customise specific steps, debug a component in isolation, or integrate Solo into a bespoke automation pipeline.

Prerequisites

Before proceeding, ensure you have completed the following:

  • System Readiness — your local environment meets all hardware and software requirements (Docker, kind, kubectl, helm, Solo).
  • Quickstart — you have a running Kind cluster.
  • Set your environment variables if you have not already done so:
export SOLO_CLUSTER_NAME=solo
export SOLO_NAMESPACE=solo-deployment
export SOLO_CLUSTER_SETUP_NAMESPACE=solo-cluster
export SOLO_DEPLOYMENT=solo-deployment

$env:SOLO_CLUSTER_NAME = 'solo'
$env:SOLO_NAMESPACE = 'solo-deployment'
$env:SOLO_CLUSTER_SETUP_NAMESPACE = 'solo-cluster'
$env:SOLO_DEPLOYMENT = 'solo-deployment'

Deployment Steps

Note: The expected output blocks below are fetched from the latest published Solo release at build time and will always reflect the current version.

1. Connect Cluster and Create Deployment

  • Connect Solo to the Kind cluster and create a new deployment configuration:

    # Connect to the Kind cluster
solo cluster-ref config connect \
  --cluster-ref kind-${SOLO_CLUSTER_NAME} \
  --context kind-${SOLO_CLUSTER_NAME}

# Create a new deployment
solo deployment config create \
  -n "${SOLO_NAMESPACE}" \
  --deployment "${SOLO_DEPLOYMENT}"

  • Expected Output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: cluster-ref config connect --cluster-ref kind-solo --context kind-solo
  **********************************************************************************
  ❯ Initialize
  ✔ Initialize 
  ❯ Validating cluster ref: 
  ✔ Validating cluster ref: kind-solo 
  ❯ Test connection to cluster: 
  ✔ Test connection to cluster: kind-solo 
  ❯ Associate a context with a cluster reference: 
  ✔ Associate a context with a cluster reference: kind-solo 
  • ******************************* Solo *********************************************
Version			: 0.80.0
Kubernetes Context	: kind-solo
Kubernetes Cluster	: kind-solo
Current Command		: deployment config create --namespace solo --deployment solo-deployment --realm 0 --shard 0
Kubernetes Namespace	: solo
**********************************************************************************
❯ Initialize
✔ Initialize 
❯ Add deployment to local config
✔ Adding deployment: solo-deployment with namespace: solo to local config

2. Add Cluster to Deployment

  • Attach the cluster to your deployment and specify the number of consensus nodes:

    1. Single node:

    solo deployment cluster attach \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref kind-${SOLO_CLUSTER_NAME} \
  --num-consensus-nodes 1

    2. Multiple nodes (e.g., –num-consensus-nodes 3):

    solo deployment cluster attach \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref kind-${SOLO_CLUSTER_NAME} \
  --num-consensus-nodes 3

  • Expected Output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: deployment cluster attach --deployment solo-deployment --cluster-ref kind-solo --num-consensus-nodes 1
  **********************************************************************************
  ❯ Pre-flight: check Docker Desktop containerd setting
  ✔ Pre-flight: check Docker Desktop containerd setting 
  ❯ Check dependencies
  ❯ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ✔ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependencies 
  ❯ Setup chart manager
  ✔ Setup chart manager [0.7s]
  ❯ Initialize
  ✔ Initialize 
  ❯ Verify args
  ✔ Verify args 
  ❯ check ledger phase
  ✔ check ledger phase 
  ❯ Test cluster reference connection
  ✔ Test cluster reference connection: kind-solo, context: kind-solo 
  ❯ Verify prerequisites
  ✔ Verify prerequisites 
  ❯ Check for other deployments
  ✔ Check for other deployments 
  ❯ add cluster-ref in local config deployments
  Adding cluster-ref: kind-solo for deployment: solo-deployment in local config
  ✔ add cluster-ref: kind-solo for deployment: solo-deployment in local config 
  ❯ create remote config for deployment
  ✔ create remote config for deployment: solo-deployment in cluster reference: kind-solo

3. Generate Keys

  • Generate the gossip and TLS keys for your consensus nodes:

    solo keys consensus generate \
  --gossip-keys \
  --tls-keys \
  --deployment "${SOLO_DEPLOYMENT}"

    PEM key files are written to ~/.solo/cache/keys/.

  • Expected output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: keys consensus generate --gossip-keys --tls-keys --deployment solo-deployment
  **********************************************************************************
  ❯ Initialize
  ✔ Initialize 
  ❯ Generate gossip keys
  ❯ Backup old files
  ✔ Backup old files 
  ❯ Gossip key for node: node1
  ✔ Gossip key for node: node1 [0.2s]
  ✔ Generate gossip keys [0.2s]
  ❯ Generate gRPC TLS Keys
  ❯ Backup old files
  ❯ TLS key for node: node1
  ✔ Backup old files 
  ✔ TLS key for node: node1 [0.2s]
  ✔ Generate gRPC TLS Keys [0.2s]
  ❯ Finalize
  ✔ Finalize

4. Set Up Cluster with Shared Components

  • Install shared cluster-level components (MinIO Operator, Prometheus CRDs, etc.) into the cluster setup namespace:

    solo cluster-ref config setup --cluster-setup-namespace "${SOLO_CLUSTER_SETUP_NAMESPACE}"

  • Expected output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: cluster-ref config setup --cluster-setup-namespace solo-cluster
  **********************************************************************************
  ❯ Pre-flight: check Docker Desktop containerd setting
  ✔ Pre-flight: check Docker Desktop containerd setting 
  ❯ Check dependencies
  ❯ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ✔ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64] [0.1s]
  ✔ Check dependencies [0.1s]
  ❯ Setup chart manager
  ✔ Setup chart manager [0.7s]
  ❯ Initialize
  ✔ Initialize 
  ❯ Install cluster charts
  ❯ Install pod-monitor-role ClusterRole
  ✅ ClusterRole pod-monitor-role installed successfully in context kind-solo
  ✔ Install pod-monitor-role ClusterRole 
  ❯ Install MinIO Operator chart
  ✅ MinIO Operator chart installed successfully on context kind-solo
  ✔ Install MinIO Operator chart [0.7s]
  ✔ Install cluster charts [0.7s]

5. Deploy the Network

  • Deploy the Solo network Helm chart, which provisions the consensus node pods, HAProxy, Envoy, and MinIO:

    solo consensus network deploy --deployment "${SOLO_DEPLOYMENT}"

    To provide a custom consensus node application.properties file, pass --application-properties <path>. Solo merges custom files with its generated defaults unless the file includes the overwrite marker. See Custom Application Properties for merge and overwrite examples.

  • Expected output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: consensus network deploy --deployment solo-deployment --consensus-node-version v0.74.0
  **********************************************************************************
  ❯ Pre-flight: check Docker Desktop containerd setting
  ✔ Pre-flight: check Docker Desktop containerd setting 
  ❯ Check dependencies
  ❯ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ✔ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64] [0.1s]
  ✔ Check dependencies [0.1s]
  ❯ Setup chart manager
  ✔ Setup chart manager [0.6s]
  ❯ Initialize
  ❯ Acquire lock
  ✔ Acquire lock - lock acquired successfully, attempt: 1/10 
  ✔ Initialize [0.2s]
  ❯ Copy gRPC TLS Certificates
  ↓ Copy gRPC TLS Certificates [SKIPPED: Copy gRPC TLS Certificates]
  ❯ Prepare staging directory
  ❯ Copy Gossip keys to staging
  ✔ Copy Gossip keys to staging 
  ❯ Copy gRPC TLS keys to staging
  ✔ Copy gRPC TLS keys to staging 
  ✔ Prepare staging directory 
  ❯ Copy node keys to secrets
  ❯ Copy TLS keys
  ❯ Node: node1, cluster: kind-solo
  ❯ Copy Gossip keys
  ✔ Copy TLS keys 
  ✔ Copy Gossip keys 
  ✔ Node: node1, cluster: kind-solo 
  ✔ Copy node keys to secrets 
  ❯ Install monitoring CRDs
  ❯ Pod Logs CRDs
  ❯ Prometheus Operator CRDs
  ✔ Pod Logs CRDs 
   - Installed prometheus-operator-crds chart, version: 24.0.2
  ✔ Prometheus Operator CRDs [4s]
  ✔ Install monitoring CRDs [4s]
  ❯ Install chart 'solo-deployment'
   - Installed solo-deployment chart, version: 0.64.0
  ✔ Install chart 'solo-deployment' [2s]
  ❯ Patch ServiceMonitor for Prometheus discovery
  ✔ Patch ServiceMonitor for Prometheus discovery 
  ❯ Check for load balancer
  ↓ Check for load balancer [SKIPPED: Check for load balancer]
  ❯ Redeploy chart with external IP address config
  ↓ Redeploy chart with external IP address config [SKIPPED: Redeploy chart with external IP address config]
  ❯ Check node pods are running
  ❯ Check Node: node1, Cluster: kind-solo
  ✔ Check Node: node1, Cluster: kind-solo [22s]
  ✔ Check node pods are running [22s]
  ❯ Check proxy pods are running
  ❯ Check HAProxy for: node1, cluster: kind-solo
  ❯ Check Envoy Proxy for: node1, cluster: kind-solo
  ✔ Check HAProxy for: node1, cluster: kind-solo 
  ✔ Check Envoy Proxy for: node1, cluster: kind-solo 
  ✔ Check proxy pods are running 
  ❯ Check auxiliary pods are ready
  ❯ Check MinIO
  ↓ Check MinIO [SKIPPED: Check MinIO]
  ✔ Check auxiliary pods are ready 
  ❯ Add node and proxies to remote config
  ✔ Add node and proxies to remote config 
  ❯ Copy wraps lib into consensus node
  ↓ Copy wraps lib into consensus node [SKIPPED: Copy wraps lib into consensus node]
  ❯ Copy block-nodes.json
  ✔ Copy block-nodes.json [0.7s]
  ❯ Copy JFR config file to nodes
  ↓ Copy JFR config file to nodes [SKIPPED: Copy JFR config file to nodes]

6. Set Up Consensus Nodes

  • Download the consensus node platform software and configure each node:

    export CONSENSUS_NODE_VERSION=v0.66.0

solo consensus node setup \
  --deployment "${SOLO_DEPLOYMENT}" \
  --release-tag "${CONSENSUS_NODE_VERSION}"

    On native Windows (PowerShell), set the version with $env:CONSENSUS_NODE_VERSION = 'v0.66.0' and reference variables as $env:SOLO_DEPLOYMENT / $env:CONSENSUS_NODE_VERSION.

  • Example output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: consensus node setup --deployment solo-deployment --consensus-node-version v0.74.0
  **********************************************************************************
  ❯ Load configuration
  ✔ Load configuration [0.2s]
  ❯ Initialize
  ✔ Initialize [0.2s]
  ❯ Validate nodes states
  ❯ Validating state for node node1
  ✔ Validating state for node node1 - valid state: requested 
  ✔ Validate nodes states 
  ❯ Identify network pods
  ❯ Check network pod: node1
  ✔ Check network pod: node1 
  ✔ Identify network pods 
  ❯ Fetch platform software into network nodes
  ❯ Update node: node1 [ platformVersion = v0.74.0, context = kind-solo ]
  ✔ Update node: node1 [ platformVersion = v0.74.0, context = kind-solo ] [2s]
  ✔ Fetch platform software into network nodes [4s]
  ❯ Setup network nodes
  ❯ Node: node1
  ❯ Copy configuration files
  ✔ Copy configuration files [0.5s]
  ❯ Set file permissions
  ✔ Set file permissions [0.4s]
  ✔ Node: node1 [1s]
  ✔ Setup network nodes [1s]
  ❯ Update block-nodes.json
  ✔ Update block-nodes.json [0.7s]
  ❯ setup network node folders
  ✔ setup network node folders [0.1s]
  ❯ Change node state to configured in remote config
  ✔ Change node state to configured in remote config

7. Start Consensus Nodes

  • Start all configured nodes and wait for them to reach ACTIVE status:

    solo consensus node start --deployment "${SOLO_DEPLOYMENT}"

  • Expected output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: consensus node start --deployment solo-deployment
  **********************************************************************************
  ❯ Pre-flight: check Docker Desktop containerd setting
  ✔ Pre-flight: check Docker Desktop containerd setting 
  ❯ Check dependencies
  ❯ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ✔ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependencies 
  ❯ Setup chart manager
  ✔ Setup chart manager [0.7s]
  ❯ Load configuration
  ✔ Load configuration [0.3s]
  ❯ Initialize
  ✔ Initialize 
  ❯ Validate nodes states
  ❯ Validating state for node node1
  ✔ Validating state for node node1 - valid state: configured 
  ✔ Validate nodes states 
  ❯ Identify existing network nodes
  ❯ Check network pod: node1
  ✔ Check network pod: node1 
  ✔ Identify existing network nodes 
  ❯ Upload state files network nodes
  ↓ Upload state files network nodes [SKIPPED: Upload state files network nodes]
  ❯ Starting nodes
  ❯ Start node: node1
  ✔ Start node: node1 [1s]
  ✔ Starting nodes [1s]
  ❯ Enable port forwarding for debug port and/or GRPC port
  Using requested port 35211
  ✔ Enable port forwarding for debug port and/or GRPC port 
  ❯ Check nodes are ACTIVE and proxies are ready
  ❯ Check all nodes are ACTIVE
  ❯ Check node proxies are ACTIVE
  ❯ Check proxy for node: node1
  ❯ Check network pod: node1 
  ✔ Check proxy for node: node1 
  ✔ Check node proxies are ACTIVE 
  Using requested port 30212
  Stopping port-forward for port [30212]
  Using requested port 30212
  Stopping port-forward for port [30212]
  Using requested port 30212
  ✔ Check network pod: node1  - gRPC readiness 3/3, attempt: 2/20 [40s]
  ✔ Check all nodes are ACTIVE [40s]
  ✔ Check nodes are ACTIVE and proxies are ready [40s]
  ❯ Wait for TSS
  ❯ Waiting for node: node1
  ✔ Waiting for node: node1, attempt 1/60 [10s]
  ✔ Wait for TSS [10s]
  ❯ set gRPC Web endpoint
  Stopping port-forward for port [30212]
  Using requested port 30212
  ✔ set gRPC Web endpoint [4s]
  ❯ Change node state to started in remote config
  ✔ Change node state to started in remote config 
  ❯ Add node stakes
  ❯ Adding stake for node: node1
  ✔ Adding stake for node: node1 [2s]
  ✔ Add node stakes [2s]
  ❯ Emit node started event
  ✔ Emit node started event 
  Stopping port-forward for port [30212]

8. Deploy Mirror Node

  • Deploy the Hedera Mirror Node, which indexes all transaction data and exposes a REST API and gRPC endpoint:

    solo mirror node add \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref kind-${SOLO_CLUSTER_NAME} \
  --enable-ingress \
  --pinger

    The --pinger flag keeps the mirror node’s importer active by regularly submitting record files. The --enable-ingress flag installs the HAProxy ingress controller for the mirror node REST API.

  • Expected output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: mirror node add --deployment solo-deployment --cluster-ref kind-solo --enable-ingress --quiet-mode
  **********************************************************************************
  ❯ Pre-flight: check Docker Desktop containerd setting
  ✔ Pre-flight: check Docker Desktop containerd setting 
  ❯ Check dependencies
  ❯ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ✔ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependencies 
  ❯ Setup chart manager
  ✔ Setup chart manager [0.7s]
  ❯ Initialize
  ❯ Acquire lock
  ✔ Acquire lock - lock acquired successfully, attempt: 1/10 
  ✔ Initialize [0.4s]
  ❯ Add mirror node to remote config
  ✔ Add mirror node to remote config 
  ❯ load node client
  Using requested port 30212
  ✔ load node client [1s]
  ❯ Deploy charts
  ❯ Enable shared resources
  ❯ Install Shared Resources chart
  ✔ Install Shared Resources chart [3s]
  ❯ Load redis credentials
  ✔ Load redis credentials 
  ❯ Initialize Postgres pod
  ❯ Wait for Postgres pod to be ready
  ✔ Wait for Postgres pod to be ready [11s]
  ✔ Initialize Postgres pod [11s]
  ❯ Add shared resource components to remote config
  ✔ Add shared resource components to remote config 
  ✔ Enable shared resources [14s]
  ❯ Prime mirror-node postgres secret
  ✔ Prime mirror-node postgres secret [0.7s]
  ❯ Delete stale mirror redis secret
  ✔ Delete stale mirror redis secret 
  ❯ Run database initialization script
  ✔ Run database initialization script [1s]
  ❯ Enable mirror-node
  ❯ Prepare address book
  ✔ Prepare address book 
  ❯ Install mirror ingress controller
   - Installed haproxy-ingress-1 chart, version: 0.14.5
  ✔ Install mirror ingress controller [0.7s]
  ❯ Deploy mirror-node
   - Installed mirror chart, version: v0.157.0
  ✔ Deploy mirror-node [2s]
  ✔ Enable mirror-node [3s]
  ✔ Deploy charts [20s]
  ❯ Check pods are ready
  ❯ Check Grpc
  ❯ Check Importer
  ❯ Check Rest
  ❯ Check Rest Java
  ❯ Check Web3
  ✔ Check Rest Java [10s]
  ✔ Check Web3 [14s]
  ✔ Check Grpc [18s]
  ✔ Check Importer [18s]
  ✔ Check Rest [20s]
  ✔ Check pods are ready [20s]
  ❯ Enable port forwarding for mirror ingress controller
  Using requested port 38081
  ✔ Enable port forwarding for mirror ingress controller 
  ❯ Show user messages
  
   *** Port forwarding enabled: ***
  -------------------------------------------------------------------------------
   - Mirror ingress controller port forward enabled on 127.0.0.1:38081
  -------------------------------------------------------------------------------
  ✔ Show user messages 
  Stopping port-forward for port [30212]

9. Deploy Explorer

  • Deploy the Hiero Explorer, a web UI for browsing transactions and accounts:

    solo explorer node add \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref kind-${SOLO_CLUSTER_NAME}

  • Expected output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: explorer node add --deployment solo-deployment --cluster-ref kind-solo --quiet-mode
  **********************************************************************************
  ❯ Pre-flight: check Docker Desktop containerd setting
  ✔ Pre-flight: check Docker Desktop containerd setting 
  ❯ Check dependencies
  ❯ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ✔ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependencies 
  ❯ Setup chart manager
  ✔ Setup chart manager [0.7s]
  ❯ Initialize
  ❯ Acquire lock
  ✔ Acquire lock - lock acquired successfully, attempt: 1/10 
  ✔ Initialize [0.4s]
  ❯ Load remote config
  ✔ Load remote config [0.1s]
  ❯ Add explorer to remote config
  ✔ Add explorer to remote config 
  ❯ Install cert manager
  ↓ Install cert manager [SKIPPED: Install cert manager]
  ❯ Install explorer
   - Installed hiero-explorer-1 chart, version: 26.1.0
  ✔ Install explorer [0.7s]
  ❯ Install explorer ingress controller
  ↓ Install explorer ingress controller [SKIPPED: Install explorer ingress controller]
  ❯ Check explorer pod is ready
  ✔ Check explorer pod is ready [4s]
  ❯ Check haproxy ingress controller pod is ready
  ↓ Check haproxy ingress controller pod is ready [SKIPPED: Check haproxy ingress controller pod is ready]
  ❯ Enable port forwarding for explorer
  No port forward config found for Explorer
  Using requested port 38080
  ✔ Enable port forwarding for explorer 
  ❯ Show user messages
  
   *** Port forwarding enabled: ***
  -------------------------------------------------------------------------------
   - Explorer port forward enabled on 127.0.0.1:38080
  -------------------------------------------------------------------------------
  ✔ Show user messages

10. Deploy JSON-RPC Relay

  • Deploy the Hiero JSON-RPC Relay to expose an Ethereum-compatible JSON-RPC endpoint for EVM tooling (MetaMask, Hardhat, Foundry, etc.):

    solo relay node add \
  -i node1 \
  --deployment "${SOLO_DEPLOYMENT}"

TODO: double check these, and update in solo repo if needed to match, also double check the exported variables match

  • Expected output:

    ******************************* Solo *********************************************
  Version			: 0.80.0
  Kubernetes Context	: kind-solo
  Kubernetes Cluster	: kind-solo
  Current Command		: relay node add --node-aliases node1 --deployment solo-deployment --cluster-ref kind-solo --relay-version 0.77.0
  **********************************************************************************
  ❯ Pre-flight: check Docker Desktop containerd setting
  ✔ Pre-flight: check Docker Desktop containerd setting 
  ❯ Check dependencies
  ❯ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ❯ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64]
  ✔ Check dependency: kind [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: helm [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependency: kubectl [OS: linux, Release: 6.8.0-117-generic, Arch: x64] 
  ✔ Check dependencies 
  ❯ Setup chart manager
  ✔ Setup chart manager [0.8s]
  ❯ Initialize
  ❯ Acquire lock
  ✔ Acquire lock - lock acquired successfully, attempt: 1/10 
  ✔ Initialize [0.4s]
  ❯ Add relay component in remote config
  ✔ Add relay component in remote config 
  ❯ Check chart is installed
  ✔ Check chart is installed [0.1s]
  ❯ Prepare chart values
  ✔ Prepare chart values 
  ❯ Deploy JSON RPC Relay
   - Installed relay-1 chart, version: 0.77.0
  ✔ Deploy JSON RPC Relay [0.6s]
  ❯ Check relay is running
  ✔ Check relay is running [4s]
  ❯ Check relay is ready
  ✔ Check relay is ready [3s]
  ❯ Enable port forwarding for relay node
  No port forward config found for JSON RPC Relay
  Using requested port 37546
  ✔ Enable port forwarding for relay node 
  ❯ Show user messages
  
   *** Port forwarding enabled: ***
  -------------------------------------------------------------------------------
   - JSON RPC Relay port forward enabled on 127.0.0.1:37546
  -------------------------------------------------------------------------------
  ✔ Show user messages

Cleanup

When you are done, destroy components in the reverse order of deployment.

Important: Always destroy components before destroying the network. Skipping this order can leave orphaned Helm releases and PVCs in your cluster.

1. Destroy JSON-RPC Relay

solo relay node destroy \
  -i node1 \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref kind-${SOLO_CLUSTER_NAME}

2. Destroy Explorer

solo explorer node destroy \
  --deployment "${SOLO_DEPLOYMENT}" \
  --force

3. Destroy Mirror Node

solo mirror node destroy \
  --deployment "${SOLO_DEPLOYMENT}" \
  --force

4. Destroy the Network

solo consensus network destroy \
  --deployment "${SOLO_DEPLOYMENT}" \
  --force

2.2.4 - Custom Application Properties

Configure consensus node application.properties with Solo’s default merge mode or full overwrite mode.

Overview

Solo lets you provide a custom application.properties file for consensus nodes with the --application-properties flag. By default, Solo merges your file with its generated defaults. If you need complete control over the final file, add an overwrite marker to your custom file.

Use the default merge mode when you only need to change or add a few properties. Use overwrite mode only when you want your file to replace Solo’s generated application.properties content.

Default merge mode

Pass your file to solo consensus network deploy:

solo consensus network deploy \
  --deployment "${SOLO_DEPLOYMENT}" \
  --application-properties ./config/application.properties

In merge mode, Solo starts with its generated application.properties, then applies your file as key-level overrides:

  • If your file contains a key that already exists in Solo’s generated file, Solo replaces that key’s value.
  • If your file contains a new key, Solo appends it to the final file.
  • Blank lines and comments in your file are ignored during the merge.
  • Solo-generated keys that you do not mention remain in the final file.

Example custom file for merge mode:

# Override only the properties that need to change.
contracts.chainId=298
hedera.recordStream.logPeriod=1

This is the recommended mode for most deployments because Solo keeps its generated defaults while still applying your overrides.

Overwrite mode

To replace Solo’s generated application.properties file, add the overwrite marker as a comment in your custom file:

# SOLO_ENABLE_OVERWRITE=true

contracts.chainId=298
hedera.recordStream.logPeriod=1
# Include every other property your consensus nodes require.

Then deploy with the same flag:

solo consensus network deploy \
  --deployment "${SOLO_DEPLOYMENT}" \
  --application-properties ./config/application.properties

The marker must be on a comment line that starts with #. Solo looks for the exact text SOLO_ENABLE_OVERWRITE=true inside a comment. If the marker is missing, or if it is written as a normal property instead of a comment, Solo uses default merge mode.

In overwrite mode, your file becomes the full application.properties content. Solo does not carry over defaults that are missing from your file, so include all properties required by the consensus node version and deployment topology you are running.

Falcon values file

For One-shot Falcon deployments, put the same flag under the network section:

network:
  --application-properties: "./config/application.properties"

The merge or overwrite behavior is still controlled by the contents of the referenced application.properties file. Add # SOLO_ENABLE_OVERWRITE=true to that file only when you want overwrite mode.

For the complete list of Falcon network flags, see the Falcon Values File Reference.

2.2.5 - Dynamically add, update, and remove Consensus Nodes

Learn how to dynamically add, update, and remove consensus nodes in a running Solo network without taking the network offline. Execute operations independently while the network remains operational.

Overview

This guide covers how to dynamically manage consensus nodes in a running Solo network - adding new nodes, updating existing ones, and removing nodes that are no longer needed. All three operations can be performed without taking the network offline.

Prerequisites

Before proceeding, ensure you have:

  • A running Solo network. If you don’t have one, deploy using one of the following methods:

    1. Quickstart - single command deployment using solo one-shot single deploy.
    2. Manual Deployment - step-by-step deployment with full control over each component.

  • Set the required environment variables as described below:

export SOLO_CLUSTER_NAME=solo
export SOLO_NAMESPACE=solo-deployment
export SOLO_CLUSTER_SETUP_NAMESPACE=solo-cluster
export SOLO_DEPLOYMENT=solo-deployment

$env:SOLO_CLUSTER_NAME = 'solo'
$env:SOLO_NAMESPACE = 'solo-deployment'
$env:SOLO_CLUSTER_SETUP_NAMESPACE = 'solo-cluster'
$env:SOLO_DEPLOYMENT = 'solo-deployment'

Key and Storage Concepts

Before running any node operation, it helps to understand two concepts that appear in the prepare step.

  1. Cryptographic Keys

    Solo generates two types of keys for each consensus node:

    • Gossip keys — used for encrypted node-to-node communication within the network. Stored as s-private-node*.pem and s-public-node*.pem under ~/.solo/cache/keys/.
    • TLS keys — used to secure gRPC connections to the node. Stored as hedera-node*.crt and hedera-node*.key under ~/.solo/cache/keys/.

    When adding a new node, Solo generates a fresh key pair and stores it alongside the keys for existing nodes in the same directory. For more detail, see Where are my keys stored?.

  2. Persistent Volume Claims (PVCs)

    By default, consensus node storage is ephemeral - data stored by a node is lost if its pod crashes or is restarted. This is intentional for lightweight local testing where persistence is not required.

    The --pvcs true flag creates Persistent Volume Claims (PVCs) for the node, ensuring its state survives pod restarts. Enable this flag for any node that needs to persist across restarts or that will participate in longer-running test scenarios.

    Note: PVCs are not enabled by default. Enable them only if your node needs to persist state across pod restarts.

  3. Staging Directory

    The --output-dir context flag specifies a local staging directory where Solo writes all artifacts produced during prepare. Solo’s working files are stored under ~/.solo/ — if you use a relative path like context, the directory is created in your current working directory. Do not delete it until execute has completed successfully.

Adding a Node to an Existing Network

You can dynamically add a new consensus node to a running network without taking the network offline. This process involves three stages: preparing the node’s keys and configuration, submitting the on-chain transaction, and executing the addition.

Step 1: Prepare the new node

Generate the new node’s gossip and TLS keys, create its persistent volumes, and stage its configuration into an output directory:

solo consensus dev-node-add prepare \
  --gossip-keys true \
  --tls-keys true \
  --deployment "${SOLO_DEPLOYMENT}" \
  --pvcs true \
  --admin-key <admin-key> \
  --node-alias node2 \
  --output-dir context
FlagDescription
–gossip-keysGenerate gossip keys for the new node.
–tls-keysGenerate gRPC TLS keys for the new node.
–pvcsCreate persistent volume claims for the new node.
–admin-keyThe admin key used to authorize the node addition transaction.
–node-aliasAlias for the new node (e.g., node2).
–output-dirDirectory where prepared context files are saved for use in subsequent steps.

Step 2: Submit the transaction to add the node

Submit the on-chain transaction to register the new node with the network:

solo consensus dev-node-add submit-transactions \
  --deployment "${SOLO_DEPLOYMENT}" \
  --input-dir context

Step 3: Execute the node addition

Apply the node addition and bring the new node online:

solo consensus dev-node-add execute \
  --deployment "${SOLO_DEPLOYMENT}" \
  --input-dir context

Note: For a complete walkthrough with expected outputs, see the Node Create Transaction example.

Updating a Node

You can update an existing consensus node - for example, to upgrade its software version or modify its configuration - without removing it from the network.

Step 1: Prepare the update

Stage the updated configuration and any new software version for the target node:

solo consensus dev-node-update prepare \
  --deployment "${SOLO_DEPLOYMENT}" \
  --node-alias node1 \
  --release-tag v0.66.0 \
  --output-dir context
FlagDescription
–node-aliasAlias of the node to update (e.g., node1).
–release-tagThe consensus node software version to update to.
–new-admin-key(Optional) New admin key for the node’s Hedera account. Omit to keep the existing admin key.
–output-dirDirectory where prepared context files are saved for use in subsequent steps.

Step 2: Submit the update transaction

Submit the on-chain transaction to register the node update with the network:

solo consensus dev-node-update submit-transactions \
  --deployment "${SOLO_DEPLOYMENT}" \
  --input-dir context

Step 3: Execute the update

Apply the update and restart the node with the new configuration:

solo consensus dev-node-update execute \
  --deployment "${SOLO_DEPLOYMENT}" \
  --input-dir context

Note: For a complete walkthrough with expected outputs, see the Node Update Transaction example.

Removing a Node from a Network

You can dynamically remove a consensus node from a running network without taking the remaining nodes offline.

Note: Removing a node permanently reduces the number of consensus nodes in the network. Ensure the remaining nodes meet the minimum threshold required for consensus before proceeding.

Step 1: Prepare the Node for Deletion

Stage the deletion context for the target node:

solo consensus dev-node-delete prepare \
  --deployment "${SOLO_DEPLOYMENT}" \
  --node-alias node2 \
  --output-dir context
FlagDescription
–node-aliasAlias of the node to remove (e.g., node2).
–output-dirDirectory where prepared context files are saved for use in subsequent steps.

Step 2: Submit the delete transaction

Submit the on-chain transaction to deregister the node from the network:

solo consensus dev-node-delete submit-transactions \
  --deployment "${SOLO_DEPLOYMENT}" \
  --input-dir context

Step 3: Execute the deletion

Remove the node and clean up its associated resources:

solo consensus dev-node-delete execute \
  --deployment "${SOLO_DEPLOYMENT}" \
  --input-dir context

Note: For a complete walkthrough with expected outputs, see the Node Delete Transaction example.

2.3 - Attach JVM Debugger and Retrieve Logs

Learn how to attach a JVM debugger to a running Hiero Consensus Node, retrieve logs for analysis, and save and restore network state files along with essential tools for developers and deep-level troubleshooting.

Overview

This guide covers three debugging workflows:

  • Retrieve logs from a running consensus node using k9s or the Solo CLI
  • Attach a JVM debugger in IntelliJ IDEA to a running or restarting node
  • Save and restore network state files to replay scenarios across sessions

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 cluster and are familiar with the basic Solo workflow.

You will also need:

  • k9s installed (brew install k9s)
  • IntelliJ IDEA with a Remote JVM Debug run configuration (for JVM debugging only)
  • A local checkout of hiero-consensus-node that has been built with assemble or build (for JVM debugging only)

1. Retrieve Consensus Node Logs

Using k9s

Run k9s -A in your terminal to open the cluster dashboard, then select one of the network node pods.

k9s pod list showing network nodes

Select the root-container and press s to open a shell inside the container.

k9s container list with root-container highlighted

Navigate to the Hedera application directory to browse logs and configuration:

cd /opt/hgcapp/services-hedera/HapiApp2.0/

From there you can inspect logs and configuration files:

[root@network-node1-0 HapiApp2.0]# ls -ltr data/config/
total 0
lrwxrwxrwx 1 root root 27 Dec  4 02:05 bootstrap.properties -> ..data/bootstrap.properties
lrwxrwxrwx 1 root root 29 Dec  4 02:05 application.properties -> ..data/application.properties
lrwxrwxrwx 1 root root 32 Dec  4 02:05 api-permission.properties -> ..data/api-permission.properties

[root@network-node1-0 HapiApp2.0]# ls -ltr output/
total 1148
-rw-r--r-- 1 hedera hedera       0 Dec  4 02:06 hgcaa.log
-rw-r--r-- 1 hedera hedera       0 Dec  4 02:06 queries.log
drwxr-xr-x 2 hedera hedera    4096 Dec  4 02:06 transaction-state
drwxr-xr-x 2 hedera hedera    4096 Dec  4 02:06 state
-rw-r--r-- 1 hedera hedera     190 Dec  4 02:06 swirlds-vmap.log
drwxr-xr-x 2 hedera hedera    4096 Dec  4 16:01 swirlds-hashstream
-rw-r--r-- 1 hedera hedera 1151446 Dec  4 16:07 swirlds.log

Using the Solo CLI (Alternative option)

To download hgcaa.log and swirlds.log as a zip archive without entering the container shell, run:

# Downloads logs to ~/.solo/logs/<namespace>/<timestamp>
solo deployment diagnostics all --deployment solo-deployment

2. Attach a JVM Debugger in IntelliJ IDEA

Solo supports pausing node startup at a JDWP debug port so you can attach IntelliJ IDEA before the node begins processing transactions.

Configure IntelliJ IDEA

Create a Remote JVM Debug run configuration in IntelliJ IDEA.

For the Hedera Node application:

IntelliJ Remote JVM Debug configuration for hedera-app

If you are working on the Platform test application instead:

IntelliJ Remote JVM Debug configuration for platform-app

Set any breakpoints you need before launching the Solo command in the next step.

Note: The local-build-path in the commands below references ../hiero-consensus-node/hedera-node/data. Adjust this path to match your local checkout location. Ensure the directory is up to date by running ./gradlew assemble in the hiero-consensus-node repo before proceeding.

Example 1 — Debug a node during initial network deployment

This example deploys a three-node network and pauses node2 for debugger attachment.

SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-deployment
SOLO_CLUSTER_SETUP_NAMESPACE=solo-setup
SOLO_DEPLOYMENT=solo-deployment

# Remove any previous state to avoid name collision issues
rm -Rf ~/.solo
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"

solo cluster-ref config setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref config connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}

solo deployment config create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment cluster attach --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo keys consensus generate --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3

solo consensus network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --debug-node-alias node2
solo consensus node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo consensus node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --debug-node-alias node2

When Solo reaches the active-check phase for node2, it pauses and displays:

❯ Check all nodes are ACTIVE
  Check node: node1,
  Check node: node2,  Please attach JVM debugger now.
  Check node: node3,
? JVM debugger setup for node2. Continue when debugging is complete? (y/N)

At this point, launch the remote debug configuration in IntelliJ IDEA. The node will stop at your breakpoint:

Hedera node stopped at a breakpoint in IntelliJ

Platform app stopped at a breakpoint in IntelliJ

When you are done debugging, resume execution in IntelliJ, then type y in the terminal to allow Solo to continue.

Example 2 — Debug a node during a node add operation

This example starts a three-node network and then attaches a debugger while adding node4.

SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-deployment
SOLO_CLUSTER_SETUP_NAMESPACE=solo-setup
SOLO_DEPLOYMENT=solo-deployment

rm -Rf ~/.solo
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"

solo cluster-ref config setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref config connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}

solo deployment config create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment cluster attach --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo keys consensus generate --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3

solo consensus network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --pvcs
solo consensus node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo consensus node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3

solo consensus node add --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys \
  --debug-node-alias node4 \
  --local-build-path ../hiero-consensus-node/hedera-node/data \
  --pvcs

Example 3 — Debug a node during a node update operation

This example attaches a debugger to node2 while it restarts as part of an update operation.

SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-deployment
SOLO_CLUSTER_SETUP_NAMESPACE=solo-setup
SOLO_DEPLOYMENT=solo-deployment

rm -Rf ~/.solo
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"

solo cluster-ref config setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref config connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}

solo deployment config create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment cluster attach --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo keys consensus generate --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3

solo consensus network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo consensus node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo consensus node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3

solo consensus node update --deployment "${SOLO_DEPLOYMENT}" \
  --node-alias node2 \
  --debug-node-alias node2 \
  --local-build-path ../hiero-consensus-node/hedera-node/data \
  --new-account-number 0.0.7 \
  --gossip-public-key ./s-public-node2.pem \
  --gossip-private-key ./s-private-node2.pem \
  --release-tag v0.71.0

Example 4 — Debug a node during a node delete operation

This example attaches a debugger to node3 while node2 is being removed from the network.

SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-deployment
SOLO_CLUSTER_SETUP_NAMESPACE=solo-setup
SOLO_DEPLOYMENT=solo-deployment

rm -Rf ~/.solo
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"

solo cluster-ref config setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref config connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}

solo deployment config create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment cluster attach --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo keys consensus generate --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3

solo consensus network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo consensus node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo consensus node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3

solo consensus node destroy --deployment "${SOLO_DEPLOYMENT}" \
  --node-alias node2 \
  --debug-node-alias node3 \
  --local-build-path ../hiero-consensus-node/hedera-node/data

3. Save and Restore Network State

You can snapshot the state of a running network and restore it later. This is useful for replaying specific scenarios or sharing reproducible test cases with the team.

Save state

Stop the nodes first, then download the state archives:

# Stop all nodes before downloading state
solo consensus node stop --deployment "${SOLO_DEPLOYMENT}"

# Download state files to ~/.solo/logs/<namespace>/
solo consensus state download -i node1,node2,node3 --deployment "${SOLO_DEPLOYMENT}"

The state files are saved under ~/.solo/logs/:

└── logs
    ├── solo-deployment
    │   ├── network-node1-0-state.zip
    │   └── network-node2-0-state.zip
    └── solo.log

Restore state

Create a fresh cluster, deploy the network, then upload the saved state before starting the nodes:

SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-deployment
SOLO_CLUSTER_SETUP_NAMESPACE=solo-setup
SOLO_DEPLOYMENT=solo-deployment

rm -Rf ~/.solo
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"

solo cluster-ref config setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref config connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}

solo deployment config create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment cluster attach --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo keys consensus generate --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3

solo consensus network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo consensus node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo consensus node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo consensus node stop --deployment "${SOLO_DEPLOYMENT}"

# Upload previously saved state files
solo consensus node state download  -i node1,node2,node3 --deployment "${SOLO_DEPLOYMENT}"

# Restart the network using the uploaded state
solo consensus node start --deployment "${SOLO_DEPLOYMENT}" --state-file network-node1-0-state.zip

2.4 - One-Shot Deploy with Custom Component Versions

Use the –edge flag and *_EDGE_VERSION environment variables to deploy a Solo network against arbitrary component versions — release candidates, pre-releases, or local builds — without modifying Solo source or rebuilding the CLI.

Overview

Solo’s one-shot single deploy and one-shot multi deploy commands accept an --edge flag that switches every component from its built-in stable default to a separate set of “edge” versions. Each edge version is read from an environment variable at startup, so you can pin any component to any tag the container registry exposes — including release candidates and unreleased builds — without editing Solo source or rebuilding the CLI.

Use this guide when you need to:

  • Test a Hiero Consensus Node release candidate against the rest of the Solo-managed stack.
  • Reproduce a specific component version combination for a bug report or regression test.
  • Iterate on a single component (Mirror Node, Relay, Explorer, …) while the other components stay on stable defaults.

For the canonical list of *_EDGE_VERSION variables, see Edge Component Versions in the environment variables reference.

Local binary builds vs published version overrides: --edge and *_EDGE_VERSION variables pin components to published container image tags — they require the image to exist in the registry. If you need to deploy a binary you compiled locally (before any tag or release exists), use --local-build-path instead. See Deploying a Local Consensus Node Build.

How It Works

*_EDGE_VERSION env var (e.g. CONSENSUS_NODE_EDGE_VERSION)
      │
      ▼
solo one-shot ... deploy --edge
      │
      ▼
Each component is pinned to its edge version for this deploy.
Components without an explicit override fall back to the compiled-in
edge defaults, which themselves fall back to the stable defaults.
  • Without --edge, Solo uses the stable defaults compiled into the CLI.
  • With --edge, Solo reads the *_EDGE_VERSION constants — and any matching environment variable you set in the shell overrides those constants.

You only need to set variables for the components you want to override. All others fall back to their compiled-in defaults.

Image cache: Because you pin versions with environment variables, Solo’s image cache pulls the matching image versions automatically. Pinning a version with a --*-version CLI flag (or in solo.config.yaml) instead does not update the cache — it would pull the default versions and cause a cache miss on first deploy. Use the environment variables shown here to keep the cache aligned with the deployed versions.

Quick Start

Deploy a single-node network with a custom Consensus Node release candidate:

CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1 \
solo one-shot single deploy --edge --dev

What this does:

  • CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1 overrides the consensus node version for this command invocation.
  • --edge tells Solo to read *_EDGE_VERSION variables instead of stable defaults.
  • --dev enables Solo’s developer mode — appropriate for local development, not for production-shaped deployments.
  • Mirror Node, Relay, Explorer, Block Node, and the Solo chart keep their compiled-in edge defaults because no *_EDGE_VERSION was set for them.

Note: If you already have a running one-shot deployment and want to keep it, the command above fails with “A deployment named one-shot already exists” because one-shot is the default deployment name. Pass --deployment <name> --namespace <name> to deploy the edge build alongside the existing one:

CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1 \
solo one-shot single deploy --edge --dev \
  --deployment one-shot-edge --namespace one-shot-edge

Every solo one-shot deploy overwrites ~/.solo/cache/last-one-shot-deployment.txt with its own deployment name. After this command, the cache file points at one-shot-edge, not the original one-shot. Pass --deployment explicitly when running follow-up commands against a specific deployment.

Where to Find Version Tags

Each *_EDGE_VERSION value is a published release tag from the component’s GitHub release page. Pick a tag from the appropriate page below, and match the format the component publishes — a missing or extra v prefix is the most common cause of image-pull failures.

ComponentRelease tagsFormatExample
Consensus Nodehiero-consensus-nodevMAJOR.MINOR.PATCH[-qualifier]v0.74.0-rc.1
Mirror Nodehiero-mirror-nodevMAJOR.MINOR.PATCHv0.153.1
JSON-RPC Relayhiero-json-rpc-relayMAJOR.MINOR.PATCH0.77.0
Explorerhiero-mirror-node-explorerMAJOR.MINOR.PATCH27.0.0
Block Nodehiero-block-nodevMAJOR.MINOR.PATCH[-qualifier]v0.32.0
Solo Charthashgraph/solo-chartsMAJOR.MINOR.PATCH0.64.0

Note: Consensus Node, Mirror Node, and Block Node tags are prefixed with v; Relay, Explorer, and Solo Chart tags are not. The tag must exist in the component’s container registry, otherwise the deploy fails with an image-pull error — see Troubleshooting.

Command Reference

In Solo v0.72.0, --edge is accepted by the single and multi one-shot deploy variants. solo one-shot falcon deploy does not currently accept --edge — use one of the two variants below to test custom component versions.

Single-node deploy

CONSENSUS_NODE_EDGE_VERSION=<version> \
MIRROR_NODE_EDGE_VERSION=<version> \
solo one-shot single deploy --edge [--dev] [other flags]

Multi-node deploy

CONSENSUS_NODE_EDGE_VERSION=<version> \
MIRROR_NODE_EDGE_VERSION=<version> \
solo one-shot multi deploy --edge --num-consensus-nodes 3 [--dev] [other flags]

Examples

Override Consensus Node and Mirror Node

CONSENSUS_NODE_EDGE_VERSION=v0.73.0 \
MIRROR_NODE_EDGE_VERSION=v0.153.1 \
solo one-shot single deploy --edge --dev

Override every component

CONSENSUS_NODE_EDGE_VERSION=v0.73.0 \
MIRROR_NODE_EDGE_VERSION=v0.153.1 \
RELAY_EDGE_VERSION=0.77.0 \
EXPLORER_EDGE_VERSION=27.0.0 \
BLOCK_NODE_EDGE_VERSION=v0.32.0 \
SOLO_CHART_EDGE_VERSION=0.64.0 \
solo one-shot single deploy --edge --dev

Export once, reuse across a development session

If you are iterating and running deploy/destroy/deploy cycles, export the variables so every one-shot command in the shell session picks them up:

export CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1
export MIRROR_NODE_EDGE_VERSION=v0.153.1

solo one-shot single deploy --edge --dev

# Destroy and redeploy without re-typing the variables
solo one-shot single destroy
solo one-shot single deploy --edge --dev

Verifying the Versions in Use

After the deploy starts, confirm the resolved versions in the structured Solo log:

tail -f $HOME/.solo/logs/solo.ndjson | jq '.msg, .version // empty'

Note: Use solo.ndjson (newline-delimited JSON, machine-readable) for jq pipes. The companion solo.log is pino-pretty formatted text and will not parse as JSON.

Inspect the deployed Helm releases and their chart versions:

helm list -A
helm get values <release-name> -n <namespace>

Confirm the consensus node container image tag:

kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

Replace <namespace> with your deployment namespace (default one-shot — see Find your deployment namespace).

Without --edge

Omitting --edge uses the stable defaults compiled into the Solo CLI you are running — any *_EDGE_VERSION variables you have set are ignored for that invocation.

# Stable defaults — *_EDGE_VERSION variables are ignored.
solo one-shot single deploy --dev

If you want to pin versions without using --edge (for example, to test a specific stable release of one component), see Pinning Component Versions in the environment variables reference.

Troubleshooting

The version I set is not being used.

Confirm you passed --edge. Without it, Solo ignores every *_EDGE_VERSION variable and uses the compiled-in stable defaults.

Solo is ignoring my environment variable.

The variable must be exported in (or prefixed to) the same shell process that runs Solo. Verify with:

echo $CONSENSUS_NODE_EDGE_VERSION   # should print your value

If you set the variable inline (FOO=bar solo ...), double-check the variable name is spelled exactly as listed in Edge Component Versions — the names are case-sensitive.

The deploy fails with an image-pull error.

The tag you supplied does not exist in the component’s container registry, or the format is wrong (missing v prefix, extra spaces, …). Cross-check the tag against the official release list for that component before retrying.

The deploy starts but a component crashes immediately.

Different component versions are not guaranteed to be mutually compatible. When mixing edge versions, prefer combinations Solo’s CI already exercises (see the Version Compatibility Reference).

2.5 - Customizing Solo with Tasks

Use the Task runner to deploy and customize Solo networks, then explore maintained GitHub example projects for common workflows.

Overview

The Task tool (task) is a task runner that enables you to deploy and customize Solo networks using infrastructure-as-code patterns. Rather than running individual Solo CLI commands, you can use predefined Taskfile targets to orchestrate complex deployment workflows with a single command.

This guide covers installing the Task tool, understanding available Taskfile targets, and using them to deploy networks with various configurations. It also points to maintained example projects that demonstrate common Solo workflows.

Note: This guide assumes you have cloned the Solo repository and have 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).
  • Quickstart: You are familiar with the basic Solo workflow and the solo one-shot single deploy command.

Tip: Task-based workflows are ideal for developers who want to:

  • Run the same deployment multiple times reliably.
  • Customize network components (add mirror nodes, relays, block nodes, etc.).
  • Use version control to track deployment configurations.
  • Integrate Solo deployments into CI/CD pipelines.

Install the Task Tool

The Task tool is a dependency for using Taskfile targets in the Solo repository. Install it using one of the following methods:

brew install go-task/tap/go-task

Using npm

npm install -g @go-task/cli

Verify the installation:

task --version

Expected output:

Task version: v3.X.X

Using package managers

Visit the Task installation guide for additional installation methods for your operating system.

Understanding the Task Structure

The Solo repository uses a modular Task architecture located in the scripts/ directory:

scripts/
├── Taskfile.yml                    # Main entry point (includes other Taskfiles)
├── Taskfile.scripts.yml            # Core deployment and management tasks
├── Taskfile.examples.yml           # Example project tasks
├── Taskfile.release.yml            # Package publishing tasks
└── [other helper scripts]

How to Run Tasks

From the root directory or any example directory, run:

# Run the default task
task

# Run a specific task
task <task-name>

# Run tasks with variables
task <task-name> -- VAR_NAME=value

Deploy Network Configurations

Basic Network Deployment

Deploy a standalone Hiero Consensus Node network with a single command:

# From the repository root, navigate to scripts directory
cd scripts

# Deploy default network (2 consensus nodes)
task default

This command performs the following actions:

  • Initializes Solo and downloads required dependencies.
  • Creates a local Kubernetes cluster using Kind.
  • Deploys 2 consensus nodes.
  • Sets up gRPC and JSON-RPC endpoints for client access.

Deploy Network with Mirror Node

Deploy a network with a consensus node, mirror node, and Hiero Explorer:

cd scripts

task default-with-mirror

This configuration includes:

ComponentDescription
Consensus Node2 consensus nodes running Hiero
Mirror NodeStores and serves historical transaction data
Explorer UIWeb interface for viewing accounts

Access the Explorer at: http://localhost:38080/localnet/dashboard (Solo 0.63+) or http://localhost:8080/localnet/dashboard (Solo 0.62 and earlier). See Port availability if the port is in use.

Deploy Network with Relay and Explorer

Deploy a network with consensus nodes, mirror node, explorer, and JSON-RPC relay for Ethereum-compatible access:

cd scripts

task default-with-relay

This configuration includes:

ComponentDescription
Consensus Node2 consensus nodes running Hiero
Mirror NodeStores and serves historical transaction data
Explorer UIWeb interface for viewing accounts
JSON-RPC RelayEthereum-compatible JSON-RPC interface

Access the services at (Solo 0.63+ defaults; for Solo 0.62 and earlier use the legacy ports in parentheses):

  • Explorer: http://localhost:38080/localnet/dashboard (legacy: http://localhost:8080/localnet/dashboard)
  • JSON-RPC Relay: http://localhost:37546 (legacy: http://localhost:7546)

See Port availability if a port is already in use on your machine.

Available Taskfile Targets

The Taskfile includes a comprehensive set of targets for deploying and managing Solo networks. Below are the most commonly used targets, organized by category.

Core Deployment Targets

These targets handle the primary deployment lifecycle:

TaskDescription
defaultComplete deployment workflow for Solo
installInitialize cluster, create deployment, and setup consensus net
destroyTear down the consensus network
cleanFull cleanup: destroy network, remove cache, logs, and files
startStart all consensus nodes
stopStop all consensus nodes

Example: Deploy, then clean up

cd scripts

# Deploy the network
task default

# ... (use the network)

# Stop the network
task stop

# Remove all traces of the deployment
task clean

Cache and Log Cleanup

When cleaning up, you can selectively remove specific components:

TaskDescription
clean:cacheRemove the Solo cache directory (~/.solo/cache)
clean:logsRemove the Solo logs directory (~/.solo/logs)
clean:tmpRemove temporary deployment files

Mirror Node Management

Add, configure, or remove mirror nodes from an existing deployment:

TaskDescription
solo:mirror-nodeAdd a mirror node to the current deployment
solo:destroyer-mirror-nodeRemove the mirror node from the deployment

Example: Add mirror node to running network

cd scripts

# Start with a basic network
task default

# Add mirror node later
task solo:mirror-node

# Remove mirror node
task solo:destroyer-mirror-node

Explorer UI Management

Deploy or remove the Hiero Explorer for transaction/account viewing:

TaskDescription
solo:explorerAdd explorer UI to the current deployment
solo:destroy-explorerRemove explorer UI from the deployment

Example: Deploy network with explorer

cd scripts

task default
task solo:explorer

# Access at http://localhost:38080/localnet/dashboard (Solo 0.63+) or http://localhost:8080/localnet/dashboard (Solo 0.62 and earlier)

JSON-RPC Relay Management

Deploy or remove the Relay for Ethereum-compatible access:

TaskDescription
solo:relayAdd JSON-RPC relay to the current deployment
solo:destroy-relayRemove JSON-RPC relay from the deployment

Example: Add relay to running network

cd scripts

task default-with-mirror
task solo:relay

# Access JSON-RPC at http://localhost:37546 (Solo 0.63+) or http://localhost:7546 (Solo 0.62 and earlier)

Block Node Management

Deploy or remove block nodes for streaming block data:

TaskDescription
solo:block:addAdd a block node to the current deployment
solo:block:destroyRemove the block node from the deployment

Example: Deploy network with block node

cd scripts

task default
task solo:block:add

# Block node will stream block data

Infrastructure Tasks

Low-level tasks for managing clusters and network infrastructure:

TaskDescription
cluster:createCreate a Kind (Kubernetes in Docker) cluster
cluster:destroyDelete the Kind cluster
solo:cluster:setupSetup cluster infrastructure and prerequisites
solo:initInitialize Solo (download tools and templates)
solo:deployment:createCreate a new deployment configuration
solo:deployment:attachAttach an existing cluster to a deployment
solo:network:deployDeploy the consensus network to the cluster
solo:network:destroyDestroy the consensus network

Tip: Unless you need custom cluster management, use the higher-level tasks like default, install, or destroy which orchestrate these infrastructure tasks automatically.

Utility Tasks

Helpful tasks for inspecting and managing running networks:

TaskDescription
show:ipsDisplay the external IPs of all network nodes
solo:node:logsRetrieve logs from consensus nodes
solo:freeze:restartExecute a freeze/restart upgrade workflow for testing version upgrades

Example: View network IPs and logs

cd scripts

# See which nodes are running and their IPs
task show:ips

# Retrieve node logs for debugging
task solo:node:logs

Database Tasks

Deploy external databases for specialized configurations:

TaskDescription
solo:external-databaseSetup external PostgreSQL database with Helm

Advanced Configuration with Environment Variables

You can customize Task behavior by setting environment variables before running tasks. Common variables include:

VariableDescriptionDefault
SOLO_NETWORK_SIZENumber of consensus nodes1
SOLO_NAMESPACEKubernetes namespacesolo-e2e
CONSENSUS_NODE_VERSIONConsensus node versionv0.65.1
MIRROR_NODE_VERSIONMirror node versionv0.138.0
RELAY_VERSIONJSON-RPC Relay versionv0.70.0
EXPLORER_VERSIONExplorer UI versionv25.1.1

For a comprehensive reference of all available environment variables, see Using Environment Variables.

Example: Deploy with custom versions

cd scripts

# Deploy with specific component versions
CONSENSUS_NODE_VERSION=v0.66.0 \
MIRROR_NODE_VERSION=v0.139.0 \
task default-with-mirror

Example Projects

The Solo repository includes 14+ maintained example projects that demonstrate common Solo workflows. These examples serve as templates and starting points for custom implementations.

Getting Started with Examples

Each example is located in the examples/ directory and includes:

  • Pre-configured Taskfile.yml with deployment settings.
  • init-containers-values.yaml for customization.
  • Example-specific README with detailed instructions.

To run an example:

cd examples/<example-name>

# Deploy the example
task

# Clean up when done
task clean

Available Examples

Network Setup Examples

Configuration Examples

Database Examples

State Management Examples

Node Transaction Examples

These examples demonstrate manual operations for adding, modifying, and removing nodes:

Integration Examples

Testing Examples

  • Rapid-Fire: Rapid-fire deployment and teardown commands for stress testing the deployment workflow
  • Running Solo Inside Cluster: Deploy Solo within an existing Kubernetes cluster instead of creating a new one

Practical Workflows

Workflow 1: Quick Development Network with Logging

Deploy a network for development and debugging:

cd scripts

# Set logging level (PowerShell: $env:SOLO_LOG_LEVEL = 'debug')
export SOLO_LOG_LEVEL=debug

# Deploy with mirror and relay
task default-with-relay

# Retrieve logs if needed
task solo:node:logs

# View network endpoints
task show:ips

# Clean up
task clean

Workflow 2: Test Configuration Changes

Iterate on network configuration:

cd examples/custom-network-config

# Edit the Taskfile or init-containers-values.yaml

# Deploy with your changes
task

# Test your configuration

# Clean up and try again
task clean

Workflow 3: Upgrade Network Components

Test upgrading Solo components:

cd examples/version-upgrade-test

# Deploy with current versions
task

# The example automatically tests the upgrade path

# Clean up
task clean

Workflow 4: Backup and Restore Network State

Test disaster recovery and state migration:

cd examples/state-save-and-restore

# Deploy initial network with state
task

# The example includes backup/restore operations

# Clean up
task clean

Troubleshooting

Common Issues

Task command not found

Ensure Task is installed and on your PATH:

which task
task --version

Taskfile not found

Run Task commands from the scripts/ directory or an examples/ subdirectory where a Taskfile.yml exists:

cd scripts
task default

Insufficient resources

Some deployments require significant resources. Verify your Docker has at least 12 GB of memory and 6 CPU cores allocated:

docker info --format 'CPU: {{.NCPU}}, Memory: {{.MemTotal | div 1000000000}}GB'

Cluster cleanup issues

If the cluster becomes unstable, perform a full cleanup:

cd scripts

# Remove all traces
task clean

# As a last resort, manually delete the Kind cluster
kind delete cluster --name solo-e2e

Next Steps

After deploying a network with Task, explore:

Additional Resources

2.6 - Solo CI Workflow

Learn how to integrate Solo into a GitHub Actions CI pipeline covering runner requirements, tool installation, and automated network deployment within CI environments. Set up fresh isolated Solo networks for each CI run.

Overview

This guide walks you through integrating Solo into a GitHub Actions CI pipeline - covering runner requirements, tool installation, and automated network deployment. Each step installs dependencies directly in the workflow, since CI runners are fresh environments with no pre-installed tools.

Prerequisites

Before proceeding, ensure you have completed the following:

  • System Readiness — your local environment meets all hardware and software requirements.
  • Quickstart — you are familiar with the basic Solo workflow and the solo one-shot single deploy command.

This guide assumes you are integrating Solo into a GitHub Actions workflow where each runner is a fresh environment. The steps below install all required tools directly inside the workflow rather than relying on pre-installed dependencies.

Runner Requirements

Solo requires a minimum of 6 CPU cores and 12 GB of memory on the runner. If these requirements are not met, Solo components may hang or fail to install during deployment.

Note: The Kubernetes cluster does not have full access to all memory available on the host. Setting Docker to 12 GB of memory means the Kind cluster running inside Docker will have access to less than 12 GB. Memory and CPU utilisation also increase over time as transaction load grows. The requirements above are validated for solo one-shot single deploy as documented in this guide.

To verify that your runner meets these requirements, add the following step to your workflow:

  - name: Check Docker Resources
    run: |
      read cpus mem <<<"$(docker info --format '{{.NCPU}} {{.MemTotal}}')"
      mem_gb=$(awk -v m="$mem" 'BEGIN{printf "%.1f", m/1000000000}')
      echo "CPU cores: $cpus"
      echo "Memory: ${mem_gb} GB"

Expected Output:

  CPU cores: 6
  Memory: 12 GB

Step 1: Set Up Kind

Install Kind to create and manage a local Kubernetes cluster in your workflow.

  - name: Setup Kind
    uses: helm/kind-action@a1b0e391336a6ee6713a0583f8c6240d70863de3
    with:
      install_only: true
      node_image: kindest/node:v1.32.2@sha256:3966f21e12b760f6585bde7140cae5e8cdc0e52b37a6f90ce39834b6e72e3f49
      version: v0.29.0
      kubectl_version: v1.32.2
      verbosity: 3
      wait: 120s

Important: Kind version must be v0.29.0 or later and Kubernetes version must be v1.32.2 or later. Solo enforces this minimum version at runtime. Installing an older version will cause deployment failures.

Step 2: Install Node.js

  - name: Set up Node.js
    uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020
    with:
      node-version: 22.12.0

Step 3: Install Solo CLI

Install the Solo CLI globally using npm.

Important: Always pin the CLI version. Unpinned installs may pick up breaking changes from newer releases and cause unexpected workflow failures.

  - name: Install Solo CLI
    run: |
      set -euo pipefail
      npm install -g @hiero-ledger/solo@<version>
      solo --version
      kind --version

Step 4: Deploy Solo

Deploy a Solo network to your Kind cluster. This command creates and configures a fully functional local Hiero network, including:

  • Consensus Node

  • Mirror Node

  • Mirror Node Explorer

  • JSON-RPC Relay

      - name: Deploy Solo
    env:
      SOLO_CLUSTER_NAME: solo
      SOLO_NAMESPACE: one-shot
      SOLO_CLUSTER_SETUP_NAMESPACE: solo-cluster
      SOLO_DEPLOYMENT: solo-deployment
    run: |
      set -euo pipefail
      kind create cluster -n "${SOLO_CLUSTER_NAME}"
      solo one-shot single deploy | tee solo-deploy.log

Resetting Between Tests

If several tests each need a clean genesis ledger, you do not have to redeploy for each one. After deploying once, reset the ledger to genesis between tests to return to a known starting state without recreating the cluster:

  - name: Reset ledger to genesis
    env:
      SOLO_DEPLOYMENT: solo-deployment
    run: |
      set -euo pipefail
      solo ledger system reset --deployment "${SOLO_DEPLOYMENT}"

This is faster than a destroy-and-redeploy cycle. See Reset the ledger to genesis for details and available flags.

Cleanup

After the workflow completes, destroy the Solo deployment and delete the Kind cluster to avoid leaving resources behind.

  - name: Destroy Solo deployment
    env:
      SOLO_DEPLOYMENT: solo-deployment
    run: |
      set -euo pipefail
      solo one-shot single destroy --deployment "${SOLO_DEPLOYMENT}"

  - name: Delete Kind cluster
    env:
      SOLO_CLUSTER_NAME: solo
    run: |
      set -euo pipefail
      kind delete cluster -n "${SOLO_CLUSTER_NAME}"

Complete Example Workflow

The following is the full workflow combining all steps above. Copy this into your .github/workflows/ directory as a starting point.

name: Solo CI Example

on:
  workflow_dispatch:
    inputs:
      solo_version:
        description: 'Solo CLI version to install'
        required: false
        default: '0.69.0'
      kind_version:
        description: 'Kind version to install (minimum v0.29.0)'
        required: false
        default: 'v0.29.0'
      kubectl_version:
        description: 'kubectl version to install (minimum v1.32.2)'
        required: false
        default: 'v1.32.2'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Check Docker Resources
        run: |
          read cpus mem <<<"$(docker info --format '{{.NCPU}} {{.MemTotal}}')"
          mem_gb=$(awk -v m="$mem" 'BEGIN{printf "%.1f", m/1000000000}')
          echo "CPU cores: $cpus"
          echo "Memory: ${mem_gb} GB"
          
      - name: Setup Kind
        uses: helm/kind-action@a1b0e391336a6ee6713a0583f8c6240d70863de3
        with:
          install_only: true
          node_image: kindest/node:v1.32.2@sha256:3966f21e12b760f6585bde7140cae5e8cdc0e52b37a6f90ce39834b6e72e3f49
          version: v0.29.0
          kubectl_version: v1.32.2
          verbosity: 3
          wait: 120s
         
      - name: Set up Node.js
        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020
        with:
          node-version: 22.12.0
      
      - name: Install Solo CLI
        run: |
          set -euo pipefail
          npm install -g @hiero-ledger/solo@<version>
          solo --version
          kind --version
      
      - name: Deploy Solo
        env:
          SOLO_CLUSTER_NAME: solo
          SOLO_NAMESPACE: one-shot
          SOLO_CLUSTER_SETUP_NAMESPACE: solo-cluster
          SOLO_DEPLOYMENT: solo-deployment
        run: |
          set -euo pipefail
          kind create cluster -n "${SOLO_CLUSTER_NAME}"
          solo one-shot single deploy | tee solo-deploy.log

      - name: Destroy Solo deployment
        env:
          SOLO_DEPLOYMENT: solo-deployment
        run: |
          set -euo pipefail
          solo one-shot single destroy --deployment "${SOLO_DEPLOYMENT}"

      - name: Delete Kind cluster
        env:
          SOLO_CLUSTER_NAME: solo
        run: |
          set -euo pipefail
          kind delete cluster -n "${SOLO_CLUSTER_NAME}"

2.7 - One-Shot Deploy on a GitHub-hosted Runner

Deploy a full Solo network on a standard GitHub-hosted Ubuntu runner using the one-shot single deploy command. No self-hosted runner or pre-provisioned cluster required.

Deploy Solo on a Standard GitHub Runner

This guide is for developers who want to deploy a Solo network in CI to run integration tests against a live Hedera network from their own project. It uses the standard ubuntu-latest GitHub-hosted runner and the Solo CLI installed via Homebrew.

For the hardware specs that runner provides, see GitHub’s documentation on standard hosted runners.

How It Works

Solo’s one-shot deploy is self-contained. You do not need to:

  • Pre-create a Kind cluster
  • Install Helm separately
  • Run solo init manually

The command handles cluster provisioning, tool installation, and full network deployment internally, then exits when every component is healthy.

GitHub Runner (ubuntu-latest)
  └─► solo one-shot single deploy
        ├─► Kind cluster created automatically
        ├─► Consensus Node deployed and started
        ├─► Mirror Node deployed and started
        ├─► Explorer deployed and started
        └─► JSON-RPC Relay deployed and started

Example Workflow

name: "Integration Tests"

on:
  pull_request:
    types: [opened, reopened, synchronize, ready_for_review]

defaults:
  run:
    shell: bash

permissions:
  contents: read

jobs:
  integration-tests:
    name: Integration Tests
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Install Solo CLI
        run: |
          brew install hiero-ledger/tools/solo
          solo --version

      - name: One-Shot Single Deploy
        run: solo one-shot single deploy

      - name: Verify Mirror REST API
        timeout-minutes: 5
        run: |
          echo "Waiting for mirror node REST API..."
          for i in $(seq 1 30); do
            response=$(curl -sf http://localhost:38081/api/v1/accounts 2>/dev/null || true)
            if echo "${response}" | grep -q '"accounts"'; then
              echo "Mirror REST API is up."
              exit 0
            fi
            echo "Attempt ${i}/30: not ready, retrying in 10s..."
            sleep 10
          done
          echo "ERROR: Mirror REST API did not become available."
          exit 1

      # Add your integration test steps here

      - name: One-Shot Single Destroy
        if: always()
        run: solo one-shot single destroy --quiet-mode || true

      - name: Upload Logs
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: solo-logs
          path: ~/.solo/logs/*
          overwrite: true
          if-no-files-found: warn

2.8 - Run Performance Tests Locally

Run Solo E2E performance tests locally, including setup, execution, optional local build path configuration, and branch workflow triggering.

Overview

This guide shows how to run the Solo E2E performance test on a local machine.

Prerequisites

  • task, node, npm, kubectl, and kind installed
  • Docker running
  • Solo dependencies installed (npm ci)

Run the Performance Test

From the repository root:

task test-setup
task test-e2e-performance

The test uses one-shot single deploy/destroy flow and then runs rapid-fire load tests.

Optional: Use a Local Consensus Node Build

If you already have a local consensus node build, set SOLO_LOCAL_BUILD_PATH so commands that consume --local-build-path can use it by default:

export SOLO_LOCAL_BUILD_PATH="/absolute/path/to/hiero-consensus-node/hedera-node/data"
task test-setup
task test-e2e-performance

Optional: Shorten Test Duration

You can shorten load-test duration while iterating:

export ONE_SHOT_METRICS_TEST_DURATION_IN_MINUTES=2
task test-e2e-performance

Run the GitHub Performance Workflow for a Branch

You can run the repository performance workflow against any pushed Solo branch.

Option 1: Using gh CLI

export SOLO_BRANCH="<your-branch-name>"
gh workflow run "Performance Test Solo Deployment" --ref "${SOLO_BRANCH}" --repo hiero-ledger/solo

Watch the latest run for that branch:

RUN_ID=$(gh run list --workflow "Performance Test Solo Deployment" --branch "${SOLO_BRANCH}" --limit 1 --json databaseId -q '.[0].databaseId')
gh run watch "${RUN_ID}" --repo hiero-ledger/solo

Option 2: Using GitHub Web UI

  1. Open https://github.com/hiero-ledger/solo/actions/workflows/flow-performance-test.yaml.
  2. Click Run workflow.
  3. Select your branch in the branch dropdown.
  4. Click Run workflow to start the run.

2.9 - CLI Reference

Canonical Solo CLI command and flag reference, including migration guidance from legacy command paths. Use this section to look up Solo commands, subcommands, and flags.

2.9.1 - Solo CLI Reference

Canonical Solo CLI command and flag reference for end users.

Overview

This page is the canonical command reference for the Solo CLI.

  • Use it to look up command paths, subcommands, and flags.
  • Use solo <command> --help and solo <command> <subcommand> --help for runtime help on your installed version.
  • For legacy command mappings, see CLI Migration Reference.

Output Formats (--output, -o)

Solo supports machine-readable output for version output and for command execution flows that honor the output format flag.

solo --version -o json
solo --version -o yaml
solo --version -o wide

Expected formats:

  • json: JSON object output.
  • yaml: YAML output.
  • wide: plain text value-oriented output.

Global Flags

Global flags shown in root help:

  • --dev: enable developer mode.
  • --force-port-forward: force port forwarding for network services.
  • -v, --version: print Solo version.

Command and Flag Reference

The sections below are generated from Solo CLI help output using the implementation on hiero-ledger/solo.

Version Output

******************************* Solo *********************************************
Version			: 0.80.0
**********************************************************************************

Root Help Output

Usage:
  solo <command> [options]

Commands:
  init         Initialize local environment
  config       Backup and restore component configurations for Solo deployments. These commands display what would be backed up or restored without performing actual operations.
  block        Block Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.
  cluster-ref  Manages the relationship between Kubernetes context names and Solo cluster references which are an alias for a kubernetes context.
  consensus    Consensus Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.
  deployment   Create, modify, and delete deployment configurations. Deployments are required for most of the other commands.
  explorer     Explorer Node operations for creating, modifying, and destroying resources.These commands require the presence of an existing deployment.
  keys         Consensus key generation operations
  ledger       System, Account, and Crypto ledger-based management operations. These commands require an operational set of consensus nodes and may require an operational mirror node.
  mirror       Mirror Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.
  relay        RPC Relay Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.
  cache        Manage solo cached items.
  one-shot     One Shot commands for new and returning users who need a preset environment type. These commands use reasonable defaults to provide a single command out of box experience.
  rapid-fire   Commands for performing load tests a Solo deployment

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

init

 init

Initialize local environment

Options:

                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-u,  --user                Optional user name used for     [string]                                      
                           local configuration. Only                                                     
                           accepts letters and numbers.                                                  
                           Defaults to the username                                                      
                           provided by the OS                                                            
-v,  --version             Show version number             [boolean]

config

 config

Backup and restore component configurations for Solo deployments. These commands display what would be backed up or restored without performing actual operations.

Commands:
  config ops   Configuration backup and restore operations

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

config ops

 config ops

Configuration backup and restore operations

Commands:
  config ops backup             Create a backup for all component configurations of a deployment. Create a zip file with configuration and log data.Export states, configmaps and secrets
  config ops restore-config     Restore component configurations from backup. Imports ConfigMaps, Secrets, logs, and state files for a running deployment.
  config ops restore-clusters   Restore Kind clusters from backup directory structure. Creates clusters, sets up Docker network, installs MetalLB, and initializes cluster configurations. Does not deploy network components.
  config ops restore-network    Deploy network components to existing clusters from backup. Deploys consensus nodes, block nodes, mirror nodes, explorers, and relay nodes. Requires clusters to be already created (use restore-clusters first).

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

config ops backup

 config ops backup

Create a backup for all component configurations of a deployment. Create a zip file with configuration and log data.Export states, configmaps and secrets

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --output-dir          Path to the directory where     [string]                  
                           the command context will be                               
                           saved to                                                  
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]                 
     --zip-file            Path to the encrypted backup    [string]                  
                           ZIP archive used during                                   
                           restore                                                   
     --zip-password        Password to encrypt generated   [string]                  
                           backup ZIP archives

config ops restore-config

 config ops restore-config

Restore component configurations from backup. Imports ConfigMaps, Secrets, logs, and state files for a running deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --input-dir           Path to the directory where     [string]                  
                           the command context will be                               
                           loaded from                                               
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

config ops restore-clusters

 config ops restore-clusters

Restore Kind clusters from backup directory structure. Creates clusters, sets up Docker network, installs MetalLB, and initializes cluster configurations. Does not deploy network components.

Options:

     --input-dir           Path to the directory where     [string] [required]                               
                           the command context will be                                                       
                           loaded from                                                                       
                                                                                                             
     --dev                 Enable developer mode           [boolean] [default: false]                        
     --force-port-forward  Force port forward to access    [boolean] [default: true]                         
                           the network services                                                              
     --metallb-config      Path pattern for MetalLB        [string] [default: "metallb-cluster-{index}.yaml"]
                           configuration YAML files                                                          
                           (supports {index} placeholder                                                     
                           for cluster number)                                                               
     --options-file        Path to YAML file containing    [string]                                          
                           component-specific deployment                                                     
                           options (consensus, block,                                                        
                           mirror, relay, explorer)                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                        
                           confirmation                                                                      
-v,  --version             Show version number             [boolean]                                         
     --zip-file            Path to the encrypted backup    [string]                                          
                           ZIP archive used during                                                           
                           restore                                                                           
     --zip-password        Password to encrypt generated   [string]                                          
                           backup ZIP archives

config ops restore-network

 config ops restore-network

Deploy network components to existing clusters from backup. Deploys consensus nodes, block nodes, mirror nodes, explorers, and relay nodes. Requires clusters to be already created (use restore-clusters first).

Options:

     --input-dir           Path to the directory where     [string] [required]       
                           the command context will be                               
                           loaded from                                               
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --options-file        Path to YAML file containing    [string]                  
                           component-specific deployment                             
                           options (consensus, block,                                
                           mirror, relay, explorer)                                  
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
     --realm               Realm number. Requires          [number] [default: 0]     
                           network-node > v61.0 for                                  
                           non-zero values                                           
     --shard               Shard number. Requires          [number] [default: 0]     
                           network-node > v61.0 for                                  
                           non-zero values                                           
-v,  --version             Show version number             [boolean]

block

 block

Block Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.

Commands:
  block node   Create, manage, or destroy block node instances. Operates on a single block node instance at a time.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

block node

 block node

Create, manage, or destroy block node instances. Operates on a single block node instance at a time.

Commands:
  block node add               Creates and configures a new block node instance for the specified deployment using the specified Kubernetes cluster. The cluster must be accessible and attached to the specified deployment.
  block node destroy           Destroys a single block node instance in the specified deployment. Requires access to all Kubernetes clusters attached to the deployment.
  block node upgrade           Upgrades a single block node instance in the specified deployment. Requires access to all Kubernetes clusters attached to the deployment.
  block node add-external      Add an external block node for the specified deployment. You can specify the priority and consensus nodes to which to connect or use the default settings.
  block node delete-external   Deletes an external block node from the specified deployment.
  block node collect-jfr       Downloads the Java Flight Recorder recording from a block node instance in the specified deployment to the local solo logs directory. Requires the block node to have been deployed with Java Flight Recorder enabled.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

block node add

 block node add

Creates and configures a new block node instance for the specified deployment using the specified Kubernetes cluster. The cluster must be accessible and attached to the specified deployment.

Options:

-d,  --deployment                                The name the user will          [string] [required]                                                                                           
                                                 reference locally to link to a                                                                                                                
                                                 deployment                                                                                                                                    
                                                                                                                                                                                               
     --block-node-chart-dir                      Block node local chart          [string]                                                                                                      
                                                 directory path (e.g.                                                                                                                          
                                                 ~/hiero-block-node/charts)                                                                                                                    
     --block-node-message-size-hard-limit-bytes  Hard limit, in bytes, for       [number]                                                                                                      
                                                 block node connection message                                                                                                                 
                                                 size in block-nodes.json                                                                                                                      
     --block-node-message-size-soft-limit-bytes  Soft limit, in bytes, for       [number]                                                                                                      
                                                 block node connection message                                                                                                                 
                                                 size in block-nodes.json                                                                                                                      
     --block-node-tss-overlay                    Force-apply block-node TSS      [boolean] [default: false]                                                                                    
                                                 values overlay when deploying                                                                                                                 
                                                 block nodes before consensus                                                                                                                  
                                                 deployment sets tssEnabled in                                                                                                                 
                                                 remote config.                                                                                                                                
     --block-node-version                        Block node version to deploy    [string]                                                                                                      
                                                 for (e.g. v0.31.0 or 0.31.0).                                                                                                                 
     --chart-dir                                 Local chart directory path      [string]                                                                                                      
                                                 (e.g. ~/solo-charts/charts)                                                                                                                   
     --chart-version                             DEPRECATED: use                 [string] [default: "0.36.0"]                                                                                  
                                                 --block-node-version                                                                                                                          
-c,  --cluster-ref                               The cluster reference that      [string]                                                                                                      
                                                 will be used for referencing                                                                                                                  
                                                 the Kubernetes cluster and                                                                                                                    
                                                 stored in the local and remote                                                                                                                
                                                 configuration for the                                                                                                                         
                                                 deployment.  For commands that                                                                                                                
                                                 take multiple clusters they                                                                                                                   
                                                 can be separated by commas.                                                                                                                   
     --component-image                           ,  --relay-image                [string]                                                                                                      
                                                 Docker image override. Accepts                                                                                                                
                                                 a registry reference (e.g.                                                                                                                    
                                                 ghcr.io/hiero-ledger/block-node-server:0.36.0) or a local reference (e.g. block-node-server:0.36.0-SNAPSHOT). Local images found in Docker are automatically loaded into the Kind cluster.                                                                                                                
     --consensus-node-version                    Consensus node version to       [string]                                                                                                      
                                                 deploy (e.g. v0.73.0 or                                                                                                                       
                                                 0.73.0).                                                                                                                                      
     --dev                                       Enable developer mode           [boolean] [default: false]                                                                                    
     --domain-name                               Custom domain name              [string]                                                                                                      
     --enable-ingress                            enable ingress on the           [boolean] [default: false]                                                                                    
                                                 component/pod                                                                                                                                 
     --force-port-forward                        Force port forward to access    [boolean] [default: true]                                                                                     
                                                 the network services                                                                                                                          
     --image-tag                                                                 [Deprecated] Use  --component-image  instead. Overrides the Docker image tag (e.g. 0.36.0-SNAPSHOT).  [string]
     --priority-mapping                          Configure block node priority   [string]                                                                                                      
                                                 mapping. Unlisted nodes will                                                                                                                  
                                                 not be routed to a block node                                                                                                                 
                                                 Default: all consensus nodes                                                                                                                  
                                                 included, first node priority                                                                                                                 
                                                 is 2. Example:                                                                                                                                
                                                 "priority-mapping                                                                                                                             
                                                 node1=2,node2=1"                                                                                                                              
-q,  --quiet-mode                                Quiet mode, do not prompt for   [boolean] [default: false]                                                                                    
                                                 confirmation                                                                                                                                  
-t,  --release-tag                               DEPRECATED: use                 [string] [default: "v0.74.0"]                                                                                 
                                                 --consensus-node-version                                                                                                                      
                                                 (e.g. v0.74.0)                                                                                                                                
-f,  --values-file                               Comma separated chart values    [string]                                                                                                      
                                                 file                                                                                                                                          
-v,  --version                                   Show version number             [boolean]

block node destroy

 block node destroy

Destroys a single block node instance in the specified deployment. Requires access to all Kubernetes clusters attached to the deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --chart-dir           Local chart directory path      [string]                  
                           (e.g. ~/solo-charts/charts)                               
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force               Force actions even if those     [boolean] [default: false]
                           can be skipped                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --id                  The numeric identifier for the  [number]                  
                           component                                                 
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

block node upgrade

 block node upgrade

Upgrades a single block node instance in the specified deployment. Requires access to all Kubernetes clusters attached to the deployment.

Options:

-d,  --deployment            The name the user will          [string] [required]       
                             reference locally to link to a                            
                             deployment                                                
                                                                                       
     --block-node-chart-dir  Block node local chart          [string]                  
                             directory path (e.g.                                      
                             ~/hiero-block-node/charts)                                
     --chart-dir             Local chart directory path      [string]                  
                             (e.g. ~/solo-charts/charts)                               
-c,  --cluster-ref           The cluster reference that      [string]                  
                             will be used for referencing                              
                             the Kubernetes cluster and                                
                             stored in the local and remote                            
                             configuration for the                                     
                             deployment.  For commands that                            
                             take multiple clusters they                               
                             can be separated by commas.                               
     --dev                   Enable developer mode           [boolean] [default: false]
     --force                 Force actions even if those     [boolean] [default: false]
                             can be skipped                                            
     --force-port-forward    Force port forward to access    [boolean] [default: true] 
                             the network services                                      
     --id                    The numeric identifier for the  [number]                  
                             component                                                 
-q,  --quiet-mode            Quiet mode, do not prompt for   [boolean] [default: false]
                             confirmation                                              
     --upgrade-version       Version to be used for the      [string]                  
                             upgrade                                                   
-f,  --values-file           Comma separated chart values    [string]                  
                             file                                                      
-v,  --version               Show version number             [boolean]

block node add-external

 block node add-external

Add an external block node for the specified deployment. You can specify the priority and consensus nodes to which to connect or use the default settings.

Options:

     --address                                   Provide external block node     [string] [required]       
                                                 address (IP or domain), with                              
                                                 optional port (Default port:                              
                                                 40840) Examples: " --address                              
                                                 localhost:8080", " --address                              
                                                 192.0.0.1"                                                
-d,  --deployment                                The name the user will          [string] [required]       
                                                 reference locally to link to a                            
                                                 deployment                                                
                                                                                                           
     --block-node-message-size-hard-limit-bytes  Hard limit, in bytes, for       [number]                  
                                                 block node connection message                             
                                                 size in block-nodes.json                                  
     --block-node-message-size-soft-limit-bytes  Soft limit, in bytes, for       [number]                  
                                                 block node connection message                             
                                                 size in block-nodes.json                                  
-c,  --cluster-ref                               The cluster reference that      [string]                  
                                                 will be used for referencing                              
                                                 the Kubernetes cluster and                                
                                                 stored in the local and remote                            
                                                 configuration for the                                     
                                                 deployment.  For commands that                            
                                                 take multiple clusters they                               
                                                 can be separated by commas.                               
     --dev                                       Enable developer mode           [boolean] [default: false]
     --force-port-forward                        Force port forward to access    [boolean] [default: true] 
                                                 the network services                                      
     --priority-mapping                          Configure block node priority   [string]                  
                                                 mapping. Unlisted nodes will                              
                                                 not be routed to a block node                             
                                                 Default: all consensus nodes                              
                                                 included, first node priority                             
                                                 is 2. Example:                                            
                                                 "priority-mapping                                         
                                                 node1=2,node2=1"                                          
-q,  --quiet-mode                                Quiet mode, do not prompt for   [boolean] [default: false]
                                                 confirmation                                              
-v,  --version                                   Show version number             [boolean]

block node delete-external

 block node delete-external

Deletes an external block node from the specified deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force               Force actions even if those     [boolean] [default: false]
                           can be skipped                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --id                  The numeric identifier for the  [number]                  
                           component                                                 
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

block node collect-jfr

 block node collect-jfr

Downloads the Java Flight Recorder recording from a block node instance in the specified deployment to the local solo logs directory. Requires the block node to have been deployed with Java Flight Recorder enabled.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --id                  The numeric identifier for the  [number]                  
                           component                                                 
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

cluster-ref

 cluster-ref

Manages the relationship between Kubernetes context names and Solo cluster references which are an alias for a kubernetes context.

Commands:
  cluster-ref config   List, create, manage, and remove associations between Kubernetes contexts and Solo cluster references.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

cluster-ref config

 cluster-ref config

List, create, manage, and remove associations between Kubernetes contexts and Solo cluster references.

Commands:
  cluster-ref config connect      Creates a new internal Solo cluster name to a Kubernetes context or maps a Kubernetes context to an existing internal Solo cluster reference
  cluster-ref config disconnect   Removes the Kubernetes context associated with an internal Solo cluster reference.
  cluster-ref config list         Lists the configured Kubernetes context to Solo cluster reference mappings.
  cluster-ref config info         Displays the status information and attached deployments for a given Solo cluster reference mapping.
  cluster-ref config setup        Setup cluster with shared components
  cluster-ref config reset        Uninstall shared components from cluster

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

cluster-ref config connect

 cluster-ref config connect

Creates a new internal Solo cluster name to a Kubernetes context or maps a Kubernetes context to an existing internal Solo cluster reference

Options:

-c,  --cluster-ref         The cluster reference that      [string] [required]       
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --context             The Kubernetes context name to  [string] [required]       
                           be used                                                   
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

cluster-ref config disconnect

 cluster-ref config disconnect

Removes the Kubernetes context associated with an internal Solo cluster reference.

Options:

-c,  --cluster-ref         The cluster reference that      [string] [required]       
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

cluster-ref config list

 cluster-ref config list

Lists the configured Kubernetes context to Solo cluster reference mappings.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

cluster-ref config info

 cluster-ref config info

Displays the status information and attached deployments for a given Solo cluster reference mapping.

Options:

-c,  --cluster-ref         The cluster reference that      [string] [required]       
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

cluster-ref config setup

 cluster-ref config setup

Setup cluster with shared components

Options:

                                                                                                
     --chart-dir                Local chart directory path      [string]                        
                                (e.g. ~/solo-charts/charts)                                     
-c,  --cluster-ref              The cluster reference that      [string]                        
                                will be used for referencing                                    
                                the Kubernetes cluster and                                      
                                stored in the local and remote                                  
                                configuration for the                                           
                                deployment.  For commands that                                  
                                take multiple clusters they                                     
                                can be separated by commas.                                     
-s,  --cluster-setup-namespace  Cluster Setup Namespace         [string] [default: "solo-setup"]
     --dev                      Enable developer mode           [boolean] [default: false]      
     --force-port-forward       Force port forward to access    [boolean] [default: true]       
                                the network services                                            
     --metrics-server           Deploy metrics server to        [boolean] [default: false]      
                                enable kubectl top for CPU and                                  
                                memory usage monitoring                                         
     --minio                    Deploy minio operator           [boolean] [default: true]       
     --prometheus-stack         Deploy prometheus stack         [boolean] [default: false]      
-q,  --quiet-mode               Quiet mode, do not prompt for   [boolean] [default: false]      
                                confirmation                                                    
     --solo-chart-version       Solo testing chart version      [string] [default: "0.64.0"]    
-v,  --version                  Show version number             [boolean]

cluster-ref config reset

 cluster-ref config reset

Uninstall shared components from cluster

Options:

-c,  --cluster-ref              The cluster reference that      [string] [required]             
                                will be used for referencing                                    
                                the Kubernetes cluster and                                      
                                stored in the local and remote                                  
                                configuration for the                                           
                                deployment.  For commands that                                  
                                take multiple clusters they                                     
                                can be separated by commas.                                     
                                                                                                
-s,  --cluster-setup-namespace  Cluster Setup Namespace         [string] [default: "solo-setup"]
     --dev                      Enable developer mode           [boolean] [default: false]      
     --force                    Force actions even if those     [boolean] [default: false]      
                                can be skipped                                                  
     --force-port-forward       Force port forward to access    [boolean] [default: true]       
                                the network services                                            
-q,  --quiet-mode               Quiet mode, do not prompt for   [boolean] [default: false]      
                                confirmation                                                    
-v,  --version                  Show version number             [boolean]

consensus

 consensus

Consensus Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.

Commands:
  consensus network            Ledger/network wide consensus operations such as freeze, upgrade, and deploy. Operates on the entire ledger and all consensus node instances.
  consensus node               List, create, manage, or destroy consensus node instances. Operates on a single consensus node instance at a time.
  consensus state              List, download, and upload consensus node state backups to/from individual consensus node instances.
  consensus dev-node-add       Dev operations for adding consensus nodes.
  consensus dev-node-update    Dev operations for updating consensus nodes
  consensus dev-node-upgrade   Dev operations for upgrading consensus nodes
  consensus dev-node-delete    Dev operations for delete consensus nodes
  consensus dev-freeze         Dev operations for freezing consensus nodes

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus network

 consensus network

Ledger/network wide consensus operations such as freeze, upgrade, and deploy. Operates on the entire ledger and all consensus node instances.

Commands:
  consensus network deploy    Installs and configures all consensus nodes for the deployment.
  consensus network destroy   Removes all consensus network components from the deployment.
  consensus network freeze    Initiates a network freeze for scheduled maintenance or upgrades
  consensus network upgrade   Upgrades the software version running on all consensus nodes.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus network deploy

 consensus network deploy

Installs and configures all consensus nodes for the deployment.

Options:

-d,  --deployment                                The name the user will          [string] [required]                                      
                                                 reference locally to link to a                                                           
                                                 deployment                                                                               
                                                                                                                                          
     --api-permission-properties                 api-permission.properties file  [string] [default: "templates/api-permission.properties"]
                                                 for node                                                                                 
     --app                                       Testing app name                [string] [default: "HederaNode.jar"]                     
     --application-env                           the application.env file for    [string] [default: "templates/application.env"]          
                                                 the node provides environment                                                            
                                                 variables to the                                                                         
                                                 solo-container to be used when                                                           
                                                 the hedera platform is started                                                           
     --application-properties                    application.properties file     [string] [default: "templates/application.properties"]   
                                                 for node (default merges with                                                            
                                                 Solo defaults; add comment                                                               
                                                 'SOLO_ENABLE_OVERWRITE=true'                                                             
                                                 in the file to use overwrite                                                             
                                                 mode)                                                                                    
     --aws-bucket                                name of aws storage bucket      [string]                                                 
     --aws-bucket-prefix                         path prefix of aws storage      [string]                                                 
                                                 bucket                                                                                   
     --aws-bucket-region                         name of aws bucket region       [string]                                                 
     --aws-endpoint                              aws storage endpoint URL        [string]                                                 
     --aws-write-access-key                      aws storage access key for      [string]                                                 
                                                 write access                                                                             
     --aws-write-secrets                         aws storage secret key for      [string]                                                 
                                                 write access                                                                             
     --backup-bucket                             name of bucket for backing up   [string]                                                 
                                                 state files                                                                              
     --backup-endpoint                           backup storage endpoint URL     [string]                                                 
     --backup-provider                           backup storage service          [string] [default: "GCS"]                                
                                                 provider, GCS or AWS                                                                     
     --backup-region                             backup storage region           [string] [default: "us-central1"]                        
     --backup-write-access-key                   backup storage access key for   [string]                                                 
                                                 write access                                                                             
     --backup-write-secrets                      backup storage secret key for   [string]                                                 
                                                 write access                                                                             
     --block-node-message-size-hard-limit-bytes  Hard limit, in bytes, for       [number]                                                 
                                                 block node connection message                                                            
                                                 size in block-nodes.json                                                                 
     --block-node-message-size-soft-limit-bytes  Soft limit, in bytes, for       [number]                                                 
                                                 block node connection message                                                            
                                                 size in block-nodes.json                                                                 
     --bootstrap-properties                      bootstrap.properties file for   [string] [default: "templates/bootstrap.properties"]     
                                                 node                                                                                     
     --cache-dir                                 Local cache directory           [string] [default: "/home/runner/.solo/cache"]           
-l,  --chain-id                                  Chain ID                        [string] [default: "298"]                                
     --chart-dir                                 Local chart directory path      [string]                                                 
                                                 (e.g. ~/solo-charts/charts)                                                              
     --consensus-node-version                    Consensus node version to       [string]                                                 
                                                 deploy (e.g. v0.73.0 or                                                                  
                                                 0.73.0).                                                                                 
     --debug-node-alias                          Enable default jvm debug port   [string]                                                 
                                                 (5005) for the given node id                                                             
     --dev                                       Enable developer mode           [boolean] [default: false]                               
     --domain-names                              Custom domain names for         [string]                                                 
                                                 consensus nodes mapping for                                                              
                                                 the(e.g. node0=domain.name                                                               
                                                 where key is node alias and                                                              
                                                 value is domain name)with                                                                
                                                 multiple nodes comma separated                                                           
     --enable-monitoring-support                 Enables CRDs for Prometheus     [boolean] [default: true]                                
                                                 and Grafana.                                                                             
     --envoy-ips                                 IP mapping where key = value    [string]                                                 
                                                 is node alias and static ip                                                              
                                                 for envoy proxy, (e.g.:                                                                  
                                                 --envoy-ips                                                                              
                                                 node1=127.0.0.1,node2=127.0.0.1)                                                           
     --force-port-forward                        Force port forward to access    [boolean] [default: true]                                
                                                 the network services                                                                     
     --gcs-bucket                                name of gcs storage bucket      [string]                                                 
     --gcs-bucket-prefix                         path prefix of google storage   [string]                                                 
                                                 bucket                                                                                   
     --gcs-endpoint                              gcs storage endpoint URL        [string]                                                 
     --gcs-write-access-key                      gcs storage access key for      [string]                                                 
                                                 write access                                                                             
     --gcs-write-secrets                         gcs storage secret key for      [string]                                                 
                                                 write access                                                                             
     --genesis-throttles-file                    throttles.json file used        [string]                                                 
                                                 during network genesis                                                                   
     --grpc-tls-cert                             TLS Certificate path for the    [string]                                                 
                                                 gRPC (e.g.                                                                               
                                                 "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated)                                                           
     --grpc-tls-key                              TLS Certificate key path for    [string]                                                 
                                                 the gRPC (e.g.                                                                           
                                                 "node1=/Users/username/node1-grpc.key" with multiple nodes comma separated)                                                           
     --grpc-web-tls-cert                         TLS Certificate path for gRPC   [string]                                                 
                                                 Web (e.g.                                                                                
                                                 "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated)                                                           
     --grpc-web-tls-key                          TLC Certificate key path for    [string]                                                 
                                                 gRPC Web (e.g.                                                                           
                                                 "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma separated)                                                           
     --haproxy-ips                               IP mapping where key = value    [string]                                                 
                                                 is node alias and static ip                                                              
                                                 for haproxy, (e.g.:                                                                      
                                                 --haproxy-ips                                                                            
                                                 node1=127.0.0.1,node2=127.0.0.1)                                                           
     --jfr-config                                Java Flight Recorder            [string]                                                 
                                                 configuration file path                                                                  
     --load-balancer                             Enable load balancer for        [boolean] [default: false]                               
                                                 network node proxies                                                                     
     --log4j2-xml                                log4j2.xml file for node        [string] [default: "templates/log4j2.xml"]               
-i,  --node-aliases                              Comma separated node aliases    [string]                                                 
                                                 (empty means all nodes)                                                                  
     --pod-log                                   Install PodLog custom resource  [boolean] [default: false]                               
                                                 for monitoring Network Node                                                              
                                                 pod logs                                                                                 
     --pvcs                                      Enable persistent volume        [boolean] [default: false]                               
                                                 claims to store data outside                                                             
                                                 the pod, required for                                                                    
                                                 consensus node add                                                                       
-q,  --quiet-mode                                Quiet mode, do not prompt for   [boolean] [default: false]                               
                                                 confirmation                                                                             
-t,  --release-tag                               DEPRECATED: use                 [string] [default: "v0.74.0"]                            
                                                 --consensus-node-version                                                                 
                                                 (e.g. v0.74.0)                                                                           
     --service-monitor                           Install ServiceMonitor custom   [boolean] [default: false]                               
                                                 resource for monitoring                                                                  
                                                 Network Node metrics                                                                     
     --settings-txt                              settings.txt file for node      [string] [default: "templates/settings.txt"]             
     --solo-chart-version                        Solo testing chart version      [string] [default: "0.64.0"]                             
     --storage-type                              storage type for saving stream  [default: "minio_only"]                                  
                                                 files, available options are                                                             
                                                 minio_only, aws_only,                                                                    
                                                 gcs_only, aws_and_gcs                                                                    
     --tss                                       Enable hinTS/TSS (CN >=         [boolean] [default: true]                                
                                                 v0.74).                                                                                  
-f,  --values-file                               Comma separated chart values    [string]                                                 
                                                 file paths for each cluster                                                              
                                                 (e.g.                                                                                    
                                                 values.yaml,cluster-1=./a/b/values1.yaml,cluster-2=./a/b/values2.yaml)                                                           
-v,  --version                                   Show version number             [boolean]                                                
     --wraps                                     Enable recursive WRAPs          [boolean] [default: false]                               
                                                 aggregation for hinTS/TSS (CN                                                            
                                                 >= v0.72).                                                                               
     --wraps-key-path                            Path to a local directory       [string]                                                 
                                                 containing pre-existing WRAPs                                                            
                                                 proving key files (.bin)

consensus network destroy

 consensus network destroy

Removes all consensus network components from the deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --delete-pvcs         Delete the persistent volume    [boolean] [default: false]
                           claims. If both  --delete-pvcs                            
                            and  --delete-secrets  are                               
                           set to true, the namespace                                
                           will be deleted.                                          
     --delete-secrets      Delete the network secrets. If  [boolean] [default: false]
                           both  --delete-pvcs  and                                  
                           --delete-secrets  are set to                              
                           true, the namespace will be                               
                           deleted.                                                  
     --dev                 Enable developer mode           [boolean] [default: false]
     --enable-timeout      enable time out for running a   [boolean] [default: false]
                           command                                                   
     --force               Force actions even if those     [boolean] [default: false]
                           can be skipped                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

consensus network freeze

 consensus network freeze

Initiates a network freeze for scheduled maintenance or upgrades

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

consensus network upgrade

 consensus network upgrade

Upgrades the software version running on all consensus nodes.

Options:

-d,  --deployment                 The name the user will          [string] [required]                                      
                                  reference locally to link to a                                                           
                                  deployment                                                                               
                                                                                                                           
     --api-permission-properties  api-permission.properties file  [string] [default: "templates/api-permission.properties"]
                                  for node                                                                                 
     --app                        Testing app name                [string] [default: "HederaNode.jar"]                     
     --application-env            the application.env file for    [string] [default: "templates/application.env"]          
                                  the node provides environment                                                            
                                  variables to the                                                                         
                                  solo-container to be used when                                                           
                                  the hedera platform is started                                                           
     --application-properties     application.properties file     [string] [default: "templates/application.properties"]   
                                  for node (default merges with                                                            
                                  Solo defaults; add comment                                                               
                                  'SOLO_ENABLE_OVERWRITE=true'                                                             
                                  in the file to use overwrite                                                             
                                  mode)                                                                                    
     --bootstrap-properties       bootstrap.properties file for   [string] [default: "templates/bootstrap.properties"]     
                                  node                                                                                     
     --cache-dir                  Local cache directory           [string] [default: "/home/runner/.solo/cache"]           
     --chart-dir                  Local chart directory path      [string]                                                 
                                  (e.g. ~/solo-charts/charts)                                                              
     --debug-node-alias           Enable default jvm debug port   [string]                                                 
                                  (5005) for the given node id                                                             
     --dev                        Enable developer mode           [boolean] [default: false]                               
     --force                      Force actions even if those     [boolean] [default: false]                               
                                  can be skipped                                                                           
     --force-port-forward         Force port forward to access    [boolean] [default: true]                                
                                  the network services                                                                     
     --local-build-path           path of hedera local repo       [string]                                                 
     --log4j2-xml                 log4j2.xml file for node        [string] [default: "templates/log4j2.xml"]               
-i,  --node-aliases               Comma separated node aliases    [string]                                                 
                                  (empty means all nodes)                                                                  
-q,  --quiet-mode                 Quiet mode, do not prompt for   [boolean] [default: false]                               
                                  confirmation                                                                             
     --settings-txt               settings.txt file for node      [string] [default: "templates/settings.txt"]             
     --solo-chart-version         Solo testing chart version      [string] [default: "0.64.0"]                             
     --upgrade-version            Version to be used for the      [string]                                                 
                                  upgrade                                                                                  
     --upgrade-zip-file           A zipped file used for network  [string]                                                 
                                  upgrade                                                                                  
-f,  --values-file                Comma separated chart values    [string]                                                 
                                  file paths for each cluster                                                              
                                  (e.g.                                                                                    
                                  values.yaml,cluster-1=./a/b/values1.yaml,cluster-2=./a/b/values2.yaml)                                                           
-v,  --version                    Show version number             [boolean]                                                
     --wraps-key-path             Path to a local directory       [string]                                                 
                                  containing pre-existing WRAPs                                                            
                                  proving key files (.bin)

consensus node

 consensus node

List, create, manage, or destroy consensus node instances. Operates on a single consensus node instance at a time.

Commands:
  consensus node setup         Setup node with a specific version of Hedera platform
  consensus node start         Start a node
  consensus node stop          Stop a node
  consensus node restart       Restart all nodes of the network
  consensus node refresh       Reset and restart a node
  consensus node add           Adds a node with a specific version of Hedera platform
  consensus node update        Update a node with a specific version of Hedera platform
  consensus node destroy       Delete a node with a specific version of Hedera platform
  consensus node collect-jfr   Collect Java Flight Recorder (JFR) files from a node for diagnostics and performance analysis. Requires the node to be running with Java Flight Recorder enabled.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus node setup

 consensus node setup

Setup node with a specific version of Hedera platform

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
                                                                                                             
     --admin-public-keys       Comma separated list of DER     [string]                                      
                               encoded ED25519 public keys                                                   
                               and must match the order of                                                   
                               the node aliases                                                              
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --app-config              json config file of testing     [string]                                      
                               app                                                                           
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --local-build-path        path of hedera local repo       [string]                                      
-i,  --node-aliases            Comma separated node aliases    [string]                                      
                               (empty means all nodes)                                                       
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
-v,  --version                 Show version number             [boolean]

consensus node start

 consensus node start

Start a node

Options:

-d,  --deployment          The name the user will          [string] [required]                                                      
                           reference locally to link to a                                                                           
                           deployment                                                                                               
                                                                                                                                    
     --app                 Testing app name                [string] [default: "HederaNode.jar"]                                     
     --debug-node-alias    Enable default jvm debug port   [string]                                                                 
                           (5005) for the given node id                                                                             
     --dev                 Enable developer mode           [boolean] [default: false]                                               
     --external-address    Bind address for kubectl        [string]                                                                 
                           port-forward (for example                                                                                
                           127.0.0.1 or 0.0.0.0)                                                                                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                                                
                           the network services                                                                                     
     --grpc-web-endpoints  Configure gRPC Web endpoints    [Format: <alias>=<address>[:<port>][,<alias>=<address>[:<port>]]][string]
                           mapping, comma separated                                                                                 
                           (Default port: 8080) (Aliases                                                                            
                           can be provided explicitly, or                                                                           
                           inferred by node id order)                                                                               
                           Examples:                                                                                                
                           node1=127.0.0.1:8080,node2=127.0.0.1:8081 node1=localhost,node2=localhost:8081 localhost,127.0.0.2:8081                                                                           
-i,  --node-aliases        Comma separated node aliases    [string]                                                                 
                           (empty means all nodes)                                                                                  
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                                               
                           confirmation                                                                                             
     --stake-amounts       The amount to be staked in the  [string]                                                                 
                           same order you list the node                                                                             
                           aliases with multiple node                                                                               
                           staked values comma separated                                                                            
     --state-file          A zipped state file to be used  [string]                                                                 
                           for the network                                                                                          
-v,  --version             Show version number             [boolean]                                                                
     --wraps-key-path      Path to a local directory       [string]                                                                 
                           containing pre-existing WRAPs                                                                            
                           proving key files (.bin)

consensus node stop

 consensus node stop

Stop a node

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-i,  --node-aliases        Comma separated node aliases    [string]                  
                           (empty means all nodes)                                   
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

consensus node restart

 consensus node restart

Restart all nodes of the network

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]                 
     --wraps-key-path      Path to a local directory       [string]                  
                           containing pre-existing WRAPs                             
                           proving key files (.bin)

consensus node refresh

 consensus node refresh

Reset and restart a node

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --local-build-path        path of hedera local repo       [string]                                      
-i,  --node-aliases            Comma separated node aliases    [string]                                      
                               (empty means all nodes)                                                       
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
-v,  --version                 Show version number             [boolean]

consensus node add

 consensus node add

Adds a node with a specific version of Hedera platform

Options:

-d,  --deployment                   The name the user will          [string] [required]                                                                                                   
                                    reference locally to link to a                                                                                                                        
                                    deployment                                                                                                                                            
                                                                                                                                                                                          
     --admin-key                    Admin key                       [string] [default: "302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137"]
     --app                          Testing app name                [string] [default: "HederaNode.jar"]                                                                                  
     --block-node-mapping           Configure block-node priority   [string]                                                                                                              
                                    mapping. Default: all                                                                                                                                 
                                    block-node included, first's                                                                                                                          
                                    priority is 2. Unlisted                                                                                                                               
                                    block-node will not routed to                                                                                                                         
                                    the consensus node node.                                                                                                                              
                                    Example:  --block-node-mapping                                                                                                                        
                                     1=2,2=1                                                                                                                                              
     --cache-dir                    Local cache directory           [string] [default: "/home/runner/.solo/cache"]                                                                        
-l,  --chain-id                     Chain ID                        [string] [default: "298"]                                                                                             
     --chart-dir                    Local chart directory path      [string]                                                                                                              
                                    (e.g. ~/solo-charts/charts)                                                                                                                           
-c,  --cluster-ref                  The cluster reference that      [string]                                                                                                              
                                    will be used for referencing                                                                                                                          
                                    the Kubernetes cluster and                                                                                                                            
                                    stored in the local and remote                                                                                                                        
                                    configuration for the                                                                                                                                 
                                    deployment.  For commands that                                                                                                                        
                                    take multiple clusters they                                                                                                                           
                                    can be separated by commas.                                                                                                                           
     --consensus-node-version       Consensus node version to       [string]                                                                                                              
                                    deploy (e.g. v0.73.0 or                                                                                                                               
                                    0.73.0).                                                                                                                                              
     --debug-node-alias             Enable default jvm debug port   [string]                                                                                                              
                                    (5005) for the given node id                                                                                                                          
     --dev                          Enable developer mode           [boolean] [default: false]                                                                                            
     --domain-names                 Custom domain names for         [string]                                                                                                              
                                    consensus nodes mapping for                                                                                                                           
                                    the(e.g. node0=domain.name                                                                                                                            
                                    where key is node alias and                                                                                                                           
                                    value is domain name)with                                                                                                                             
                                    multiple nodes comma separated                                                                                                                        
     --endpoint-type                Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                                                                                            
     --envoy-ips                    IP mapping where key = value    [string]                                                                                                              
                                    is node alias and static ip                                                                                                                           
                                    for envoy proxy, (e.g.:                                                                                                                               
                                    --envoy-ips                                                                                                                                           
                                    node1=127.0.0.1,node2=127.0.0.1)                                                                                                                        
     --external-block-node-mapping  Configure external-block-node   [string]                                                                                                              
                                    priority mapping. Default: all                                                                                                                        
                                    external-block-node included,                                                                                                                         
                                    first's priority is 2.                                                                                                                                
                                    Unlisted external-block-node                                                                                                                          
                                    will not routed to the                                                                                                                                
                                    consensus node node. Example:                                                                                                                         
                                    --external-block-node-mapping                                                                                                                         
                                    1=2,2=1                                                                                                                                               
     --force                        Force actions even if those     [boolean] [default: false]                                                                                            
                                    can be skipped                                                                                                                                        
     --force-port-forward           Force port forward to access    [boolean] [default: true]                                                                                             
                                    the network services                                                                                                                                  
     --gossip-endpoints             Comma separated gossip          [string]                                                                                                              
                                    endpoints of the node(e.g.                                                                                                                            
                                    first one is internal, second                                                                                                                         
                                    one is external)                                                                                                                                      
     --gossip-keys                  Generate gossip keys for nodes  [boolean] [default: false]                                                                                            
     --grpc-endpoints               Comma separated gRPC endpoints  [string]                                                                                                              
                                    of the node (at most 8)                                                                                                                               
     --grpc-tls-cert                TLS Certificate path for the    [string]                                                                                                              
                                    gRPC (e.g.                                                                                                                                            
                                    "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated)                                                                                                                        
     --grpc-tls-key                 TLS Certificate key path for    [string]                                                                                                              
                                    the gRPC (e.g.                                                                                                                                        
                                    "node1=/Users/username/node1-grpc.key" with multiple nodes comma separated)                                                                                                                        
     --grpc-web-endpoint            Configure gRPC Web endpoint     [Format: <address>[:<port>]]  [string]                                                                                
                                    (Default port: 8080)                                                                                                                                  
     --grpc-web-tls-cert            TLS Certificate path for gRPC   [string]                                                                                                              
                                    Web (e.g.                                                                                                                                             
                                    "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated)                                                                                                                        
     --grpc-web-tls-key             TLC Certificate key path for    [string]                                                                                                              
                                    gRPC Web (e.g.                                                                                                                                        
                                    "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma separated)                                                                                                                        
     --haproxy-ips                  IP mapping where key = value    [string]                                                                                                              
                                    is node alias and static ip                                                                                                                           
                                    for haproxy, (e.g.:                                                                                                                                   
                                    --haproxy-ips                                                                                                                                         
                                    node1=127.0.0.1,node2=127.0.0.1)                                                                                                                        
     --local-build-path             path of hedera local repo       [string]                                                                                                              
     --pvcs                         Enable persistent volume        [boolean] [default: false]                                                                                            
                                    claims to store data outside                                                                                                                          
                                    the pod, required for                                                                                                                                 
                                    consensus node add                                                                                                                                    
-q,  --quiet-mode                   Quiet mode, do not prompt for   [boolean] [default: false]                                                                                            
                                    confirmation                                                                                                                                          
-t,  --release-tag                  DEPRECATED: use                 [string] [default: "v0.74.0"]                                                                                         
                                    --consensus-node-version                                                                                                                              
                                    (e.g. v0.74.0)                                                                                                                                        
     --solo-chart-version           Solo testing chart version      [string] [default: "0.64.0"]                                                                                          
     --tls-keys                     Generate gRPC TLS keys for      [boolean] [default: false]                                                                                            
                                    nodes                                                                                                                                                 
-v,  --version                      Show version number             [boolean]                                                                                                             
     --wraps-key-path               Path to a local directory       [string]                                                                                                              
                                    containing pre-existing WRAPs                                                                                                                         
                                    proving key files (.bin)

consensus node update

 consensus node update

Update a node with a specific version of Hedera platform

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
     --node-alias              Node alias (e.g. node99)        [string] [required]                           
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir               Local chart directory path      [string]                                      
                               (e.g. ~/solo-charts/charts)                                                   
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --debug-node-alias        Enable default jvm debug port   [string]                                      
                               (5005) for the given node id                                                  
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --force                   Force actions even if those     [boolean] [default: false]                    
                               can be skipped                                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --gossip-endpoints        Comma separated gossip          [string]                                      
                               endpoints of the node(e.g.                                                    
                               first one is internal, second                                                 
                               one is external)                                                              
     --gossip-private-key      path and file name of the       [string]                                      
                               private key for signing gossip                                                
                               in PEM key format to be used                                                  
     --gossip-public-key       path and file name of the       [string]                                      
                               public key for signing gossip                                                 
                               in PEM key format to be used                                                  
     --grpc-endpoints          Comma separated gRPC endpoints  [string]                                      
                               of the node (at most 8)                                                       
     --local-build-path        path of hedera local repo       [string]                                      
     --new-account-number      new account number for node     [string]                                      
                               update transaction                                                            
     --new-admin-key           new admin key for the Hedera    [string]                                      
                               account                                                                       
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                  
     --tls-private-key         path and file name of the       [string]                                      
                               private TLS key to be used                                                    
     --tls-public-key          path and file name of the       [string]                                      
                               public TLS key to be used                                                     
-v,  --version                 Show version number             [boolean]                                     
     --wraps-key-path          Path to a local directory       [string]                                      
                               containing pre-existing WRAPs                                                 
                               proving key files (.bin)

consensus node destroy

 consensus node destroy

Delete a node with a specific version of Hedera platform

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
     --node-alias              Node alias (e.g. node99)        [string] [required]                           
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-l,  --chain-id                Chain ID                        [string] [default: "298"]                     
     --chart-dir               Local chart directory path      [string]                                      
                               (e.g. ~/solo-charts/charts)                                                   
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --debug-node-alias        Enable default jvm debug port   [string]                                      
                               (5005) for the given node id                                                  
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --force                   Force actions even if those     [boolean] [default: false]                    
                               can be skipped                                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --local-build-path        path of hedera local repo       [string]                                      
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                  
-v,  --version                 Show version number             [boolean]

consensus node collect-jfr

 consensus node collect-jfr

Collect Java Flight Recorder (JFR) files from a node for diagnostics and performance analysis. Requires the node to be running with Java Flight Recorder enabled.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
     --node-alias          Node alias (e.g. node99)        [string] [required]       
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

consensus state

 consensus state

List, download, and upload consensus node state backups to/from individual consensus node instances.

Commands:
  consensus state download   Downloads a signed state from consensus node/nodes.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus state download

 consensus state download

Downloads a signed state from consensus node/nodes.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
-i,  --node-aliases        Comma separated node aliases    [string] [required]       
                           (empty means all nodes)                                   
                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

consensus dev-node-add

 consensus dev-node-add

Dev operations for adding consensus nodes.

Commands:
  consensus dev-node-add prepare               Prepares the addition of a node with a specific version of Hedera platform
  consensus dev-node-add submit-transactions   Submits NodeCreateTransaction and Upgrade transactions to the network nodes
  consensus dev-node-add execute               Executes the addition of a previously prepared node

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus dev-node-add prepare

 consensus dev-node-add prepare

Prepares the addition of a node with a specific version of Hedera platform

Options:

-d,  --deployment                   The name the user will          [string] [required]                                                                                                   
                                    reference locally to link to a                                                                                                                        
                                    deployment                                                                                                                                            
     --output-dir                   Path to the directory where     [string] [required]                                                                                                   
                                    the command context will be                                                                                                                           
                                    saved to                                                                                                                                              
                                                                                                                                                                                          
     --admin-key                    Admin key                       [string] [default: "302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137"]
     --app                          Testing app name                [string] [default: "HederaNode.jar"]                                                                                  
     --block-node-mapping           Configure block-node priority   [string]                                                                                                              
                                    mapping. Default: all                                                                                                                                 
                                    block-node included, first's                                                                                                                          
                                    priority is 2. Unlisted                                                                                                                               
                                    block-node will not routed to                                                                                                                         
                                    the consensus node node.                                                                                                                              
                                    Example:  --block-node-mapping                                                                                                                        
                                     1=2,2=1                                                                                                                                              
     --cache-dir                    Local cache directory           [string] [default: "/home/runner/.solo/cache"]                                                                        
-l,  --chain-id                     Chain ID                        [string] [default: "298"]                                                                                             
     --chart-dir                    Local chart directory path      [string]                                                                                                              
                                    (e.g. ~/solo-charts/charts)                                                                                                                           
-c,  --cluster-ref                  The cluster reference that      [string]                                                                                                              
                                    will be used for referencing                                                                                                                          
                                    the Kubernetes cluster and                                                                                                                            
                                    stored in the local and remote                                                                                                                        
                                    configuration for the                                                                                                                                 
                                    deployment.  For commands that                                                                                                                        
                                    take multiple clusters they                                                                                                                           
                                    can be separated by commas.                                                                                                                           
     --consensus-node-version       Consensus node version to       [string]                                                                                                              
                                    deploy (e.g. v0.73.0 or                                                                                                                               
                                    0.73.0).                                                                                                                                              
     --debug-node-alias             Enable default jvm debug port   [string]                                                                                                              
                                    (5005) for the given node id                                                                                                                          
     --dev                          Enable developer mode           [boolean] [default: false]                                                                                            
     --domain-names                 Custom domain names for         [string]                                                                                                              
                                    consensus nodes mapping for                                                                                                                           
                                    the(e.g. node0=domain.name                                                                                                                            
                                    where key is node alias and                                                                                                                           
                                    value is domain name)with                                                                                                                             
                                    multiple nodes comma separated                                                                                                                        
     --endpoint-type                Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                                                                                            
     --external-block-node-mapping  Configure external-block-node   [string]                                                                                                              
                                    priority mapping. Default: all                                                                                                                        
                                    external-block-node included,                                                                                                                         
                                    first's priority is 2.                                                                                                                                
                                    Unlisted external-block-node                                                                                                                          
                                    will not routed to the                                                                                                                                
                                    consensus node node. Example:                                                                                                                         
                                    --external-block-node-mapping                                                                                                                         
                                    1=2,2=1                                                                                                                                               
     --force                        Force actions even if those     [boolean] [default: false]                                                                                            
                                    can be skipped                                                                                                                                        
     --force-port-forward           Force port forward to access    [boolean] [default: true]                                                                                             
                                    the network services                                                                                                                                  
     --gossip-endpoints             Comma separated gossip          [string]                                                                                                              
                                    endpoints of the node(e.g.                                                                                                                            
                                    first one is internal, second                                                                                                                         
                                    one is external)                                                                                                                                      
     --gossip-keys                  Generate gossip keys for nodes  [boolean] [default: false]                                                                                            
     --grpc-endpoints               Comma separated gRPC endpoints  [string]                                                                                                              
                                    of the node (at most 8)                                                                                                                               
     --grpc-tls-cert                TLS Certificate path for the    [string]                                                                                                              
                                    gRPC (e.g.                                                                                                                                            
                                    "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated)                                                                                                                        
     --grpc-tls-key                 TLS Certificate key path for    [string]                                                                                                              
                                    the gRPC (e.g.                                                                                                                                        
                                    "node1=/Users/username/node1-grpc.key" with multiple nodes comma separated)                                                                                                                        
     --grpc-web-endpoint            Configure gRPC Web endpoint     [Format: <address>[:<port>]]  [string]                                                                                
                                    (Default port: 8080)                                                                                                                                  
     --grpc-web-tls-cert            TLS Certificate path for gRPC   [string]                                                                                                              
                                    Web (e.g.                                                                                                                                             
                                    "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated)                                                                                                                        
     --grpc-web-tls-key             TLC Certificate key path for    [string]                                                                                                              
                                    gRPC Web (e.g.                                                                                                                                        
                                    "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma separated)                                                                                                                        
     --local-build-path             path of hedera local repo       [string]                                                                                                              
     --pvcs                         Enable persistent volume        [boolean] [default: false]                                                                                            
                                    claims to store data outside                                                                                                                          
                                    the pod, required for                                                                                                                                 
                                    consensus node add                                                                                                                                    
-q,  --quiet-mode                   Quiet mode, do not prompt for   [boolean] [default: false]                                                                                            
                                    confirmation                                                                                                                                          
-t,  --release-tag                  DEPRECATED: use                 [string] [default: "v0.74.0"]                                                                                         
                                    --consensus-node-version                                                                                                                              
                                    (e.g. v0.74.0)                                                                                                                                        
     --solo-chart-version           Solo testing chart version      [string] [default: "0.64.0"]                                                                                          
     --tls-keys                     Generate gRPC TLS keys for      [boolean] [default: false]                                                                                            
                                    nodes                                                                                                                                                 
-v,  --version                      Show version number             [boolean]                                                                                                             
     --wraps-key-path               Path to a local directory       [string]                                                                                                              
                                    containing pre-existing WRAPs                                                                                                                         
                                    proving key files (.bin)

consensus dev-node-add submit-transactions

 consensus dev-node-add submit-transactions

Submits NodeCreateTransaction and Upgrade transactions to the network nodes

Options:

-d,  --deployment                   The name the user will          [string] [required]                           
                                    reference locally to link to a                                                
                                    deployment                                                                    
     --input-dir                    Path to the directory where     [string] [required]                           
                                    the command context will be                                                   
                                    loaded from                                                                   
                                                                                                                  
     --app                          Testing app name                [string] [default: "HederaNode.jar"]          
     --block-node-mapping           Configure block-node priority   [string]                                      
                                    mapping. Default: all                                                         
                                    block-node included, first's                                                  
                                    priority is 2. Unlisted                                                       
                                    block-node will not routed to                                                 
                                    the consensus node node.                                                      
                                    Example:  --block-node-mapping                                                
                                     1=2,2=1                                                                      
     --cache-dir                    Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-l,  --chain-id                     Chain ID                        [string] [default: "298"]                     
     --chart-dir                    Local chart directory path      [string]                                      
                                    (e.g. ~/solo-charts/charts)                                                   
-c,  --cluster-ref                  The cluster reference that      [string]                                      
                                    will be used for referencing                                                  
                                    the Kubernetes cluster and                                                    
                                    stored in the local and remote                                                
                                    configuration for the                                                         
                                    deployment.  For commands that                                                
                                    take multiple clusters they                                                   
                                    can be separated by commas.                                                   
     --consensus-node-version       Consensus node version to       [string]                                      
                                    deploy (e.g. v0.73.0 or                                                       
                                    0.73.0).                                                                      
     --debug-node-alias             Enable default jvm debug port   [string]                                      
                                    (5005) for the given node id                                                  
     --dev                          Enable developer mode           [boolean] [default: false]                    
     --domain-names                 Custom domain names for         [string]                                      
                                    consensus nodes mapping for                                                   
                                    the(e.g. node0=domain.name                                                    
                                    where key is node alias and                                                   
                                    value is domain name)with                                                     
                                    multiple nodes comma separated                                                
     --endpoint-type                Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --external-block-node-mapping  Configure external-block-node   [string]                                      
                                    priority mapping. Default: all                                                
                                    external-block-node included,                                                 
                                    first's priority is 2.                                                        
                                    Unlisted external-block-node                                                  
                                    will not routed to the                                                        
                                    consensus node node. Example:                                                 
                                    --external-block-node-mapping                                                 
                                    1=2,2=1                                                                       
     --force                        Force actions even if those     [boolean] [default: false]                    
                                    can be skipped                                                                
     --force-port-forward           Force port forward to access    [boolean] [default: true]                     
                                    the network services                                                          
     --gossip-endpoints             Comma separated gossip          [string]                                      
                                    endpoints of the node(e.g.                                                    
                                    first one is internal, second                                                 
                                    one is external)                                                              
     --gossip-keys                  Generate gossip keys for nodes  [boolean] [default: false]                    
     --grpc-endpoints               Comma separated gRPC endpoints  [string]                                      
                                    of the node (at most 8)                                                       
     --grpc-tls-cert                TLS Certificate path for the    [string]                                      
                                    gRPC (e.g.                                                                    
                                    "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated)                                                
     --grpc-tls-key                 TLS Certificate key path for    [string]                                      
                                    the gRPC (e.g.                                                                
                                    "node1=/Users/username/node1-grpc.key" with multiple nodes comma separated)                                                
     --grpc-web-endpoint            Configure gRPC Web endpoint     [Format: <address>[:<port>]]  [string]        
                                    (Default port: 8080)                                                          
     --grpc-web-tls-cert            TLS Certificate path for gRPC   [string]                                      
                                    Web (e.g.                                                                     
                                    "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated)                                                
     --grpc-web-tls-key             TLC Certificate key path for    [string]                                      
                                    gRPC Web (e.g.                                                                
                                    "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma separated)                                                
     --local-build-path             path of hedera local repo       [string]                                      
     --pvcs                         Enable persistent volume        [boolean] [default: false]                    
                                    claims to store data outside                                                  
                                    the pod, required for                                                         
                                    consensus node add                                                            
-q,  --quiet-mode                   Quiet mode, do not prompt for   [boolean] [default: false]                    
                                    confirmation                                                                  
-t,  --release-tag                  DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                                    --consensus-node-version                                                      
                                    (e.g. v0.74.0)                                                                
     --solo-chart-version           Solo testing chart version      [string] [default: "0.64.0"]                  
     --tls-keys                     Generate gRPC TLS keys for      [boolean] [default: false]                    
                                    nodes                                                                         
-v,  --version                      Show version number             [boolean]                                     
     --wraps-key-path               Path to a local directory       [string]                                      
                                    containing pre-existing WRAPs                                                 
                                    proving key files (.bin)

consensus dev-node-add execute

 consensus dev-node-add execute

Executes the addition of a previously prepared node

Options:

-d,  --deployment                   The name the user will          [string] [required]                                                                                                   
                                    reference locally to link to a                                                                                                                        
                                    deployment                                                                                                                                            
     --input-dir                    Path to the directory where     [string] [required]                                                                                                   
                                    the command context will be                                                                                                                           
                                    loaded from                                                                                                                                           
                                                                                                                                                                                          
     --admin-key                    Admin key                       [string] [default: "302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137"]
     --app                          Testing app name                [string] [default: "HederaNode.jar"]                                                                                  
     --block-node-mapping           Configure block-node priority   [string]                                                                                                              
                                    mapping. Default: all                                                                                                                                 
                                    block-node included, first's                                                                                                                          
                                    priority is 2. Unlisted                                                                                                                               
                                    block-node will not routed to                                                                                                                         
                                    the consensus node node.                                                                                                                              
                                    Example:  --block-node-mapping                                                                                                                        
                                     1=2,2=1                                                                                                                                              
     --cache-dir                    Local cache directory           [string] [default: "/home/runner/.solo/cache"]                                                                        
-l,  --chain-id                     Chain ID                        [string] [default: "298"]                                                                                             
     --chart-dir                    Local chart directory path      [string]                                                                                                              
                                    (e.g. ~/solo-charts/charts)                                                                                                                           
-c,  --cluster-ref                  The cluster reference that      [string]                                                                                                              
                                    will be used for referencing                                                                                                                          
                                    the Kubernetes cluster and                                                                                                                            
                                    stored in the local and remote                                                                                                                        
                                    configuration for the                                                                                                                                 
                                    deployment.  For commands that                                                                                                                        
                                    take multiple clusters they                                                                                                                           
                                    can be separated by commas.                                                                                                                           
     --consensus-node-version       Consensus node version to       [string]                                                                                                              
                                    deploy (e.g. v0.73.0 or                                                                                                                               
                                    0.73.0).                                                                                                                                              
     --debug-node-alias             Enable default jvm debug port   [string]                                                                                                              
                                    (5005) for the given node id                                                                                                                          
     --dev                          Enable developer mode           [boolean] [default: false]                                                                                            
     --domain-names                 Custom domain names for         [string]                                                                                                              
                                    consensus nodes mapping for                                                                                                                           
                                    the(e.g. node0=domain.name                                                                                                                            
                                    where key is node alias and                                                                                                                           
                                    value is domain name)with                                                                                                                             
                                    multiple nodes comma separated                                                                                                                        
     --endpoint-type                Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                                                                                            
     --envoy-ips                    IP mapping where key = value    [string]                                                                                                              
                                    is node alias and static ip                                                                                                                           
                                    for envoy proxy, (e.g.:                                                                                                                               
                                    --envoy-ips                                                                                                                                           
                                    node1=127.0.0.1,node2=127.0.0.1)                                                                                                                        
     --external-block-node-mapping  Configure external-block-node   [string]                                                                                                              
                                    priority mapping. Default: all                                                                                                                        
                                    external-block-node included,                                                                                                                         
                                    first's priority is 2.                                                                                                                                
                                    Unlisted external-block-node                                                                                                                          
                                    will not routed to the                                                                                                                                
                                    consensus node node. Example:                                                                                                                         
                                    --external-block-node-mapping                                                                                                                         
                                    1=2,2=1                                                                                                                                               
     --force                        Force actions even if those     [boolean] [default: false]                                                                                            
                                    can be skipped                                                                                                                                        
     --force-port-forward           Force port forward to access    [boolean] [default: true]                                                                                             
                                    the network services                                                                                                                                  
     --gossip-endpoints             Comma separated gossip          [string]                                                                                                              
                                    endpoints of the node(e.g.                                                                                                                            
                                    first one is internal, second                                                                                                                         
                                    one is external)                                                                                                                                      
     --gossip-keys                  Generate gossip keys for nodes  [boolean] [default: false]                                                                                            
     --grpc-endpoints               Comma separated gRPC endpoints  [string]                                                                                                              
                                    of the node (at most 8)                                                                                                                               
     --grpc-tls-cert                TLS Certificate path for the    [string]                                                                                                              
                                    gRPC (e.g.                                                                                                                                            
                                    "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated)                                                                                                                        
     --grpc-tls-key                 TLS Certificate key path for    [string]                                                                                                              
                                    the gRPC (e.g.                                                                                                                                        
                                    "node1=/Users/username/node1-grpc.key" with multiple nodes comma separated)                                                                                                                        
     --grpc-web-endpoint            Configure gRPC Web endpoint     [Format: <address>[:<port>]]  [string]                                                                                
                                    (Default port: 8080)                                                                                                                                  
     --grpc-web-tls-cert            TLS Certificate path for gRPC   [string]                                                                                                              
                                    Web (e.g.                                                                                                                                             
                                    "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated)                                                                                                                        
     --grpc-web-tls-key             TLC Certificate key path for    [string]                                                                                                              
                                    gRPC Web (e.g.                                                                                                                                        
                                    "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma separated)                                                                                                                        
     --haproxy-ips                  IP mapping where key = value    [string]                                                                                                              
                                    is node alias and static ip                                                                                                                           
                                    for haproxy, (e.g.:                                                                                                                                   
                                    --haproxy-ips                                                                                                                                         
                                    node1=127.0.0.1,node2=127.0.0.1)                                                                                                                        
     --local-build-path             path of hedera local repo       [string]                                                                                                              
     --pvcs                         Enable persistent volume        [boolean] [default: false]                                                                                            
                                    claims to store data outside                                                                                                                          
                                    the pod, required for                                                                                                                                 
                                    consensus node add                                                                                                                                    
-q,  --quiet-mode                   Quiet mode, do not prompt for   [boolean] [default: false]                                                                                            
                                    confirmation                                                                                                                                          
-t,  --release-tag                  DEPRECATED: use                 [string] [default: "v0.74.0"]                                                                                         
                                    --consensus-node-version                                                                                                                              
                                    (e.g. v0.74.0)                                                                                                                                        
     --solo-chart-version           Solo testing chart version      [string] [default: "0.64.0"]                                                                                          
     --tls-keys                     Generate gRPC TLS keys for      [boolean] [default: false]                                                                                            
                                    nodes                                                                                                                                                 
-v,  --version                      Show version number             [boolean]                                                                                                             
     --wraps-key-path               Path to a local directory       [string]                                                                                                              
                                    containing pre-existing WRAPs                                                                                                                         
                                    proving key files (.bin)

consensus dev-node-update

 consensus dev-node-update

Dev operations for updating consensus nodes

Commands:
  consensus dev-node-update prepare               Prepare the deployment to update a node with a specific version of Hedera platform
  consensus dev-node-update submit-transactions   Submit transactions for updating a node with a specific version of Hedera platform
  consensus dev-node-update execute               Executes the updating of a node with a specific version of Hedera platform

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus dev-node-update prepare

 consensus dev-node-update prepare

Prepare the deployment to update a node with a specific version of Hedera platform

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
     --node-alias              Node alias (e.g. node99)        [string] [required]                           
     --output-dir              Path to the directory where     [string] [required]                           
                               the command context will be                                                   
                               saved to                                                                      
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir               Local chart directory path      [string]                                      
                               (e.g. ~/solo-charts/charts)                                                   
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --debug-node-alias        Enable default jvm debug port   [string]                                      
                               (5005) for the given node id                                                  
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --force                   Force actions even if those     [boolean] [default: false]                    
                               can be skipped                                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --gossip-endpoints        Comma separated gossip          [string]                                      
                               endpoints of the node(e.g.                                                    
                               first one is internal, second                                                 
                               one is external)                                                              
     --gossip-private-key      path and file name of the       [string]                                      
                               private key for signing gossip                                                
                               in PEM key format to be used                                                  
     --gossip-public-key       path and file name of the       [string]                                      
                               public key for signing gossip                                                 
                               in PEM key format to be used                                                  
     --grpc-endpoints          Comma separated gRPC endpoints  [string]                                      
                               of the node (at most 8)                                                       
     --local-build-path        path of hedera local repo       [string]                                      
     --new-account-number      new account number for node     [string]                                      
                               update transaction                                                            
     --new-admin-key           new admin key for the Hedera    [string]                                      
                               account                                                                       
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                  
     --tls-private-key         path and file name of the       [string]                                      
                               private TLS key to be used                                                    
     --tls-public-key          path and file name of the       [string]                                      
                               public TLS key to be used                                                     
-v,  --version                 Show version number             [boolean]                                     
     --wraps-key-path          Path to a local directory       [string]                                      
                               containing pre-existing WRAPs                                                 
                               proving key files (.bin)

consensus dev-node-update submit-transactions

 consensus dev-node-update submit-transactions

Submit transactions for updating a node with a specific version of Hedera platform

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
     --input-dir               Path to the directory where     [string] [required]                           
                               the command context will be                                                   
                               loaded from                                                                   
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir               Local chart directory path      [string]                                      
                               (e.g. ~/solo-charts/charts)                                                   
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --debug-node-alias        Enable default jvm debug port   [string]                                      
                               (5005) for the given node id                                                  
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --force                   Force actions even if those     [boolean] [default: false]                    
                               can be skipped                                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --gossip-endpoints        Comma separated gossip          [string]                                      
                               endpoints of the node(e.g.                                                    
                               first one is internal, second                                                 
                               one is external)                                                              
     --grpc-endpoints          Comma separated gRPC endpoints  [string]                                      
                               of the node (at most 8)                                                       
     --local-build-path        path of hedera local repo       [string]                                      
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                  
-v,  --version                 Show version number             [boolean]                                     
     --wraps-key-path          Path to a local directory       [string]                                      
                               containing pre-existing WRAPs                                                 
                               proving key files (.bin)

consensus dev-node-update execute

 consensus dev-node-update execute

Executes the updating of a node with a specific version of Hedera platform

Options:

-d,  --deployment              The name the user will          [string] [required]                                                                                                   
                               reference locally to link to a                                                                                                                        
                               deployment                                                                                                                                            
     --input-dir               Path to the directory where     [string] [required]                                                                                                   
                               the command context will be                                                                                                                           
                               loaded from                                                                                                                                           
                                                                                                                                                                                     
     --admin-key               Admin key                       [string] [default: "302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137"]
     --app                     Testing app name                [string] [default: "HederaNode.jar"]                                                                                  
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]                                                                        
     --chart-dir               Local chart directory path      [string]                                                                                                              
                               (e.g. ~/solo-charts/charts)                                                                                                                           
     --consensus-node-version  Consensus node version to       [string]                                                                                                              
                               deploy (e.g. v0.73.0 or                                                                                                                               
                               0.73.0).                                                                                                                                              
     --debug-node-alias        Enable default jvm debug port   [string]                                                                                                              
                               (5005) for the given node id                                                                                                                          
     --dev                     Enable developer mode           [boolean] [default: false]                                                                                            
     --domain-names            Custom domain names for         [string]                                                                                                              
                               consensus nodes mapping for                                                                                                                           
                               the(e.g. node0=domain.name                                                                                                                            
                               where key is node alias and                                                                                                                           
                               value is domain name)with                                                                                                                             
                               multiple nodes comma separated                                                                                                                        
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                                                                                            
     --force                   Force actions even if those     [boolean] [default: false]                                                                                            
                               can be skipped                                                                                                                                        
     --force-port-forward      Force port forward to access    [boolean] [default: true]                                                                                             
                               the network services                                                                                                                                  
     --gossip-endpoints        Comma separated gossip          [string]                                                                                                              
                               endpoints of the node(e.g.                                                                                                                            
                               first one is internal, second                                                                                                                         
                               one is external)                                                                                                                                      
     --grpc-endpoints          Comma separated gRPC endpoints  [string]                                                                                                              
                               of the node (at most 8)                                                                                                                               
     --local-build-path        path of hedera local repo       [string]                                                                                                              
     --new-account-number      new account number for node     [string]                                                                                                              
                               update transaction                                                                                                                                    
     --new-admin-key           new admin key for the Hedera    [string]                                                                                                              
                               account                                                                                                                                               
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                                                                                            
                               confirmation                                                                                                                                          
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                                                                                         
                               --consensus-node-version                                                                                                                              
                               (e.g. v0.74.0)                                                                                                                                        
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                                                                                          
-v,  --version                 Show version number             [boolean]                                                                                                             
     --wraps-key-path          Path to a local directory       [string]                                                                                                              
                               containing pre-existing WRAPs                                                                                                                         
                               proving key files (.bin)

consensus dev-node-upgrade

 consensus dev-node-upgrade

Dev operations for upgrading consensus nodes

Commands:
  consensus dev-node-upgrade prepare               Prepare for upgrading network
  consensus dev-node-upgrade submit-transactions   Submit transactions for upgrading network
  consensus dev-node-upgrade execute               Executes the upgrading the network

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus dev-node-upgrade prepare

 consensus dev-node-upgrade prepare

Prepare for upgrading network

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
     --output-dir          Path to the directory where     [string] [required]                           
                           the command context will be                                                   
                           saved to                                                                      
                                                                                                         
     --app                 Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir           Local chart directory path      [string]                                      
                           (e.g. ~/solo-charts/charts)                                                   
     --debug-node-alias    Enable default jvm debug port   [string]                                      
                           (5005) for the given node id                                                  
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force               Force actions even if those     [boolean] [default: false]                    
                           can be skipped                                                                
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
     --local-build-path    path of hedera local repo       [string]                                      
-i,  --node-aliases        Comma separated node aliases    [string]                                      
                           (empty means all nodes)                                                       
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --solo-chart-version  Solo testing chart version      [string] [default: "0.64.0"]                  
     --upgrade-zip-file    A zipped file used for network  [string]                                      
                           upgrade                                                                       
-v,  --version             Show version number             [boolean]

consensus dev-node-upgrade submit-transactions

 consensus dev-node-upgrade submit-transactions

Submit transactions for upgrading network

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
     --input-dir           Path to the directory where     [string] [required]                           
                           the command context will be                                                   
                           loaded from                                                                   
                                                                                                         
     --app                 Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir           Local chart directory path      [string]                                      
                           (e.g. ~/solo-charts/charts)                                                   
     --debug-node-alias    Enable default jvm debug port   [string]                                      
                           (5005) for the given node id                                                  
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force               Force actions even if those     [boolean] [default: false]                    
                           can be skipped                                                                
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
     --local-build-path    path of hedera local repo       [string]                                      
-i,  --node-aliases        Comma separated node aliases    [string]                                      
                           (empty means all nodes)                                                       
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --solo-chart-version  Solo testing chart version      [string] [default: "0.64.0"]                  
     --upgrade-zip-file    A zipped file used for network  [string]                                      
                           upgrade                                                                       
-v,  --version             Show version number             [boolean]

consensus dev-node-upgrade execute

 consensus dev-node-upgrade execute

Executes the upgrading the network

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
     --input-dir           Path to the directory where     [string] [required]                           
                           the command context will be                                                   
                           loaded from                                                                   
                                                                                                         
     --app                 Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir           Local chart directory path      [string]                                      
                           (e.g. ~/solo-charts/charts)                                                   
     --debug-node-alias    Enable default jvm debug port   [string]                                      
                           (5005) for the given node id                                                  
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force               Force actions even if those     [boolean] [default: false]                    
                           can be skipped                                                                
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
     --local-build-path    path of hedera local repo       [string]                                      
-i,  --node-aliases        Comma separated node aliases    [string]                                      
                           (empty means all nodes)                                                       
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --solo-chart-version  Solo testing chart version      [string] [default: "0.64.0"]                  
     --upgrade-zip-file    A zipped file used for network  [string]                                      
                           upgrade                                                                       
-v,  --version             Show version number             [boolean]

consensus dev-node-delete

 consensus dev-node-delete

Dev operations for delete consensus nodes

Commands:
  consensus dev-node-delete prepare               Prepares the deletion of a node with a specific version of Hedera platform
  consensus dev-node-delete submit-transactions   Submits transactions to the network nodes for deleting a node
  consensus dev-node-delete execute               Executes the deletion of a previously prepared node

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus dev-node-delete prepare

 consensus dev-node-delete prepare

Prepares the deletion of a node with a specific version of Hedera platform

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
     --node-alias              Node alias (e.g. node99)        [string] [required]                           
     --output-dir              Path to the directory where     [string] [required]                           
                               the command context will be                                                   
                               saved to                                                                      
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-l,  --chain-id                Chain ID                        [string] [default: "298"]                     
     --chart-dir               Local chart directory path      [string]                                      
                               (e.g. ~/solo-charts/charts)                                                   
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --debug-node-alias        Enable default jvm debug port   [string]                                      
                               (5005) for the given node id                                                  
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --force                   Force actions even if those     [boolean] [default: false]                    
                               can be skipped                                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --local-build-path        path of hedera local repo       [string]                                      
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                  
-v,  --version                 Show version number             [boolean]

consensus dev-node-delete submit-transactions

 consensus dev-node-delete submit-transactions

Submits transactions to the network nodes for deleting a node

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
     --input-dir               Path to the directory where     [string] [required]                           
                               the command context will be                                                   
                               loaded from                                                                   
     --node-alias              Node alias (e.g. node99)        [string] [required]                           
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-l,  --chain-id                Chain ID                        [string] [default: "298"]                     
     --chart-dir               Local chart directory path      [string]                                      
                               (e.g. ~/solo-charts/charts)                                                   
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --debug-node-alias        Enable default jvm debug port   [string]                                      
                               (5005) for the given node id                                                  
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --force                   Force actions even if those     [boolean] [default: false]                    
                               can be skipped                                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --local-build-path        path of hedera local repo       [string]                                      
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                  
-v,  --version                 Show version number             [boolean]

consensus dev-node-delete execute

 consensus dev-node-delete execute

Executes the deletion of a previously prepared node

Options:

-d,  --deployment              The name the user will          [string] [required]                           
                               reference locally to link to a                                                
                               deployment                                                                    
     --input-dir               Path to the directory where     [string] [required]                           
                               the command context will be                                                   
                               loaded from                                                                   
     --node-alias              Node alias (e.g. node99)        [string] [required]                           
                                                                                                             
     --app                     Testing app name                [string] [default: "HederaNode.jar"]          
     --cache-dir               Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-l,  --chain-id                Chain ID                        [string] [default: "298"]                     
     --chart-dir               Local chart directory path      [string]                                      
                               (e.g. ~/solo-charts/charts)                                                   
     --consensus-node-version  Consensus node version to       [string]                                      
                               deploy (e.g. v0.73.0 or                                                       
                               0.73.0).                                                                      
     --debug-node-alias        Enable default jvm debug port   [string]                                      
                               (5005) for the given node id                                                  
     --dev                     Enable developer mode           [boolean] [default: false]                    
     --domain-names            Custom domain names for         [string]                                      
                               consensus nodes mapping for                                                   
                               the(e.g. node0=domain.name                                                    
                               where key is node alias and                                                   
                               value is domain name)with                                                     
                               multiple nodes comma separated                                                
     --endpoint-type           Endpoint type (IP or FQDN)      [string] [default: "FQDN"]                    
     --force                   Force actions even if those     [boolean] [default: false]                    
                               can be skipped                                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]                     
                               the network services                                                          
     --local-build-path        path of hedera local repo       [string]                                      
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]                    
                               confirmation                                                                  
-t,  --release-tag             DEPRECATED: use                 [string] [default: "v0.74.0"]                 
                               --consensus-node-version                                                      
                               (e.g. v0.74.0)                                                                
     --solo-chart-version      Solo testing chart version      [string] [default: "0.64.0"]                  
-v,  --version                 Show version number             [boolean]

consensus dev-freeze

 consensus dev-freeze

Dev operations for freezing consensus nodes

Commands:
  consensus dev-freeze prepare-upgrade   Prepare the network for a Freeze Upgrade operation
  consensus dev-freeze freeze-upgrade    Performs a Freeze Upgrade operation with on the network after it has been prepared with prepare-upgrade

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

consensus dev-freeze prepare-upgrade

 consensus dev-freeze prepare-upgrade

Prepare the network for a Freeze Upgrade operation

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --skip-node-alias     The node alias to skip,         [string]                                      
                           because of a                                                                  
                           NodeUpdateTransaction or it is                                                
                           down (e.g. node99)                                                            
-v,  --version             Show version number             [boolean]

consensus dev-freeze freeze-upgrade

 consensus dev-freeze freeze-upgrade

Performs a Freeze Upgrade operation with on the network after it has been prepared with prepare-upgrade

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --skip-node-alias     The node alias to skip,         [string]                                      
                           because of a                                                                  
                           NodeUpdateTransaction or it is                                                
                           down (e.g. node99)                                                            
-v,  --version             Show version number             [boolean]

deployment

 deployment

Create, modify, and delete deployment configurations. Deployments are required for most of the other commands.

Commands:
  deployment cluster       View and manage Solo cluster references used by a deployment.
  deployment config        List, view, create, delete, and import deployments. These commands affect the local configuration only.
  deployment state         View the actual state of the deployment on the Kubernetes clusters or teardown/destroy all remote and local configuration for a given deployment.
  deployment refresh       Refresh port-forward processes for all components in the deployment.
  deployment diagnostics   Capture diagnostic information such as logs, signed states, and ledger/network/node configurations.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

deployment cluster

 deployment cluster

View and manage Solo cluster references used by a deployment.

Commands:
  deployment cluster attach   Attaches a cluster reference to a deployment.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

deployment cluster attach

 deployment cluster attach

Attaches a cluster reference to a deployment.

Options:

-c,  --cluster-ref                 The cluster reference that      [string] [required]                                          
                                   will be used for referencing                                                                 
                                   the Kubernetes cluster and                                                                   
                                   stored in the local and remote                                                               
                                   configuration for the                                                                        
                                   deployment.  For commands that                                                               
                                   take multiple clusters they                                                                  
                                   can be separated by commas.                                                                  
-d,  --deployment                  The name the user will          [string] [required]                                          
                                   reference locally to link to a                                                               
                                   deployment                                                                                   
                                                                                                                                
     --dev                         Enable developer mode           [boolean] [default: false]                                   
     --dns-base-domain             Base domain for the DNS is the  [string] [default: "cluster.local"]                          
                                   suffix used to construct the                                                                 
                                   fully qualified domain name                                                                  
                                   (FQDN)                                                                                       
     --dns-consensus-node-pattern  Pattern to construct the        [string] [default: "network-{nodeAlias}-svc.{namespace}.svc"]
                                   prefix for the fully qualified                                                               
                                   domain name (FQDN) for the                                                                   
                                   consensus node, the suffix is                                                                
                                   provided by the                                                                              
                                   --dns-base-domain  option (ex.                                                               
                                   network-{nodeAlias}-svc.{namespace}.svc)                                                               
     --enable-cert-manager         Pass the flag to enable cert    [boolean] [default: false]                                   
                                   manager                                                                                      
     --force-port-forward          Force port forward to access    [boolean] [default: true]                                    
                                   the network services                                                                         
     --num-consensus-nodes         Used to specify desired number  [number]                                                     
                                   of consensus nodes for                                                                       
                                   pre-genesis deployments                                                                      
-q,  --quiet-mode                  Quiet mode, do not prompt for   [boolean] [default: false]                                   
                                   confirmation                                                                                 
-v,  --version                     Show version number             [boolean]

deployment config

 deployment config

List, view, create, delete, and import deployments. These commands affect the local configuration only.

Commands:
  deployment config list     Lists all local deployment configurations or deployments in a specific cluster.
  deployment config create   Creates a new local deployment configuration.
  deployment config delete   Removes a local deployment configuration.
  deployment config info     Displays the full status of a deployment including components, versions, and port-forward status.
  deployment config ports    List all port-forwards for a deployment. JSON and YAMl output formats, create files containing the data

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

deployment config list

 deployment config list

Lists all local deployment configurations or deployments in a specific cluster.

Options:

                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment config create

 deployment config create

Creates a new local deployment configuration.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
-n,  --namespace           Namespace                       [string] [required]       
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
     --realm               Realm number. Requires          [number] [default: 0]     
                           network-node > v61.0 for                                  
                           non-zero values                                           
     --shard               Shard number. Requires          [number] [default: 0]     
                           network-node > v61.0 for                                  
                           non-zero values                                           
-v,  --version             Show version number             [boolean]

deployment config delete

 deployment config delete

Removes a local deployment configuration.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment config info

 deployment config info

Displays the full status of a deployment including components, versions, and port-forward status.

Options:

                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment config ports

 deployment config ports

List all port-forwards for a deployment. JSON and YAMl output formats, create files containing the data

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-c,  --cluster-ref         The cluster reference that      [string]                                      
                           will be used for referencing                                                  
                           the Kubernetes cluster and                                                    
                           stored in the local and remote                                                
                           configuration for the                                                         
                           deployment.  For commands that                                                
                           take multiple clusters they                                                   
                           can be separated by commas.                                                   
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-o,  --output              Output format. One of:          [string]                                      
                           json|yaml|wide                                                                
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-v,  --version             Show version number             [boolean]

deployment state

 deployment state

View the actual state of the deployment on the Kubernetes clusters or teardown/destroy all remote and local configuration for a given deployment.

Commands:
  deployment state images   Lists every pod in the deployment namespace and shows its running container image. Useful to verify that a locally-built image was loaded correctly.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

deployment state images

 deployment state images

Lists every pod in the deployment namespace and shows its running container image. Useful to verify that a locally-built image was loaded correctly.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment refresh

 deployment refresh

Refresh port-forward processes for all components in the deployment.

Commands:
  deployment refresh port-forwards   Refresh and restore killed port-forward processes.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

deployment refresh port-forwards

 deployment refresh port-forwards

Refresh and restore killed port-forward processes.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment diagnostics

 deployment diagnostics

Capture diagnostic information such as logs, signed states, and ledger/network/node configurations.

Commands:
  deployment diagnostics all           Captures logs, configs, and diagnostic artifacts from all consensus nodes and test connections.
  deployment diagnostics debug         Similar to diagnostics all subcommand, but creates a zip archive for easy sharing.
  deployment diagnostics connections   Tests connections to Consensus, Relay, Explorer, Mirror and Block nodes.
  deployment diagnostics logs          Get logs and configuration files from consensus node/nodes.
  deployment diagnostics analyze       Analyze a previously collected diagnostics logs directory for common failure signatures.
  deployment diagnostics report        Collect diagnostic logs and create a GitHub issue using the gh CLI.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

deployment diagnostics all

 deployment diagnostics all

Captures logs, configs, and diagnostic artifacts from all consensus nodes and test connections.

Options:

                                                                                     
     --check               Fail if any configured remote   [boolean] [default: false]
                           port-forward is not reachable                             
                           locally                                                   
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment diagnostics debug

 deployment diagnostics debug

Similar to diagnostics all subcommand, but creates a zip archive for easy sharing.

Options:

                                                                                     
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --output-dir          Path to the directory where     [string]                  
                           the command context will be                               
                           saved to                                                  
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment diagnostics connections

 deployment diagnostics connections

Tests connections to Consensus, Relay, Explorer, Mirror and Block nodes.

Options:

                                                                                     
     --check               Fail if any configured remote   [boolean] [default: false]
                           port-forward is not reachable                             
                           locally                                                   
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment diagnostics logs

 deployment diagnostics logs

Get logs and configuration files from consensus node/nodes.

Options:

                                                                                     
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --output-dir          Path to the directory where     [string]                  
                           the command context will be                               
                           saved to                                                  
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment diagnostics analyze

 deployment diagnostics analyze

Analyze a previously collected diagnostics logs directory for common failure signatures.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --input-dir           Path to the directory where     [string]                  
                           the command context will be                               
                           loaded from                                               
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

deployment diagnostics report

 deployment diagnostics report

Collect diagnostic logs and create a GitHub issue using the gh CLI.

Options:

                                                                                     
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --output-dir          Path to the directory where     [string]                  
                           the command context will be                               
                           saved to                                                  
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

explorer

 explorer

Explorer Node operations for creating, modifying, and destroying resources.These commands require the presence of an existing deployment.

Commands:
  explorer node   List, create, manage, or destroy explorer node instances. Operates on a single explorer node instance at a time.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

explorer node

 explorer node

List, create, manage, or destroy explorer node instances. Operates on a single explorer node instance at a time.

Commands:
  explorer node add       Adds and configures a new node instance.
  explorer node destroy   Deletes the specified node from the deployment.
  explorer node upgrade   Upgrades the specified node in the deployment.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

explorer node add

 explorer node add

Adds and configures a new node instance.

Options:

-d,  --deployment                     The name the user will          [string] [required]                           
                                      reference locally to link to a                                                
                                      deployment                                                                    
                                                                                                                    
     --cache-dir                      Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir                      Local chart directory path      [string]                                      
                                      (e.g. ~/solo-charts/charts)                                                   
-c,  --cluster-ref                    The cluster reference that      [string]                                      
                                      will be used for referencing                                                  
                                      the Kubernetes cluster and                                                    
                                      stored in the local and remote                                                
                                      configuration for the                                                         
                                      deployment.  For commands that                                                
                                      take multiple clusters they                                                   
                                      can be separated by commas.                                                   
-s,  --cluster-setup-namespace        Cluster Setup Namespace         [string] [default: "solo-setup"]              
     --component-image                ,  --relay-image   Docker       [string]                                      
                                      image override. Accepts a                                                     
                                      registry reference (e.g.                                                      
                                      ghcr.io/hiero-ledger/block-node-server:0.36.0) or a local reference (e.g. block-node-server:0.36.0-SNAPSHOT). Local images found in Docker are automatically loaded into the Kind cluster.                                                
     --dev                            Enable developer mode           [boolean] [default: false]                    
     --domain-name                    Custom domain name              [string]                                      
     --enable-explorer-tls            Enable Explorer TLS, defaults   [boolean] [default: false]                    
                                      to false, requires certManager                                                
                                      and certManagerCrds, which can                                                
                                      be deployed through                                                           
                                      solo-cluster-setup chart or                                                   
                                      standalone                                                                    
     --enable-ingress                 enable ingress on the           [boolean] [default: false]                    
                                      component/pod                                                                 
     --explorer-chart-dir             Explorer local chart directory  [string]                                      
                                      path (e.g.                                                                    
                                      ~/hiero-mirror-node-explorer/charts)                                                
     --explorer-static-ip             The static IP address to use    [string]                                      
                                      for the Explorer load                                                         
                                      balancer, defaults to ""                                                      
     --explorer-tls-host-name         The host name to use for the    [string] [default: "explorer.solo.local"]     
                                      Explorer TLS, defaults to                                                     
                                      "explorer.solo.local"                                                         
     --explorer-version               Explorer chart version          [string] [default: "26.1.0"]                  
     --external-address               Bind address for kubectl        [string]                                      
                                      port-forward (for example                                                     
                                      127.0.0.1 or 0.0.0.0)                                                         
     --force-port-forward             Force port forward to access    [boolean] [default: true]                     
                                      the network services                                                          
     --ingress-controller-value-file  The value file to use for       [string]                                      
                                      ingress controller, defaults                                                  
                                      to ""                                                                         
     --mirror-namespace               Namespace to use for the        [string]                                      
                                      Mirror Node deployment, a new                                                 
                                      one will be created if it does                                                
                                      not exist                                                                     
     --mirror-node-id                 The id of the mirror node       [number]                                      
                                      which to connect                                                              
-n,  --namespace                      Namespace                       [string]                                      
-q,  --quiet-mode                     Quiet mode, do not prompt for   [boolean] [default: false]                    
                                      confirmation                                                                  
     --solo-chart-version             Solo testing chart version      [string] [default: "0.64.0"]                  
     --tls-cluster-issuer-type        The TLS cluster issuer type to  [string] [default: "self-signed"]             
                                      use for hedera explorer,                                                      
                                      defaults to "self-signed", the                                                
                                      available options are:                                                        
                                      "acme-staging", "acme-prod",                                                  
                                      or "self-signed"                                                              
-f,  --values-file                    Comma separated chart values    [string]                                      
                                      file                                                                          
-v,  --version                        Show version number             [boolean]

explorer node destroy

 explorer node destroy

Deletes the specified node from the deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --chart-dir           Local chart directory path      [string]                  
                           (e.g. ~/solo-charts/charts)                               
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force               Force actions even if those     [boolean] [default: false]
                           can be skipped                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

explorer node upgrade

 explorer node upgrade

Upgrades the specified node in the deployment.

Options:

-d,  --deployment                     The name the user will          [string] [required]                           
                                      reference locally to link to a                                                
                                      deployment                                                                    
                                                                                                                    
     --cache-dir                      Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir                      Local chart directory path      [string]                                      
                                      (e.g. ~/solo-charts/charts)                                                   
-c,  --cluster-ref                    The cluster reference that      [string]                                      
                                      will be used for referencing                                                  
                                      the Kubernetes cluster and                                                    
                                      stored in the local and remote                                                
                                      configuration for the                                                         
                                      deployment.  For commands that                                                
                                      take multiple clusters they                                                   
                                      can be separated by commas.                                                   
-s,  --cluster-setup-namespace        Cluster Setup Namespace         [string] [default: "solo-setup"]              
     --component-image                ,  --relay-image   Docker       [string]                                      
                                      image override. Accepts a                                                     
                                      registry reference (e.g.                                                      
                                      ghcr.io/hiero-ledger/block-node-server:0.36.0) or a local reference (e.g. block-node-server:0.36.0-SNAPSHOT). Local images found in Docker are automatically loaded into the Kind cluster.                                                
     --dev                            Enable developer mode           [boolean] [default: false]                    
     --domain-name                    Custom domain name              [string]                                      
     --enable-explorer-tls            Enable Explorer TLS, defaults   [boolean] [default: false]                    
                                      to false, requires certManager                                                
                                      and certManagerCrds, which can                                                
                                      be deployed through                                                           
                                      solo-cluster-setup chart or                                                   
                                      standalone                                                                    
     --enable-ingress                 enable ingress on the           [boolean] [default: false]                    
                                      component/pod                                                                 
     --explorer-chart-dir             Explorer local chart directory  [string]                                      
                                      path (e.g.                                                                    
                                      ~/hiero-mirror-node-explorer/charts)                                                
     --explorer-static-ip             The static IP address to use    [string]                                      
                                      for the Explorer load                                                         
                                      balancer, defaults to ""                                                      
     --explorer-tls-host-name         The host name to use for the    [string] [default: "explorer.solo.local"]     
                                      Explorer TLS, defaults to                                                     
                                      "explorer.solo.local"                                                         
     --explorer-version               Explorer chart version          [string] [default: "26.1.0"]                  
     --external-address               Bind address for kubectl        [string]                                      
                                      port-forward (for example                                                     
                                      127.0.0.1 or 0.0.0.0)                                                         
     --force-port-forward             Force port forward to access    [boolean] [default: true]                     
                                      the network services                                                          
     --id                             The numeric identifier for the  [number]                                      
                                      component                                                                     
     --ingress-controller-value-file  The value file to use for       [string]                                      
                                      ingress controller, defaults                                                  
                                      to ""                                                                         
     --mirror-namespace               Namespace to use for the        [string]                                      
                                      Mirror Node deployment, a new                                                 
                                      one will be created if it does                                                
                                      not exist                                                                     
     --mirror-node-id                 The id of the mirror node       [number]                                      
                                      which to connect                                                              
-n,  --namespace                      Namespace                       [string]                                      
-q,  --quiet-mode                     Quiet mode, do not prompt for   [boolean] [default: false]                    
                                      confirmation                                                                  
     --solo-chart-version             Solo testing chart version      [string] [default: "0.64.0"]                  
     --tls-cluster-issuer-type        The TLS cluster issuer type to  [string] [default: "self-signed"]             
                                      use for hedera explorer,                                                      
                                      defaults to "self-signed", the                                                
                                      available options are:                                                        
                                      "acme-staging", "acme-prod",                                                  
                                      or "self-signed"                                                              
-f,  --values-file                    Comma separated chart values    [string]                                      
                                      file                                                                          
-v,  --version                        Show version number             [boolean]

keys

 keys

Consensus key generation operations

Commands:
  keys consensus   Generate unique cryptographic keys (gossip or grpc TLS keys) for the Consensus Node instances.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

keys consensus

 keys consensus

Generate unique cryptographic keys (gossip or grpc TLS keys) for the Consensus Node instances.

Commands:
  keys consensus generate   Generates TLS keys required for consensus node communication.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

keys consensus generate

 keys consensus generate

Generates TLS keys required for consensus node communication.

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
     --gossip-keys         Generate gossip keys for nodes  [boolean] [default: false]                    
-n,  --namespace           Namespace                       [string]                                      
-i,  --node-aliases        Comma separated node aliases    [string]                                      
                           (empty means all nodes)                                                       
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --tls-keys            Generate gRPC TLS keys for      [boolean] [default: false]                    
                           nodes                                                                         
-v,  --version             Show version number             [boolean]

ledger

 ledger

System, Account, and Crypto ledger-based management operations. These commands require an operational set of consensus nodes and may require an operational mirror node.

Commands:
  ledger system    Perform a full ledger initialization on a new deployment, rekey privileged/system accounts, or setup network staking parameters.
  ledger account   View, list, create, update, delete, and import ledger accounts.
  ledger file      Upload or update files on the Hiero network.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

ledger system

 ledger system

Perform a full ledger initialization on a new deployment, rekey privileged/system accounts, or setup network staking parameters.

Commands:
  ledger system init    Re-keys ledger system accounts and consensus node admin keys with uniquely generated ED25519 private keys and will stake consensus nodes.
  ledger system reset   Resets the ledger system to genesis by clearing saved states and ledger-related secrets.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

ledger system init

 ledger system init

Re-keys ledger system accounts and consensus node admin keys with uniquely generated ED25519 private keys and will stake consensus nodes.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-i,  --node-aliases        Comma separated node aliases    [string]                  
                           (empty means all nodes)                                   
-v,  --version             Show version number             [boolean]

ledger system reset

 ledger system reset

Resets the ledger system to genesis by clearing saved states and ledger-related secrets.

Options:

                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-i,  --node-aliases        Comma separated node aliases    [string]                  
                           (empty means all nodes)                                   
-v,  --version             Show version number             [boolean]

ledger account

 ledger account

View, list, create, update, delete, and import ledger accounts.

Commands:
  ledger account update       Updates an existing ledger account.
  ledger account create       Creates a new ledger account.
  ledger account info         Gets the account info including the current amount of HBAR
  ledger account predefined   Creates predefined accounts used by one-shot deployments.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

ledger account update

 ledger account update

Updates an existing ledger account.

Options:

     --account-id           The Hedera account id, e.g.:    [string] [required]       
                            0.0.1001                                                  
-d,  --deployment           The name the user will          [string] [required]       
                            reference locally to link to a                            
                            deployment                                                
                                                                                      
-c,  --cluster-ref          The cluster reference that      [string]                  
                            will be used for referencing                              
                            the Kubernetes cluster and                                
                            stored in the local and remote                            
                            configuration for the                                     
                            deployment.  For commands that                            
                            take multiple clusters they                               
                            can be separated by commas.                               
     --dev                  Enable developer mode           [boolean] [default: false]
     --ecdsa-private-key    Specify a hex-encoded ECDSA     [string]                  
                            private key for the Hedera                                
                            account                                                   
     --ed25519-private-key  Specify a hex-encoded ED25519   [string]                  
                            private key for the Hedera                                
                            account                                                   
     --force-port-forward   Force port forward to access    [boolean] [default: true] 
                            the network services                                      
     --hbar-amount          Amount of HBAR to add           [number] [default: 100]   
-v,  --version              Show version number             [boolean]

ledger account create

 ledger account create

Creates a new ledger account.

Options:

-d,  --deployment           The name the user will          [string] [required]       
                            reference locally to link to a                            
                            deployment                                                
                                                                                      
-c,  --cluster-ref          The cluster reference that      [string]                  
                            will be used for referencing                              
                            the Kubernetes cluster and                                
                            stored in the local and remote                            
                            configuration for the                                     
                            deployment.  For commands that                            
                            take multiple clusters they                               
                            can be separated by commas.                               
     --create-amount        Amount of new account to        [number] [default: 1]     
                            create                                                    
     --dev                  Enable developer mode           [boolean] [default: false]
     --ecdsa-private-key    Specify a hex-encoded ECDSA     [string]                  
                            private key for the Hedera                                
                            account                                                   
     --ed25519-private-key  Specify a hex-encoded ED25519   [string]                  
                            private key for the Hedera                                
                            account                                                   
     --force-port-forward   Force port forward to access    [boolean] [default: true] 
                            the network services                                      
     --generate-ecdsa-key   Generate ECDSA private key for  [boolean] [default: false]
                            the Hedera account                                        
     --hbar-amount          Amount of HBAR to add           [number] [default: 100]   
     --private-key          Show private key information    [boolean] [default: false]
     --set-alias            Sets the alias for the Hedera   [boolean] [default: false]
                            account when it is created,                               
                            requires  --ecdsa-private-key                             
-v,  --version              Show version number             [boolean]

ledger account info

 ledger account info

Gets the account info including the current amount of HBAR

Options:

     --account-id          The Hedera account id, e.g.:    [string] [required]       
                           0.0.1001                                                  
-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --private-key         Show private key information    [boolean] [default: false]
-v,  --version             Show version number             [boolean]

ledger account predefined

 ledger account predefined

Creates predefined accounts used by one-shot deployments.

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-c,  --cluster-ref         The cluster reference that      [string]                                      
                           will be used for referencing                                                  
                           the Kubernetes cluster and                                                    
                           stored in the local and remote                                                
                           configuration for the                                                         
                           deployment.  For commands that                                                
                           take multiple clusters they                                                   
                           can be separated by commas.                                                   
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-v,  --version             Show version number             [boolean]

ledger file

 ledger file

Upload or update files on the Hiero network.

Commands:
  ledger file create   Create a new file on the Hiero network
  ledger file update   Update an existing file on the Hiero network

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

ledger file create

 ledger file create

Create a new file on the Hiero network

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
     --file-path           Local path to the file to       [string] [required]       
                           upload                                                    
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

ledger file update

 ledger file update

Update an existing file on the Hiero network

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
     --file-id             The network file id, e.g.:      [string] [required]       
                           0.0.150                                                   
     --file-path           Local path to the file to       [string] [required]       
                           upload                                                    
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

mirror

 mirror

Mirror Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.

Commands:
  mirror node   List, create, manage, or destroy mirror node instances. Operates on a single mirror node instance at a time.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

mirror node

 mirror node

List, create, manage, or destroy mirror node instances. Operates on a single mirror node instance at a time.

Commands:
  mirror node add       Adds and configures a new node instance.
  mirror node destroy   Deletes the specified node from the deployment.
  mirror node upgrade   Upgrades the specified node from the deployment.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

mirror node add

 mirror node add

Adds and configures a new node instance.

Options:

-d,  --deployment                        The name the user will          [string] [required]                           
                                         reference locally to link to a                                                
                                         deployment                                                                    
                                                                                                                       
     --cache-dir                         Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir                         Local chart directory path      [string]                                      
                                         (e.g. ~/solo-charts/charts)                                                   
-c,  --cluster-ref                       The cluster reference that      [string]                                      
                                         will be used for referencing                                                  
                                         the Kubernetes cluster and                                                    
                                         stored in the local and remote                                                
                                         configuration for the                                                         
                                         deployment.  For commands that                                                
                                         take multiple clusters they                                                   
                                         can be separated by commas.                                                   
     --component-image                   ,  --relay-image     Docker     [string]                                      
                                         image override. Accepts a                                                     
                                         registry reference (e.g.                                                      
                                         ghcr.io/hiero-ledger/block-node-server:0.36.0) or a local reference (e.g. block-node-server:0.36.0-SNAPSHOT). Local images found in Docker are automatically loaded into the Kind cluster.                                                
     --dev                               Enable developer mode           [boolean] [default: false]                    
     --domain-name                       Custom domain name              [string]                                      
     --enable-ingress                    enable ingress on the           [boolean] [default: false]                    
                                         component/pod                                                                 
     --external-address                  Bind address for kubectl        [string]                                      
                                         port-forward (for example                                                     
                                         127.0.0.1 or 0.0.0.0)                                                         
     --external-database-host            Use to provide the external     [string]                                      
                                         database host if the '                                                        
                                         --use-external-database ' is                                                  
                                         passed                                                                        
     --external-database-owner-password  Use to provide the external     [string]                                      
                                         database owner's password if                                                  
                                         the ' --use-external-database                                                 
                                         ' is passed                                                                   
     --external-database-owner-username  Use to provide the external     [string]                                      
                                         database owner's username if                                                  
                                         the ' --use-external-database                                                 
                                         ' is passed                                                                   
     --external-database-read-password   Use to provide the external     [string]                                      
                                         database readonly user's                                                      
                                         password if the '                                                             
                                         --use-external-database ' is                                                  
                                         passed                                                                        
     --external-database-read-username   Use to provide the external     [string]                                      
                                         database readonly user's                                                      
                                         username if the '                                                             
                                         --use-external-database ' is                                                  
                                         passed                                                                        
     --force                             Force enable block node         [boolean] [default: false]                    
                                         integration bypassing the                                                     
                                         version requirements CN >=                                                    
                                         v0.72.0, BN >= 0.29.0, CN >=                                                  
                                         0.150.0                                                                       
     --force-port-forward                Force port forward to access    [boolean] [default: true]                     
                                         the network services                                                          
     --ingress-controller-value-file     The value file to use for       [string]                                      
                                         ingress controller, defaults                                                  
                                         to ""                                                                         
     --mirror-node-chart-dir             Mirror node local chart         [string]                                      
                                         directory path (e.g.                                                          
                                         ~/hiero-mirror-node/charts).                                                  
                                         NOTE: This only provides the                                                  
                                         Helm chart templates — it does                                                
                                         NOT make the chart images                                                     
                                         available to the cluster. All                                                 
                                         container images referenced by                                                
                                         the chart must already be                                                     
                                         pullable (e.g. published to a                                                 
                                         registry or loaded into the                                                   
                                         cluster with `kind load                                                       
                                         docker-image`). Using a local                                                 
                                         branch chart with SNAPSHOT                                                    
                                         image tags will cause pods to                                                 
                                         fail with ImagePullBackOff                                                    
                                         unless those images have been                                                 
                                         built and pushed to a registry                                                
                                         or loaded into the cluster.                                                   
     --mirror-node-version               Mirror node chart version       [string] [default: "v0.157.0"]                
     --mirror-static-ip                  static IP address for the       [string]                                      
                                         mirror node                                                                   
     --operator-id                       Operator ID                     [string]                                      
     --operator-key                      Operator Key                    [string]                                      
     --parallel-deploy                   Run independent one-shot        [boolean] [default: true]                     
                                         deploy stages in parallel                                                     
                                         (consensus+block,                                                             
                                         mirror+accounts,                                                              
                                         explorer+relay). Disable with                                                 
                                         --no-parallel-deploy  for                                                     
                                         sequential execution (useful                                                  
                                         for debugging or                                                              
                                         resource-constrained                                                          
                                         environments).                                                                
     --pinger                            Enable Pinger service in the    [boolean] [default: false]                    
                                         Mirror node monitor                                                           
-q,  --quiet-mode                        Quiet mode, do not prompt for   [boolean] [default: false]                    
                                         confirmation                                                                  
     --solo-chart-version                Solo testing chart version      [string] [default: "0.64.0"]                  
     --storage-bucket                    name of storage bucket for      [string]                                      
                                         mirror node importer                                                          
     --storage-bucket-prefix             path prefix of storage bucket   [string]                                      
                                         mirror node importer                                                          
     --storage-bucket-region             region of storage bucket        [string]                                      
                                         mirror node importer                                                          
     --storage-endpoint                  storage endpoint URL for        [string]                                      
                                         mirror node importer                                                          
     --storage-read-access-key           storage read access key for     [string]                                      
                                         mirror node importer                                                          
     --storage-read-secrets              storage read-secret key for     [string]                                      
                                         mirror node importer                                                          
     --storage-type                      storage type for saving stream  [default: "minio_only"]                       
                                         files, available options are                                                  
                                         minio_only, aws_only,                                                         
                                         gcs_only, aws_and_gcs                                                         
     --use-external-database             Set to true if you have an      [boolean] [default: false]                    
                                         external database to use                                                      
                                         instead of the database that                                                  
                                         the Mirror Node Helm chart                                                    
                                         supplies                                                                      
-f,  --values-file                       Comma separated chart values    [string]                                      
                                         file                                                                          
-v,  --version                           Show version number             [boolean]

mirror node destroy

 mirror node destroy

Deletes the specified node from the deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --chart-dir           Local chart directory path      [string]                  
                           (e.g. ~/solo-charts/charts)                               
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force               Force actions even if those     [boolean] [default: false]
                           can be skipped                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --id                  The numeric identifier for the  [number]                  
                           component                                                 
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

mirror node upgrade

 mirror node upgrade

Upgrades the specified node from the deployment.

Options:

-d,  --deployment                        The name the user will          [string] [required]                           
                                         reference locally to link to a                                                
                                         deployment                                                                    
                                                                                                                       
     --cache-dir                         Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --chart-dir                         Local chart directory path      [string]                                      
                                         (e.g. ~/solo-charts/charts)                                                   
-c,  --cluster-ref                       The cluster reference that      [string]                                      
                                         will be used for referencing                                                  
                                         the Kubernetes cluster and                                                    
                                         stored in the local and remote                                                
                                         configuration for the                                                         
                                         deployment.  For commands that                                                
                                         take multiple clusters they                                                   
                                         can be separated by commas.                                                   
     --component-image                   ,  --relay-image     Docker     [string]                                      
                                         image override. Accepts a                                                     
                                         registry reference (e.g.                                                      
                                         ghcr.io/hiero-ledger/block-node-server:0.36.0) or a local reference (e.g. block-node-server:0.36.0-SNAPSHOT). Local images found in Docker are automatically loaded into the Kind cluster.                                                
     --dev                               Enable developer mode           [boolean] [default: false]                    
     --domain-name                       Custom domain name              [string]                                      
     --enable-ingress                    enable ingress on the           [boolean] [default: false]                    
                                         component/pod                                                                 
     --external-address                  Bind address for kubectl        [string]                                      
                                         port-forward (for example                                                     
                                         127.0.0.1 or 0.0.0.0)                                                         
     --external-database-host            Use to provide the external     [string]                                      
                                         database host if the '                                                        
                                         --use-external-database ' is                                                  
                                         passed                                                                        
     --external-database-owner-password  Use to provide the external     [string]                                      
                                         database owner's password if                                                  
                                         the ' --use-external-database                                                 
                                         ' is passed                                                                   
     --external-database-owner-username  Use to provide the external     [string]                                      
                                         database owner's username if                                                  
                                         the ' --use-external-database                                                 
                                         ' is passed                                                                   
     --external-database-read-password   Use to provide the external     [string]                                      
                                         database readonly user's                                                      
                                         password if the '                                                             
                                         --use-external-database ' is                                                  
                                         passed                                                                        
     --external-database-read-username   Use to provide the external     [string]                                      
                                         database readonly user's                                                      
                                         username if the '                                                             
                                         --use-external-database ' is                                                  
                                         passed                                                                        
     --force                             Force enable block node         [boolean] [default: false]                    
                                         integration bypassing the                                                     
                                         version requirements CN >=                                                    
                                         v0.72.0, BN >= 0.29.0, CN >=                                                  
                                         0.150.0                                                                       
     --force-port-forward                Force port forward to access    [boolean] [default: true]                     
                                         the network services                                                          
     --id                                The numeric identifier for the  [number]                                      
                                         component                                                                     
     --ingress-controller-value-file     The value file to use for       [string]                                      
                                         ingress controller, defaults                                                  
                                         to ""                                                                         
     --mirror-node-chart-dir             Mirror node local chart         [string]                                      
                                         directory path (e.g.                                                          
                                         ~/hiero-mirror-node/charts).                                                  
                                         NOTE: This only provides the                                                  
                                         Helm chart templates — it does                                                
                                         NOT make the chart images                                                     
                                         available to the cluster. All                                                 
                                         container images referenced by                                                
                                         the chart must already be                                                     
                                         pullable (e.g. published to a                                                 
                                         registry or loaded into the                                                   
                                         cluster with `kind load                                                       
                                         docker-image`). Using a local                                                 
                                         branch chart with SNAPSHOT                                                    
                                         image tags will cause pods to                                                 
                                         fail with ImagePullBackOff                                                    
                                         unless those images have been                                                 
                                         built and pushed to a registry                                                
                                         or loaded into the cluster.                                                   
     --mirror-node-version               Mirror node chart version       [string] [default: "v0.157.0"]                
     --mirror-static-ip                  static IP address for the       [string]                                      
                                         mirror node                                                                   
     --operator-id                       Operator ID                     [string]                                      
     --operator-key                      Operator Key                    [string]                                      
     --pinger                            Enable Pinger service in the    [boolean] [default: false]                    
                                         Mirror node monitor                                                           
-q,  --quiet-mode                        Quiet mode, do not prompt for   [boolean] [default: false]                    
                                         confirmation                                                                  
     --solo-chart-version                Solo testing chart version      [string] [default: "0.64.0"]                  
     --storage-bucket                    name of storage bucket for      [string]                                      
                                         mirror node importer                                                          
     --storage-bucket-prefix             path prefix of storage bucket   [string]                                      
                                         mirror node importer                                                          
     --storage-bucket-region             region of storage bucket        [string]                                      
                                         mirror node importer                                                          
     --storage-endpoint                  storage endpoint URL for        [string]                                      
                                         mirror node importer                                                          
     --storage-read-access-key           storage read access key for     [string]                                      
                                         mirror node importer                                                          
     --storage-read-secrets              storage read-secret key for     [string]                                      
                                         mirror node importer                                                          
     --storage-type                      storage type for saving stream  [default: "minio_only"]                       
                                         files, available options are                                                  
                                         minio_only, aws_only,                                                         
                                         gcs_only, aws_and_gcs                                                         
     --use-external-database             Set to true if you have an      [boolean] [default: false]                    
                                         external database to use                                                      
                                         instead of the database that                                                  
                                         the Mirror Node Helm chart                                                    
                                         supplies                                                                      
-f,  --values-file                       Comma separated chart values    [string]                                      
                                         file                                                                          
-v,  --version                           Show version number             [boolean]

relay

 relay

RPC Relay Node operations for creating, modifying, and destroying resources. These commands require the presence of an existing deployment.

Commands:
  relay node   List, create, manage, or destroy relay node instances. Operates on a single relay node instance at a time.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

relay node

 relay node

List, create, manage, or destroy relay node instances. Operates on a single relay node instance at a time.

Commands:
  relay node add       Adds and configures a new node instance.
  relay node destroy   Deletes the specified node from the deployment.
  relay node upgrade   Upgrades the specified node from the deployment.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

relay node add

 relay node add

Adds and configures a new node instance.

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-l,  --chain-id            Chain ID                        [string] [default: "298"]                     
     --chart-dir           Local chart directory path      [string]                                      
                           (e.g. ~/solo-charts/charts)                                                   
-c,  --cluster-ref         The cluster reference that      [string]                                      
                           will be used for referencing                                                  
                           the Kubernetes cluster and                                                    
                           stored in the local and remote                                                
                           configuration for the                                                         
                           deployment.  For commands that                                                
                           take multiple clusters they                                                   
                           can be separated by commas.                                                   
     --component-image     ,  --relay-image   Docker       [string]                                      
                           image override. Accepts a                                                     
                           registry reference (e.g.                                                      
                           ghcr.io/hiero-ledger/block-node-server:0.36.0) or a local reference (e.g. block-node-server:0.36.0-SNAPSHOT). Local images found in Docker are automatically loaded into the Kind cluster.                                                
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --domain-name         Custom domain name              [string]                                      
     --external-address    Bind address for kubectl        [string]                                      
                           port-forward (for example                                                     
                           127.0.0.1 or 0.0.0.0)                                                         
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
     --mirror-namespace    Namespace to use for the        [string]                                      
                           Mirror Node deployment, a new                                                 
                           one will be created if it does                                                
                           not exist                                                                     
     --mirror-node-id      The id of the mirror node       [number]                                      
                           which to connect                                                              
-i,  --node-aliases        Comma separated node aliases    [string]                                      
                           (empty means all nodes)                                                       
     --operator-id         Operator ID                     [string]                                      
     --operator-key        Operator Key                    [string]                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --relay-chart-dir     Relay local chart directory     [string]                                      
                           path (e.g.                                                                    
                           ~/hiero-json-rpc-relay/charts)                                                
     --relay-release       DEPRECATED: use                 [string] [default: "0.77.0"]                  
                           --relay-version  (e.g.                                                        
                           v0.48.0)                                                                      
     --relay-version       JSON-RPC relay version to       [string]                                      
                           deploy (e.g. v0.76.2 or                                                       
                           0.76.2).                                                                      
     --replica-count       Replica count                   [number] [default: 1]                         
-f,  --values-file         Comma separated chart values    [string]                                      
                           file                                                                          
-v,  --version             Show version number             [boolean]

relay node destroy

 relay node destroy

Deletes the specified node from the deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --chart-dir           Local chart directory path      [string]                  
                           (e.g. ~/solo-charts/charts)                               
-c,  --cluster-ref         The cluster reference that      [string]                  
                           will be used for referencing                              
                           the Kubernetes cluster and                                
                           stored in the local and remote                            
                           configuration for the                                     
                           deployment.  For commands that                            
                           take multiple clusters they                               
                           can be separated by commas.                               
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
     --id                  The numeric identifier for the  [number]                  
                           component                                                 
-i,  --node-aliases        Comma separated node aliases    [string]                  
                           (empty means all nodes)                                   
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

relay node upgrade

 relay node upgrade

Upgrades the specified node from the deployment.

Options:

-d,  --deployment          The name the user will          [string] [required]                           
                           reference locally to link to a                                                
                           deployment                                                                    
                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-l,  --chain-id            Chain ID                        [string] [default: "298"]                     
     --chart-dir           Local chart directory path      [string]                                      
                           (e.g. ~/solo-charts/charts)                                                   
-c,  --cluster-ref         The cluster reference that      [string]                                      
                           will be used for referencing                                                  
                           the Kubernetes cluster and                                                    
                           stored in the local and remote                                                
                           configuration for the                                                         
                           deployment.  For commands that                                                
                           take multiple clusters they                                                   
                           can be separated by commas.                                                   
     --component-image     ,  --relay-image   Docker       [string]                                      
                           image override. Accepts a                                                     
                           registry reference (e.g.                                                      
                           ghcr.io/hiero-ledger/block-node-server:0.36.0) or a local reference (e.g. block-node-server:0.36.0-SNAPSHOT). Local images found in Docker are automatically loaded into the Kind cluster.                                                
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --domain-name         Custom domain name              [string]                                      
     --external-address    Bind address for kubectl        [string]                                      
                           port-forward (for example                                                     
                           127.0.0.1 or 0.0.0.0)                                                         
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
     --id                  The numeric identifier for the  [number]                                      
                           component                                                                     
     --mirror-namespace    Namespace to use for the        [string]                                      
                           Mirror Node deployment, a new                                                 
                           one will be created if it does                                                
                           not exist                                                                     
     --mirror-node-id      The id of the mirror node       [number]                                      
                           which to connect                                                              
-i,  --node-aliases        Comma separated node aliases    [string]                                      
                           (empty means all nodes)                                                       
     --operator-id         Operator ID                     [string]                                      
     --operator-key        Operator Key                    [string]                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
     --relay-chart-dir     Relay local chart directory     [string]                                      
                           path (e.g.                                                                    
                           ~/hiero-json-rpc-relay/charts)                                                
     --relay-release       DEPRECATED: use                 [string] [default: "0.77.0"]                  
                           --relay-version  (e.g.                                                        
                           v0.48.0)                                                                      
     --relay-version       JSON-RPC relay version to       [string]                                      
                           deploy (e.g. v0.76.2 or                                                       
                           0.76.2).                                                                      
     --replica-count       Replica count                   [number] [default: 1]                         
-f,  --values-file         Comma separated chart values    [string]                                      
                           file                                                                          
-v,  --version             Show version number             [boolean]

cache

 cache

Manage solo cached items.

Commands:
  cache image   Manage image archives used by solo.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

cache image

 cache image

Manage image archives used by solo.

Commands:
  cache image pull     Pull and caches docker images used by solo, prerequisite for `solo cache image load`.
  cache image load     Loads the images archive into a cluster. Pulling the images with `solo cache images pull` is a prerequisite.
  cache image list     Lists all cached image archives.
  cache image clear    Clears the image archives.
  cache image prune    Prune the image archives.
  cache image status   Lists all images, displays data about them and all missing images.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

cache image pull

 cache image pull

Pull and caches docker images used by solo, prerequisite for `solo cache image load`.

Options:

                                                                                                          
     --block-node-version   Block node version to deploy    [string]                                      
                            for (e.g. v0.31.0 or 0.31.0).                                                 
     --cache-dir            Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                  Enable developer mode           [boolean] [default: false]                    
     --edge                 Use edge component versions     [boolean] [default: false]                    
                            (newer than defaults). Also                                                   
                            supports version overrides                                                    
                            from solo.config.yaml and                                                     
                            solo.config.json, for example:                                                
                            `consensus-node-version:                                                      
                            v0.73.0` (YAML) or                                                            
                            `{"consensusNodeVersion":"v0.73.0"}` (JSON).                                                
     --explorer-version     Explorer chart version          [string] [default: "26.1.0"]                  
     --force-port-forward   Force port forward to access    [boolean] [default: true]                     
                            the network services                                                          
     --mirror-node-version  Mirror node chart version       [string] [default: "v0.157.0"]                
-q,  --quiet-mode           Quiet mode, do not prompt for   [boolean] [default: false]                    
                            confirmation                                                                  
     --relay-version        JSON-RPC relay version to       [string]                                      
                            deploy (e.g. v0.76.2 or                                                       
                            0.76.2).                                                                      
-v,  --version              Show version number             [boolean]

cache image load

 cache image load

Loads the images archive into a cluster. Pulling the images with `solo cache images pull` is a prerequisite.

Options:

                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-c,  --cluster-ref         The cluster reference that      [string]                                      
                           will be used for referencing                                                  
                           the Kubernetes cluster and                                                    
                           stored in the local and remote                                                
                           configuration for the                                                         
                           deployment.  For commands that                                                
                           take multiple clusters they                                                   
                           can be separated by commas.                                                   
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-v,  --version             Show version number             [boolean]

cache image list

 cache image list

Lists all cached image archives.

Options:

                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-v,  --version             Show version number             [boolean]

cache image clear

 cache image clear

Clears the image archives.

Options:

                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-v,  --version             Show version number             [boolean]

cache image prune

 cache image prune

Prune the image archives.

Options:

                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-v,  --version             Show version number             [boolean]

cache image status

 cache image status

Lists all images, displays data about them and all missing images.

Options:

                                                                                                         
     --cache-dir           Local cache directory           [string] [default: "/home/runner/.solo/cache"]
-c,  --cluster-ref         The cluster reference that      [string]                                      
                           will be used for referencing                                                  
                           the Kubernetes cluster and                                                    
                           stored in the local and remote                                                
                           configuration for the                                                         
                           deployment.  For commands that                                                
                           take multiple clusters they                                                   
                           can be separated by commas.                                                   
     --dev                 Enable developer mode           [boolean] [default: false]                    
     --force-port-forward  Force port forward to access    [boolean] [default: true]                     
                           the network services                                                          
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                    
                           confirmation                                                                  
-v,  --version             Show version number             [boolean]

one-shot

 one-shot

One Shot commands for new and returning users who need a preset environment type. These commands use reasonable defaults to provide a single command out of box experience.

Commands:
  one-shot single   Creates a uniquely named deployment with a single consensus node, mirror node, block node, relay node, and explorer node.
  one-shot multi    Creates a uniquely named deployment with multiple consensus nodes, mirror node, block node, relay node, and explorer node.
  one-shot falcon   Creates a uniquely named deployment with optional chart values override using --values-file.
  one-shot show     Display information about one-shot deployments.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

one-shot single

 one-shot single

Creates a uniquely named deployment with a single consensus node, mirror node, block node, relay node, and explorer node.

Commands:
  one-shot single deploy    Deploys all required components for the selected one shot configuration.
  one-shot single destroy   Removes the deployed resources for the selected one shot configuration.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

one-shot single deploy

 one-shot single deploy

Deploys all required components for the selected one shot configuration.

Options:

                                                                                             
     --block-node-version      Block node version to deploy    [string]                      
                               for (e.g. v0.31.0 or 0.31.0).                                 
     --chart-version           DEPRECATED: use                 [string] [default: "0.36.0"]  
                               --block-node-version                                          
-c,  --cluster-ref             The cluster reference that      [string]                      
                               will be used for referencing                                  
                               the Kubernetes cluster and                                    
                               stored in the local and remote                                
                               configuration for the                                         
                               deployment.  For commands that                                
                               take multiple clusters they                                   
                               can be separated by commas.                                   
     --consensus-node-version  Consensus node version to       [string]                      
                               deploy (e.g. v0.73.0 or                                       
                               0.73.0).                                                      
-d,  --deployment              The name the user will          [string]                      
                               reference locally to link to a                                
                               deployment                                                    
     --dev                     Enable developer mode           [boolean] [default: false]    
     --edge                    Use edge component versions     [boolean] [default: false]    
                               (newer than defaults). Also                                   
                               supports version overrides                                    
                               from solo.config.yaml and                                     
                               solo.config.json, for example:                                
                               `consensus-node-version:                                      
                               v0.73.0` (YAML) or                                            
                               `{"consensusNodeVersion":"v0.73.0"}` (JSON).                                
     --explorer-version        Explorer chart version          [string] [default: "26.1.0"]  
     --external-address        Bind address for kubectl        [string]                      
                               port-forward (for example                                     
                               127.0.0.1 or 0.0.0.0)                                         
     --force                   Force actions even if those     [boolean] [default: false]    
                               can be skipped                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]     
                               the network services                                          
     --metrics-server          Deploy metrics server to        [boolean] [default: false]    
                               enable kubectl top for CPU and                                
                               memory usage monitoring                                       
     --minimal-setup           Create a deployment with        [boolean] [default: false]    
                               minimal setup. Only includes a                                
                               single consensus node and                                     
                               mirror node                                                   
     --mirror-node-version     Mirror node chart version       [string] [default: "v0.157.0"]
-n,  --namespace               Namespace                       [string]                      
     --parallel-deploy         Run independent one-shot        [boolean] [default: true]     
                               deploy stages in parallel                                     
                               (consensus+block,                                             
                               mirror+accounts,                                              
                               explorer+relay). Disable with                                 
                               --no-parallel-deploy  for                                     
                               sequential execution (useful                                  
                               for debugging or                                              
                               resource-constrained                                          
                               environments).                                                
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]    
                               confirmation                                                  
     --relay-release           DEPRECATED: use                 [string] [default: "0.77.0"]  
                               --relay-version  (e.g.                                        
                               v0.48.0)                                                      
     --relay-version           JSON-RPC relay version to       [string]                      
                               deploy (e.g. v0.76.2 or                                       
                               0.76.2).                                                      
     --rollback                Opt in to automatic cleanup     [boolean] [default: false]    
                               when deploy fails. By default,                                
                               failed one-shot deploys keep                                  
                               partial resources so you can                                  
                               inspect the failure and re-run                                
                               the same command.                                             
-v,  --version                 Show version number             [boolean]

one-shot single destroy

 one-shot single destroy

Removes the deployed resources for the selected one shot configuration.

Options:

                                                                                     
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

one-shot multi

 one-shot multi

Creates a uniquely named deployment with multiple consensus nodes, mirror node, block node, relay node, and explorer node.

Commands:
  one-shot multi deploy    Deploys all required components for the selected multiple node one shot configuration.
  one-shot multi destroy   Removes the deployed resources for the selected multiple node one shot configuration.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

one-shot multi deploy

 one-shot multi deploy

Deploys all required components for the selected multiple node one shot configuration.

Options:

                                                                                             
     --block-node-version      Block node version to deploy    [string]                      
                               for (e.g. v0.31.0 or 0.31.0).                                 
     --chart-version           DEPRECATED: use                 [string] [default: "0.36.0"]  
                               --block-node-version                                          
-c,  --cluster-ref             The cluster reference that      [string]                      
                               will be used for referencing                                  
                               the Kubernetes cluster and                                    
                               stored in the local and remote                                
                               configuration for the                                         
                               deployment.  For commands that                                
                               take multiple clusters they                                   
                               can be separated by commas.                                   
     --consensus-node-version  Consensus node version to       [string]                      
                               deploy (e.g. v0.73.0 or                                       
                               0.73.0).                                                      
-d,  --deployment              The name the user will          [string]                      
                               reference locally to link to a                                
                               deployment                                                    
     --dev                     Enable developer mode           [boolean] [default: false]    
     --edge                    Use edge component versions     [boolean] [default: false]    
                               (newer than defaults). Also                                   
                               supports version overrides                                    
                               from solo.config.yaml and                                     
                               solo.config.json, for example:                                
                               `consensus-node-version:                                      
                               v0.73.0` (YAML) or                                            
                               `{"consensusNodeVersion":"v0.73.0"}` (JSON).                                
     --explorer-version        Explorer chart version          [string] [default: "26.1.0"]  
     --external-address        Bind address for kubectl        [string]                      
                               port-forward (for example                                     
                               127.0.0.1 or 0.0.0.0)                                         
     --force                   Force actions even if those     [boolean] [default: false]    
                               can be skipped                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]     
                               the network services                                          
     --metrics-server          Deploy metrics server to        [boolean] [default: false]    
                               enable kubectl top for CPU and                                
                               memory usage monitoring                                       
     --minimal-setup           Create a deployment with        [boolean] [default: false]    
                               minimal setup. Only includes a                                
                               single consensus node and                                     
                               mirror node                                                   
     --mirror-node-version     Mirror node chart version       [string] [default: "v0.157.0"]
-n,  --namespace               Namespace                       [string]                      
     --num-consensus-nodes     Used to specify desired number  [number]                      
                               of consensus nodes for                                        
                               pre-genesis deployments                                       
     --parallel-deploy         Run independent one-shot        [boolean] [default: true]     
                               deploy stages in parallel                                     
                               (consensus+block,                                             
                               mirror+accounts,                                              
                               explorer+relay). Disable with                                 
                               --no-parallel-deploy  for                                     
                               sequential execution (useful                                  
                               for debugging or                                              
                               resource-constrained                                          
                               environments).                                                
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]    
                               confirmation                                                  
     --relay-release           DEPRECATED: use                 [string] [default: "0.77.0"]  
                               --relay-version  (e.g.                                        
                               v0.48.0)                                                      
     --relay-version           JSON-RPC relay version to       [string]                      
                               deploy (e.g. v0.76.2 or                                       
                               0.76.2).                                                      
     --rollback                Opt in to automatic cleanup     [boolean] [default: false]    
                               when deploy fails. By default,                                
                               failed one-shot deploys keep                                  
                               partial resources so you can                                  
                               inspect the failure and re-run                                
                               the same command.                                             
-v,  --version                 Show version number             [boolean]

one-shot multi destroy

 one-shot multi destroy

Removes the deployed resources for the selected multiple node one shot configuration.

Options:

                                                                                     
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

one-shot falcon

 one-shot falcon

Creates a uniquely named deployment with optional chart values override using --values-file.

Commands:
  one-shot falcon deploy    Deploys all required components for the selected one shot configuration (with optional values file).
  one-shot falcon destroy   Removes the deployed resources for the selected one shot configuration (with optional values file).
  one-shot falcon prepare   Generates a falcon values file for use with one-shot falcon deploy. Writes to /home/runner/.solo/cache/falcon-values.yaml by default.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

one-shot falcon deploy

 one-shot falcon deploy

Deploys all required components for the selected one shot configuration (with optional values file).

Options:

                                                                                             
     --block-node-version      Block node version to deploy    [string]                      
                               for (e.g. v0.31.0 or 0.31.0).                                 
     --chart-version           DEPRECATED: use                 [string] [default: "0.36.0"]  
                               --block-node-version                                          
-c,  --cluster-ref             The cluster reference that      [string]                      
                               will be used for referencing                                  
                               the Kubernetes cluster and                                    
                               stored in the local and remote                                
                               configuration for the                                         
                               deployment.  For commands that                                
                               take multiple clusters they                                   
                               can be separated by commas.                                   
     --consensus-node-version  Consensus node version to       [string]                      
                               deploy (e.g. v0.73.0 or                                       
                               0.73.0).                                                      
     --deploy-explorer         Deploy explorer as part of      [boolean] [default: true]     
                               one-shot falcon deployment                                    
     --deploy-mirror-node      Deploy mirror node as part of   [boolean] [default: true]     
                               one-shot falcon deployment                                    
     --deploy-relay            Deploy relay as part of         [boolean] [default: true]     
                               one-shot falcon deployment                                    
-d,  --deployment              The name the user will          [string]                      
                               reference locally to link to a                                
                               deployment                                                    
     --dev                     Enable developer mode           [boolean] [default: false]    
     --edge                    Use edge component versions     [boolean] [default: false]    
                               (newer than defaults). Also                                   
                               supports version overrides                                    
                               from solo.config.yaml and                                     
                               solo.config.json, for example:                                
                               `consensus-node-version:                                      
                               v0.73.0` (YAML) or                                            
                               `{"consensusNodeVersion":"v0.73.0"}` (JSON).                                
     --explorer-version        Explorer chart version          [string] [default: "26.1.0"]  
     --external-address        Bind address for kubectl        [string]                      
                               port-forward (for example                                     
                               127.0.0.1 or 0.0.0.0)                                         
     --force                   Force actions even if those     [boolean] [default: false]    
                               can be skipped                                                
     --force-port-forward      Force port forward to access    [boolean] [default: true]     
                               the network services                                          
     --metrics-server          Deploy metrics server to        [boolean] [default: false]    
                               enable kubectl top for CPU and                                
                               memory usage monitoring                                       
     --mirror-node-version     Mirror node chart version       [string] [default: "v0.157.0"]
-n,  --namespace               Namespace                       [string]                      
     --num-consensus-nodes     Used to specify desired number  [number]                      
                               of consensus nodes for                                        
                               pre-genesis deployments                                       
     --parallel-deploy         Run independent one-shot        [boolean] [default: true]     
                               deploy stages in parallel                                     
                               (consensus+block,                                             
                               mirror+accounts,                                              
                               explorer+relay). Disable with                                 
                               --no-parallel-deploy  for                                     
                               sequential execution (useful                                  
                               for debugging or                                              
                               resource-constrained                                          
                               environments).                                                
-q,  --quiet-mode              Quiet mode, do not prompt for   [boolean] [default: false]    
                               confirmation                                                  
     --relay-release           DEPRECATED: use                 [string] [default: "0.77.0"]  
                               --relay-version  (e.g.                                        
                               v0.48.0)                                                      
     --relay-version           JSON-RPC relay version to       [string]                      
                               deploy (e.g. v0.76.2 or                                       
                               0.76.2).                                                      
     --rollback                Opt in to automatic cleanup     [boolean] [default: false]    
                               when deploy fails. By default,                                
                               failed one-shot deploys keep                                  
                               partial resources so you can                                  
                               inspect the failure and re-run                                
                               the same command.                                             
-f,  --values-file             Comma separated chart values    [string]                      
                               file                                                          
-v,  --version                 Show version number             [boolean]

one-shot falcon destroy

 one-shot falcon destroy

Removes the deployed resources for the selected one shot configuration (with optional values file).

Options:

                                                                                     
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

one-shot falcon prepare

 one-shot falcon prepare

Generates a falcon values file for use with one-shot falcon deploy. Writes to /home/runner/.solo/cache/falcon-values.yaml by default.

Options:

                                                                                                                             
     --chart-version        DEPRECATED: use                 [string] [default: "0.36.0"]                                     
                            --block-node-version                                                                             
     --debug-node-alias     Enable default jvm debug port   [string]                                                         
                            (5005) for the given node id                                                                     
     --dev                  Enable developer mode           [boolean] [default: false]                                       
     --explorer-version     Explorer chart version          [string] [default: "26.1.0"]                                     
     --force-port-forward   Force port forward to access    [boolean] [default: true]                                        
                            the network services                                                                             
     --load-balancer        Enable load balancer for        [boolean] [default: false]                                       
                            network node proxies                                                                             
     --local-build-path     path of hedera local repo       [string]                                                         
     --mirror-node-version  Mirror node chart version       [string] [default: "v0.157.0"]                                   
     --num-consensus-nodes  Used to specify desired number  [number]                                                         
                            of consensus nodes for                                                                           
                            pre-genesis deployments                                                                          
     --output-values-file   Output path for the generated   [string] [default: "/home/runner/.solo/cache/falcon-values.yaml"]
                            falcon values YAML file.                                                                         
                            Defaults to                                                                                      
                            ~/.solo/cache/falcon-values.yaml. Relative paths are resolved against the current working directory.                                                                   
-q,  --quiet-mode           Quiet mode, do not prompt for   [boolean] [default: false]                                       
                            confirmation                                                                                     
     --relay-release        DEPRECATED: use                 [string] [default: "0.77.0"]                                     
                            --relay-version  (e.g.                                                                           
                            v0.48.0)                                                                                         
-t,  --release-tag          DEPRECATED: use                 [string] [default: "v0.74.0"]                                    
                            --consensus-node-version                                                                         
                            (e.g. v0.74.0)                                                                                   
     --solo-chart-version   Solo testing chart version      [string] [default: "0.64.0"]                                     
-v,  --version              Show version number             [boolean]

one-shot show

 one-shot show

Display information about one-shot deployments.

Commands:
  one-shot show deployment   Display information about the last one-shot deployment including name, versions, and deployed components.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

one-shot show deployment

 one-shot show deployment

Display information about the last one-shot deployment including name, versions, and deployed components.

Options:

                                                                                     
-d,  --deployment          The name the user will          [string]                  
                           reference locally to link to a                            
                           deployment                                                
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

rapid-fire

 rapid-fire

Commands for performing load tests a Solo deployment

Commands:
  rapid-fire load      Run load tests using the network load generator with the selected class.
  rapid-fire destroy   Uninstall the Network Load Generator Helm chart and clean up resources.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

rapid-fire load

 rapid-fire load

Run load tests using the network load generator with the selected class.

Commands:
  rapid-fire load start   Start a rapid-fire load test using the selected class.
  rapid-fire load stop    Stop any running processes using the selected class.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

rapid-fire load start

 rapid-fire load start

Start a rapid-fire load test using the selected class.

Options:

     --args                All arguments to be passed to   [string] [required]                       
                           the NLG load test class. Value                                            
                           MUST be wrapped in 2 sets of                                              
                           different quotes. Example:                                                
                           '"-c 100 -a 40 -t 3600"'                                                  
-d,  --deployment          The name the user will          [string] [required]                       
                           reference locally to link to a                                            
                           deployment                                                                
     --test                The class name of the           [string] [required]                       
                           Performance Test to run                                                   
                                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]                
     --force               Force actions even if those     [boolean] [default: false]                
                           can be skipped                                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true]                 
                           the network services                                                      
     --javaHeap            Max Java heap size in GB for    [number] [default: 8]                     
                           the NLG load test class,                                                  
                           defaults to 8                                                             
     --max-tps             The maximum transactions per    [number] [default: 0]                     
                           second to be generated by the                                             
                           NLG load test                                                             
     --package             The package name of the         [string] [default: "com.hedera.benchmark"]
                           Performance Test to run.                                                  
                           Defaults to                                                               
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                
                           confirmation                                                              
-f,  --values-file         Comma separated chart values    [string]                                  
                           file                                                                      
-v,  --version             Show version number             [boolean]

rapid-fire load stop

 rapid-fire load stop

Stop any running processes using the selected class.

Options:

-d,  --deployment          The name the user will          [string] [required]                       
                           reference locally to link to a                                            
                           deployment                                                                
     --test                The class name of the           [string] [required]                       
                           Performance Test to run                                                   
                                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]                
     --force               Force actions even if those     [boolean] [default: false]                
                           can be skipped                                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true]                 
                           the network services                                                      
     --package             The package name of the         [string] [default: "com.hedera.benchmark"]
                           Performance Test to run.                                                  
                           Defaults to                                                               
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]                
                           confirmation                                                              
-v,  --version             Show version number             [boolean]

rapid-fire destroy

 rapid-fire destroy

Uninstall the Network Load Generator Helm chart and clean up resources.

Commands:
  rapid-fire destroy all   Uninstall the Network Load Generator Helm chart and remove all related resources.

Options:

                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-v,  --version             Show version number             [boolean]

rapid-fire destroy all

 rapid-fire destroy all

Uninstall the Network Load Generator Helm chart and remove all related resources.

Options:

-d,  --deployment          The name the user will          [string] [required]       
                           reference locally to link to a                            
                           deployment                                                
                                                                                     
     --dev                 Enable developer mode           [boolean] [default: false]
     --force               Force actions even if those     [boolean] [default: false]
                           can be skipped                                            
     --force-port-forward  Force port forward to access    [boolean] [default: true] 
                           the network services                                      
-q,  --quiet-mode          Quiet mode, do not prompt for   [boolean] [default: false]
                           confirmation                                              
-v,  --version             Show version number             [boolean]

2.9.2 - CLI Migration Reference

Legacy-to-current Solo CLI command mappings for users migrating from pre-v0.44 command paths.

Overview

Use this page when migrating scripts or runbooks from legacy Solo CLI command paths (< v0.44.0) to the current command structure.

For full current syntax and flags, see Solo CLI Reference.

Legacy to Current Mapping

Legacy commandCurrent command
initinit
block node addblock node add
block node destroyblock node destroy
block node upgradeblock node upgrade
account initledger system init
account updateledger account update
account createledger account create
account getledger account info
quick-start single deployone-shot single deploy
quick-start single destroyone-shot single destroy
cluster-ref connectcluster-ref config connect
cluster-ref disconnectcluster-ref config disconnect
cluster-ref listcluster-ref config list
cluster-ref infocluster-ref config info
cluster-ref setupcluster-ref config setup
cluster-ref resetcluster-ref config reset
deployment add-clusterdeployment cluster attach
deployment listdeployment config list
deployment createdeployment config create
deployment deletedeployment config delete
explorer deployexplorer node add
explorer destroyexplorer node destroy
mirror-node deploymirror node add
mirror-node destroymirror node destroy
relay deployrelay node add
relay destroyrelay node destroy
network deployconsensus network deploy
network destroyconsensus network destroy
node keyskeys consensus generate
node freezeconsensus network freeze
node upgradeconsensus network upgrade
node setupconsensus node setup
node startconsensus node start
node stopconsensus node stop
node restartconsensus node restart
node refreshconsensus node refresh
node addconsensus node add
node updateconsensus node update
node deleteconsensus node destroy
node add-prepareconsensus dev-node-add prepare
node add-submit-transactionconsensus dev-node-add submit-transactions
node add-executeconsensus dev-node-add execute
node update-prepareconsensus dev-node-update prepare
node update-submit-transactionconsensus dev-node-update submit-transactions
node update-executeconsensus dev-node-update execute
node upgrade-prepareconsensus dev-node-upgrade prepare
node upgrade-submit-transactionconsensus dev-node-upgrade submit-transactions
node upgrade-executeconsensus dev-node-upgrade execute
node delete-prepareconsensus dev-node-delete prepare
node delete-submit-transactionconsensus dev-node-delete submit-transactions
node delete-executeconsensus dev-node-delete execute
node prepare-upgradeconsensus dev-freeze prepare-upgrade
node freeze-upgradeconsensus dev-freeze freeze-upgrade
node logsdeployment diagnostics logs
node download-generated-filesNo direct equivalent. Use deployment diagnostics all or deployment diagnostics debug based on intent.
node statesconsensus state download

Notes

  • Current command tree includes additional commands not present in legacy CLI (for example ledger account predefined, rapid-fire load start, and consensus node collect-jfr).

2.10 - Solo Image Cache

Speed up deployments by pre-pulling and reusing the container images Solo needs. Manage the local image cache with the solo cache image commands, and control automatic caching during install and one-shot deployments.

Overview

A Solo network runs roughly 29 container images (consensus node, mirror node, JSON-RPC relay, Explorer, MinIO, and supporting services). The image cache pre-pulls those images and stores them as local .tar archives, so repeat deployments load them from disk instead of re-downloading them from their registries.

Solo populates and uses the cache automatically in two places:

  • At install time - Homebrew and npm installs pre-pull the default images.
  • During solo one-shot deploys - Solo pulls and loads the cached images as pipeline phases before the network is deployed.

You can also manage the cache directly with the solo cache image commands.

Prerequisites

  • Solo CLI v0.73.0 or later installed - the image cache was introduced in Solo v0.73.0; earlier versions have no solo cache image command. See Quickstart.

Where the cache lives

Cached image archives are stored under your Solo home directory, in ~/.solo/cache/images/ (one archive per image).

Managing the cache

All commands live under solo cache image.

Pull images

Download the default (stable) images and write them to the cache. This is a prerequisite for load.

solo cache image pull

Pass --edge to cache the edge (pre-release) component versions instead of the stable defaults:

solo cache image pull --edge

You can also pin individual components with the per-component version flags --mirror-node-version, --block-node-version, --relay-version, and --explorer-version.

Load images into a cluster

Load the cached archives into a cluster. This step needs a prior pull and a running cluster with a configured cluster reference (pull itself needs neither a running cluster nor a Docker daemon).

solo cache image load --cluster-ref <cluster-ref>

<cluster-ref> is a Solo cluster reference: an alias Solo maps to a Kubernetes context.

  • solo one-shot deployments create one named one-shot.
  • List the references you already have with solo cluster-ref config list.
  • Create a new one with solo cluster-ref config connect --cluster-ref <name> --context <kube-context>.

List cached archives

solo cache image list

Show cache status

Report which images are cached and which are missing. Pass --cluster-ref to also compare against the images already loaded in a cluster.

solo cache image status --cluster-ref <cluster-ref>

Clear or prune the cache

Remove cached image archives with clear, or with prune (Solo v0.78.0 and later):

solo cache image clear
solo cache image prune

Disabling the cache

The image cache is enabled by default. Each install/deploy path has its own opt-out:

ContextOpt-outNotes
solo one-shot deployENABLE_IMAGE_CACHE=falseRequires Solo v0.78.0 or later.
npm global installSOLO_NO_CACHE=trueSkips the post-install image pull.
Homebrew installHOMEBREW_NO_SOLO_CACHESet to any value (presence-based). Skips both the brew-level pull and the npm post-install pull.

Caching a specific component version

Solo resolves the component versions it caches from environment variables, not from CLI flags or solo.config.yaml. To cache a non-default version, set the version environment variable on the deploy command:

MIRROR_NODE_VERSION=v0.150.0 solo one-shot single deploy

Note: Passing the version with the --mirror-node-version CLI flag (or in solo.config.yaml) changes the deployed component but not the cached images - the cache still uses the default versions, which can cause a cache miss on first deploy. Use the environment variable to keep the cache aligned with the deployed versions.

Troubleshooting

  • [SOLO-4049] Cache has not been materialized yet — the load, list, status, clear, and prune commands require a populated cache. Run solo cache image pull first, then retry the command.
  • The cache is empty after installing Solo. The install-time pull is best-effort and can be skipped by a network hiccup. Populate it manually with solo cache image pull.
  • load cannot find the target cluster. Confirm the cluster reference with solo cluster-ref config list, then re-run load with the correct --cluster-ref.

3 - Using Solo

Explore practical applications and integrations for Solo. This section covers using Solo networks with the JavaScript SDK, integrating with external tools, building applications on Hiero consensus nodes, and deploying locally built consensus node binaries for development and testing.

3.1 - Accessing Solo Services

Learn how to locate and connect to ancillary services deployed alongside Solo networks, including Mirror Node Explorer, Block Nodes, and JSON-RPC Relay services.

3.1.1 - Using Solo with Mirror Node

Add Mirror Node to a Solo network to stream and query transaction records, account history, and token data via the Hiero Mirror Node REST API.

Overview

The Hiero Mirror Node stores the full transaction history of your local Solo network and exposes it through several interfaces:

  • A web-based block explorer (Hiero Mirror Node Explorer) at http://localhost:38080/localnet/dashboard (Solo 0.63+) or http://localhost:8080/localnet/dashboard (Solo 0.62 and earlier).
  • A REST API via the mirror-ingress service at http://localhost:38081 (Solo 0.63+) or http://localhost:8081 (Solo 0.62 and earlier) (recommended entry point — routes to the correct REST implementation).
  • A gRPC endpoint for mirror node subscriptions.

Important: The port numbers in this document are Solo’s default targets. If any port is already in use on your machine when Solo starts, Solo automatically selects the next available port. If an endpoint does not work, check the actual ports assigned to your deployment — see Port Reference below.

This guide walks you through adding Mirror Node and the Hiero Explorer to a Solo network, and shows you how to query transaction data and create accounts.

Prerequisites

Before proceeding, ensure you have completed the following:

  • System Readiness - your local environment meets all hardware and software requirements, including Docker and Solo.
  • Quickstart - you have a running Solo network deployed using solo one-shot single deploy.
  • To find your deployment name at any time, run solo one-shot show deployment (see Capture your deployment name).

Step 1: Deploy Solo with Mirror Node

Note: If you deployed your network using one-shot, Falcon, or the Task Tool, Mirror Node is already running - skip to Step 2: Access the Mirror Node Explorer.

Fresh manual Deployment

If you are building a custom network or adding the mirror node to an existing deployment, run the following commands in sequence.

On native Windows (PowerShell), set the environment variables with $env: instead of export (and reference them as $env:SOLO_CLUSTER_NAME, etc., in the commands that follow):

$env:SOLO_CLUSTER_NAME = 'solo-cluster'
$env:SOLO_NAMESPACE = 'solo-deployment'
$env:SOLO_CLUSTER_SETUP_NAMESPACE = 'solo-cluster-setup'
$env:SOLO_DEPLOYMENT = 'solo-deployment'

# Set environment variables
export SOLO_CLUSTER_NAME=solo-cluster
export SOLO_NAMESPACE=solo-deployment
export SOLO_CLUSTER_SETUP_NAMESPACE=solo-cluster-setup
export SOLO_DEPLOYMENT=solo-deployment

# Reset environment
rm -Rf ~/.solo
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"

# Configure cluster
solo cluster-ref config setup \
  --cluster-setup-namespace "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref config connect \
  --cluster-ref ${SOLO_CLUSTER_NAME} \
  --context kind-${SOLO_CLUSTER_NAME}

# Create deployment
solo deployment config create \
  --namespace "${SOLO_NAMESPACE}" \
  --deployment "${SOLO_DEPLOYMENT}"
solo deployment cluster attach \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref ${SOLO_CLUSTER_NAME} \
  --num-consensus-nodes 2

# Generate keys and deploy consensus nodes
solo keys consensus generate \
  --deployment "${SOLO_DEPLOYMENT}" \
  --gossip-keys --tls-keys \
  -i node1,node2
solo consensus network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2
solo consensus node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2
solo consensus node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2

# Add mirror node and explorer
solo mirror node add \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref ${SOLO_CLUSTER_NAME} \
  --enable-ingress \
  --pinger
solo explorer node add \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref ${SOLO_CLUSTER_NAME}

Note: The --pinger flag in solo mirror node add starts a background service that sends transactions to the network at regular intervals. This is required because mirror node record files are only imported when a new record file is created - without it, the mirror node will appear empty until the next transaction occurs naturally.

Step 2: Access the Mirror Node Explorer

Once Mirror Node is running, open the Hiero Explorer in your browser at:

http://localhost:38080/localnet/dashboard

Note: If you are using Solo 0.62 or earlier, the Explorer is at http://localhost:8080/localnet/dashboard. If that port does not work, check the actual port assigned to your deployment — see Port Reference.

The Explorer lets you browse accounts, transactions, tokens, and contracts on your Solo network in real time.

Step 3: Create Accounts and View Transactions

Create test accounts and observe them appearing in the Explorer:

solo ledger account create --deployment solo-deployment --hbar-amount 100
solo ledger account create --deployment solo-deployment --hbar-amount 100

Open the Explorer at http://localhost:38080/localnet/dashboard (Solo 0.63+) or http://localhost:8080/localnet/dashboard (Solo 0.62 and earlier) to see the new accounts and their transactions recorded by the Mirror Node. If the port does not work, check your actual port assignments — see Port Reference.

You can also use the Hiero JavaScript SDK to create a topic, submit a message, and subscribe to it.

Step 4: Access Mirror Node APIs

Option A: Mirror-Ingress (localhost:38081)

Use localhost:38081 (Solo 0.63+) for all Mirror Node REST API access. The mirror-ingress service routes requests to the correct REST implementation automatically. This is important because certain endpoints are only supported in the newer rest-java version.

# List recent transactions
curl -s "http://localhost:38081/api/v1/transactions?limit=5"

# Get account details
curl -s "http://localhost:38081/api/v1/accounts/0.0.2"

Note: If you are using Solo 0.62 or earlier, use localhost:8081 instead of localhost:38081. localhost:5551 (the legacy Mirror Node REST API direct endpoint) is being phased out. Always use the mirror-ingress port to ensure compatibility with all endpoints.

If you need to access it directly:

kubectl port-forward svc/mirror-1-rest -n "${SOLO_NAMESPACE}" 5551:80 &
curl -s "http://${REST_IP:-127.0.0.1}:5551/api/v1/transactions?limit=1"

Option B: Mirror Node gRPC

For mirror node gRPC subscriptions (e.g. topic messages, account balance updates), enable port-forwarding manually if not already active:

kubectl port-forward svc/mirror-1-grpc -n "${SOLO_NAMESPACE}" 5600:5600 &

Then verify available services:

grpcurl -plaintext "${GRPC_IP:-127.0.0.1}:5600" list

Option C: Mirror Node REST-Java (Direct Access)

For direct access to the rest-java service (bypassing the ingress):

kubectl port-forward service/mirror-1-restjava -n "${SOLO_NAMESPACE}" 8084:80 &

# Example: NFT allowances
curl -s "http://${REST_IP:-127.0.0.1}:8084/api/v1/accounts/0.0.2/allowances/nfts"

In most cases you should use localhost:38081 (Solo 0.63+) or localhost:8081 (Solo 0.62 and earlier) instead.

Port Reference

The ports listed below are Solo’s default targets. Solo checks each port before opening a tunnel - if the port is already in use, Solo picks the next available one and logs Using available port <port>. If an endpoint is not reachable, check the actual ports your deployment is using with solo deployment config ports --deployment <deployment-name> - see Port availability for the full set of commands.

The default local ports depend on your Solo version:

Solo 0.63 and later (current defaults):

ServiceLocal PortAccess Method
Hiero Explorer38080Browser (--enable-ingress)
Mirror Node (all-in-one)38081HTTP (--enable-ingress)
Mirror Node REST API5551kubectl port-forward (manual)
Mirror Node gRPC5600kubectl port-forward
Mirror Node REST Java8084kubectl port-forward

Solo 0.62 and earlier:

ServiceLocal PortAccess Method
Hiero Explorer8080Browser (--enable-ingress)
Mirror Node (all-in-one)8081HTTP (--enable-ingress)
Mirror Node REST API5551kubectl port-forward
Mirror Node gRPC5600kubectl port-forward
Mirror Node REST Java8084kubectl port-forward

Restoring Port-Forwards

If port-forwards are interrupted — for example after a system restart — restore them by re-running the relevant component add commands. These commands are idempotent and will reattach port-forwards without redeploying:

solo mirror node add --deployment "${SOLO_DEPLOYMENT}"
solo explorer node add --deployment "${SOLO_DEPLOYMENT}"

Tearing Down

To remove the Mirror Node from a running deployment:

solo mirror node destroy --deployment "${SOLO_DEPLOYMENT}" --force

To remove the Hiero Mirror Node Explorer:

solo explorer node destroy --deployment "${SOLO_DEPLOYMENT}" --force

For full network teardown, see Step-by-Step Manual Deployment-Cleanup.

3.2 - Using Solo with Hiero SDKs

Walk through submitting your first transaction to a local Solo network using the Hiero JavaScript, Java, or Go SDK.

Overview

The Hiero SDKs let you build and test applications on the Hiero network using JavaScript / TypeScript, Java, or Go. This guide walks you through launching a local Solo network, locating its bootstrap operator account, setting up a project for your chosen SDK, and running example transactions. The Solo-side steps are identical across all three SDKs; the language-specific steps appear in tabs you can switch between.

Prerequisites

Before proceeding, ensure you have completed the following:

  • System Readiness:

    • Your local environment meets all hardware and software requirements, including Docker, kubectl, and Solo.

    • The shared baseline tools:

      RequirementVersionPurpose
      Docker DesktopLatestRuns the Solo cluster containers
      SoloLatest stableDeploys and manages the local network

  • Plus the SDK-specific toolchain for the language you’ll use:

    RequirementVersionPurpose
    Node.jsv20 or higherRuns your application against the SDK
    RequirementVersionPurpose
    JDKv21 or higher (Eclipse Temurin recommended)Required by the Hiero Java SDK
    Gradlev8.5 or laterBuilds and runs the Java project
    RequirementVersionPurpose
    Gov1.25 or higherRequired by the Hiero Go SDK

Note: Solo uses Docker Desktop to spin up local Hiero consensus and mirror nodes. Ensure Docker Desktop is running before deploying the local network.

Step 1: Launch a Local Solo Network

Deploy a local Solo network by following the Solo Quickstart. Once it’s running, retrieve your deployment name with solo one-shot show deployment - the rest of this guide refers to it as <your-deployment-name>.

Step 2: Install the SDK

Install the Hiero SDK for your language.

Initialize a Node.js project and install the SDK from npm:

mkdir solo-js-demo && cd solo-js-demo
npm init -y
npm install @hiero-ledger/sdk

For the full SDK source tree (with the bundled examples/ directory), follow the Hiero JavaScript SDK README. The repository uses pnpm workspaces + go-task to build.

Follow the Hiero Java SDK quickstart to set up a Gradle (or Maven) project. The minimum dependency set:

implementation("com.hedera.hashgraph:sdk:2.72.0")
implementation("io.grpc:grpc-netty-shaded:1.64.0")
implementation("org.slf4j:slf4j-nop:2.0.9")

Initialize a Go module and add the Hiero Go SDK:

mkdir solo-go-demo && cd solo-go-demo
go mod init solo-go-demo
go get github.com/hiero-ledger/hiero-sdk-go/v2@v2.80.0

Go 1.25 or higher is required (per go.mod in the SDK). See the Hiero Go SDK README for the full setup walkthrough.

Step 3: Locate Your Operator Credentials

solo one-shot single deploy provisions a bootstrap operator account (0.0.2) at genesis and writes its credentials to disk. Use this account as your operator - you do not need to call solo ledger account create for the examples in this guide.

  • Print the operator credentials:

    cat ~/.solo/one-shot-<your-deployment-name>/accounts.json

  • Expected output:

    {
  "systemAccounts": [
    {
      "name": "Operator",
      "accountId": "0.0.2",
      "publicKey": "302a300506032b65700321000aa8e21064c61eab86e2a9c164565b4e7a9a4146106e0a6cd03a8c395a110e92",
      "privateKey": "302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137"
    }
  ],
  "createdAccounts": [
    { "accountId": "0.0.1002", "privateKey": "0x105d050185...", "balance": "1000000 ℏ", "group": "ecdsa-alias" },
    ...
  ]
}

    The systemAccounts[0] block is the operator (0.0.2) with an Ed25519 key in DER format. The createdAccounts array contains additional pre-funded ECDSA-alias accounts useful for EVM workflows.

  • Save the accountId and privateKey values from systemAccounts[0] - you will configure the SDK with them in the next step.

EVM tooling note: For ethers.js, Hardhat, or Foundry, use one of the createdAccounts entries; their privateKey values are already in 0x-prefixed hex form. See Using Solo with EVM Tools for the full EVM-side workflow.

Step 4: Configure the SDK to Connect to Solo

Each SDK reads operator credentials and the network endpoint differently. Pick your language tab below.

The Hiero JavaScript SDK uses environment variables to authenticate the operator account. Create a .env file at the root of the hiero-sdk-js directory:

cd hiero-sdk-js

cat > .env <<EOF
# Operator account ID (systemAccounts[0].accountId from Step 3)
OPERATOR_ID="0.0.2"

# Operator private key (systemAccounts[0].privateKey from Step 3)
OPERATOR_KEY="302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137"

# Required by LocalProvider in the SDK example scripts (Step 5).
# Not used by the Client.fromConfig() snippet below, but harmless to include.
HEDERA_NETWORK="local-node"
EOF

source .env

Important: OPERATOR_KEY must be set to the privateKey value, not the publicKey. The private key is the longer DER-encoded string beginning with 302e.... The example scripts also require HEDERA_NETWORK - they throw “LocalProvider requires the HEDERA_NETWORK environment variable to be set” if it is missing.

Security: Never commit .env to source control - the file holds the operator’s private key. Add .env to your repository’s .gitignore.

Configure the client with the Solo 0.63+ port-forwards using Client.fromConfig(). The SDK’s built-in Client.forLocalNode() preset is hardcoded to localhost:50211, which does not match Solo 0.63+ defaults (localhost:35211 for consensus gRPC, localhost:38081 for the mirror node ingress). Use the explicit network map shown below instead:

import { Client, AccountId } from "@hiero-ledger/sdk";

const network = { "127.0.0.1:35211": AccountId.fromString("0.0.3") };
const mirrorNetwork = "127.0.0.1:38081";

const client = Client.fromConfig({
  network,
  mirrorNetwork,
  // Required: the SDK's address-book refresh otherwise pulls in the
  // hardcoded 50211/50212 ports, which Solo 0.63+ does not expose.
  scheduleNetworkUpdate: false,
});
client.setOperator(process.env.OPERATOR_ID!, process.env.OPERATOR_KEY!);

Create a .env file at the project root to hold your operator credentials:

cat > .env <<EOF
# Operator account ID (systemAccounts[0].accountId from Step 3)
OPERATOR_ID=0.0.2

# Operator private key (systemAccounts[0].privateKey from Step 3)
OPERATOR_KEY=302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137
EOF

Important: OPERATOR_KEY must be the privateKey value, not the publicKey. The private key is the longer DER-encoded string beginning with 302e....

Security: Never commit .env to source control - the file holds the operator’s private key. Add .env to your repository’s .gitignore.

Load the env variables:

set -a; source .env; set +a

Configure the client in src/main/java/Main.java. Unlike the JavaScript SDK (which ships a LocalProvider / Client.forName("local-node") preset), the Hiero Java SDK has no local-node preset - Client.forName(...) only accepts "mainnet", "testnet", or "previewnet" and throws IllegalArgumentException otherwise. Build the network map explicitly using Client.forNetwork(Map) against Solo’s auto-forwarded ports:

import com.hedera.hashgraph.sdk.AccountId;
import com.hedera.hashgraph.sdk.AccountInfoQuery;
import com.hedera.hashgraph.sdk.Client;
import com.hedera.hashgraph.sdk.PrivateKey;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class Main {
    public static void main(String[] args) throws Exception {
        String operatorId  = System.getenv("OPERATOR_ID");
        String operatorKey = System.getenv("OPERATOR_KEY");
        if (operatorId == null || operatorKey == null) {
            throw new IllegalStateException(
                    "Set OPERATOR_ID and OPERATOR_KEY env vars before running.");
        }

        Map<String, AccountId> network = new HashMap<>();
        network.put("127.0.0.1:35211", AccountId.fromString("0.0.3"));

        Client client = Client.forNetwork(network);
        client.setMirrorNetwork(List.of("127.0.0.1:38081"));
        client.setOperator(
                AccountId.fromString(operatorId),
                PrivateKey.fromString(operatorKey));

        // ... transactions and queries go here ...

        client.close();
    }
}

Client.setMirrorNetwork(List<String>) declares throws InterruptedException, and queries/transactions throw TimeoutException / PrecheckStatusException. Declaring throws Exception on main keeps the example readable; wrap with explicit try/catch in production code.

The Hiero Go SDK reads operator credentials and the target network from environment variables.

Create a .env file at the project root:

cat > .env <<'EOF'
# Operator account ID (systemAccounts[0].accountId from Step 3)
export OPERATOR_ID="0.0.2"

# Operator private key (systemAccounts[0].privateKey from Step 3)
export OPERATOR_KEY="302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137"

# Network name. "localhost" is the SDK's local-node preset; only used by
# ClientForName(...) - the explicit ClientForNetworkV2 path below ignores it.
export HEDERA_NETWORK="localhost"
EOF

source .env

Important: OPERATOR_KEY must be the privateKey value, not the publicKey. The private key is the longer DER-encoded string beginning with 302e....

Security: Never commit .env to source control. Add it to .gitignore.

Configure the client in main.go. The Hiero Go SDK ships a ClientForName preset that recognizes "local" and "localhost", but the preset is hardcoded to 127.0.0.1:50211 (consensus gRPC) and 127.0.0.1:5600 (mirror gRPC) - ports Solo does not expose by default (Solo’s auto-port-forwards use 35211 and 38081). The simplest path that works out of the box is to build the network map explicitly with ClientForNetworkV2:

package main

import (
    "fmt"
    "os"

    hiero "github.com/hiero-ledger/hiero-sdk-go/v2/sdk"
)

func main() {
    operatorID := os.Getenv("OPERATOR_ID")
    operatorKey := os.Getenv("OPERATOR_KEY")
    if operatorID == "" || operatorKey == "" {
        fmt.Fprintln(os.Stderr, "Set OPERATOR_ID and OPERATOR_KEY env vars before running.")
        os.Exit(1)
    }

    network := map[string]hiero.AccountID{
        "127.0.0.1:35211": {Account: 3},
    }

    client, err := hiero.ClientForNetworkV2(network)
    if err != nil {
        panic(err)
    }
    defer client.Close()

    client.SetMirrorNetwork([]string{"127.0.0.1:38081"})

    opAccID, err := hiero.AccountIDFromString(operatorID)
    if err != nil {
        panic(err)
    }
    opKey, err := hiero.PrivateKeyFromString(operatorKey)
    if err != nil {
        panic(err)
    }
    client.SetOperator(opAccID, opKey)

    // ... transactions and queries go here ...
}

The network map’s value uses the struct literal hiero.AccountID{Account: 3} (matches network-node1’s 0.0.3). This is shorter than hiero.AccountIDFromString("0.0.3") and matches the form upstream examples use.

Verify your configuration

Add an AccountInfoQuery for the operator and run it to confirm the client reaches Solo.

In your TypeScript/JavaScript code, after building client:

const info = await new AccountInfoQuery()
  .setAccountId(AccountId.fromString(process.env.OPERATOR_ID!))
  .execute(client);

console.log("Account ID :", info.accountId.toString());
console.log("Balance    :", info.balance.toString());

In Main.java, after setOperator(...):

var info = new AccountInfoQuery()
        .setAccountId(AccountId.fromString(operatorId))
        .execute(client);

System.out.println("Account ID : " + info.accountId);
System.out.println("Balance    : " + info.balance);

Then run gradle run.

Expected output:

Account ID : 0.0.2
Balance    : 49989999499.9946 ℏ

In main.go, after SetOperator(...):

info, err := hiero.NewAccountInfoQuery().
    SetAccountID(opAccID).
    Execute(client)
if err != nil {
    panic(err)
}
fmt.Printf("Account ID : %s\n", info.AccountID)
fmt.Printf("Balance    : %s\n", info.Balance)

Then run go run ..

Expected output:

Account ID : 0.0.2
Balance    : 4.99899994792001e+10 ℏ

The Hbar value is printed in scientific notation by default; format it with info.Balance.As(hiero.HbarUnits.Hbar) or info.Balance.AsTinybar() for decimal HBAR or tinybars.

The exact balance differs slightly between deployments; what matters is that an AccountInfo returns at all - that proves the gRPC pipe to the consensus node is alive and the operator credentials are valid.

Step 5: Run Transactions Against Solo

Heads up (JavaScript and Go only): The SDK example programs use the SDK’s local-node preset (LocalProvider in JS, ClientForName("localhost") in Go), which is hardcoded to 127.0.0.1:50211 (consensus gRPC) and 127.0.0.1:5600 (mirror gRPC). Solo doesn’t expose those ports by default, so the upstream example programs cannot reach the network out of the box. Either follow Make the examples reachable below, or rewrite the example to use the Client.fromConfig (JS) / ClientForNetworkV2 (Go) pattern from Step 4. The Java SDK has no local-node preset, so this caveat does not apply there.

Make the examples reachable

Pick one:

Option A - forward Solo’s services to the SDK’s legacy ports (run examples unchanged):

kubectl port-forward svc/haproxy-node1-svc -n <your-deployment-name> 50211:50211 &
kubectl port-forward svc/mirror-1-grpc     -n <your-deployment-name> 5600:5600 &

The kubectl namespace matches <your-deployment-name> for default one-shot deploys.

Option B - edit the example to use the Client.fromConfig({ ..., scheduleNetworkUpdate: false }) pattern from Step 4. No port-forwarding needed.

No additional setup required. The Client.forNetwork(Map) pattern from Step 4 hits Solo’s auto-forwarded ports (35211 consensus, 38081 mirror) directly.

Pick one:

Option A - forward Solo’s services to the SDK’s legacy ports (run upstream examples with HEDERA_NETWORK="localhost" unchanged):

kubectl port-forward svc/haproxy-node1-svc -n <your-deployment-name> 50211:50211 &
kubectl port-forward svc/mirror-1-grpc     -n <your-deployment-name> 5600:5600 &

Option B - use ClientForNetworkV2 directly (the pattern shown in Step 4). No port-forwarding needed.

Try a tutorial against your Solo network

Once your client is configured (Step 4), the canonical Hiero / Hedera SDK tutorials run against Solo the same way they run against testnet or mainnet - only the network endpoint changes. Pick a tutorial and follow it as written:

Each SDK also ships a runnable examples/ directory with dozens of additional patterns - token creation, smart contract deployment, HCS pub/sub, scheduled transactions, and more.

Verify transactions you submit in the Hiero Explorer: http://localhost:38080/localnet/dashboard.

Step 6: Tear Down the Network

When you are finished, remove the local consensus node, mirror node, block node, relay, explorer, and all data volumes:

solo one-shot single destroy \
  --deployment <your-deployment-name>

Optional: Manage Files on the Network

Solo provides CLI commands to create and update files stored on the Hiero File Service.

Create a New File

solo ledger file create \
  --deployment <your-deployment-name> \
  --file-path ./config.json

This command:

  • Creates a new file on the network and returns a system-assigned file ID.
  • Automatically splits files larger than 4 KB into chunks using FileAppendTransaction.
  • Verifies that the uploaded content matches the local file.

Update an Existing File

solo ledger file update \
  --deployment <your-deployment-name> \
  --file-id 0.0.1234 \
  --file-path ./updated-config.json

This command:

  • Verifies the file exists on the network (errors if not found).
  • Replaces the file content and re-verifies the upload.
  • Automatically handles chunking for large files (>4 KB).

Note: For files larger than 4 KB, both commands split content into 4 KB chunks and display per-chunk progress during the append phase.

Inspect Transactions in Hiero Explorer

Open the Hiero Explorer to visually inspect submitted transactions, accounts, topics, and files. The Solo Quickstart’s Access your local network section lists the Explorer URL and port-availability behavior. Once it’s open, search by account ID, transaction ID, or topic ID to confirm that your transactions reached consensus.

Retrieving Logs

Solo writes logs to ~/.solo/logs/:

Log FileContents
solo.logHuman-readable Solo CLI output and lifecycle events
solo.ndjsonNewline-delimited JSON of the same events (authoritative, machine-readable)

The Solo log is useful for debugging connectivity issues between the SDK and your local Solo network.

SDK logging

For SDK-side logs (which logger each SDK uses and how to configure it), see the upstream docs:

Troubleshooting

SymptomLikely CauseFix
LocalProvider requires the HEDERA_NETWORK environment variable to be set (JS)HEDERA_NETWORK missing from .env, or .env not sourced in this shellAdd HEDERA_NETWORK="local-node" to .env; then source .env
Dependency resolution is looking for a library compatible with JVM runtime version 17, but 'com.hedera.hashgraph:sdk:2.72.0' is only compatible with JVM runtime version 21 or newer (Java)JDK 17 target in build.gradle.ktsSet sourceCompatibility = JavaVersion.VERSION_21 and ensure the JDK on PATH is v21+
IllegalArgumentException: Name must be one-of 'mainnet', 'testnet', or 'previewnet' (Java)Called Client.forName("local-node")Use Client.forNetwork(Map) + setMirrorNetwork(List); Java SDK has no local-node preset
go: module ... requires go >= 1.25 (Go)Local Go is older than the SDK’s go.mod floorUpgrade Go to v1.25+; on macOS, brew install go
TimeoutException from query or transaction (all SDKs)Consensus node not actually serving (deploy reported a NodesStarted timeout even though the pod is Running)Run solo one-shot single destroy --deployment <name> then solo one-shot single deploy; the second attempt usually succeeds
SDK calls fail; 127.0.0.1:35211 shows as not listening (all SDKs)Solo’s auto-port-forward for consensus gRPC died after deployRestore manually: kubectl port-forward svc/haproxy-node1-svc -n <your-deployment-name> 35211:50211 &
Upstream SDK example hangs against Solo (JS, Go)Example uses the SDK’s local-node preset, hardcoded to ports Solo doesn’t exposeFollow Option A or B in Make the examples reachable
INVALID_SIGNATURE receipt errorOPERATOR_KEY set to public key instead of private keyRe-check your .env - use the privateKey field value
INSUFFICIENT_TX_FEEOperator account has no HBARUse a pre-funded createdAccounts entry or top up the operator

Resources

3.3 - Using Solo with EVM Tools

Point your existing Ethereum tooling (Hardhat, ethers.js, and MetaMask) at a local Hiero network via the Hiero JSON-RPC relay. This document covers enabling the relay, creating and configuring a Hardhat project, deploying a Solidity contract, and configuring wallets.

Overview

Hiero is EVM-compatible. The Hiero JSON-RPC relay exposes a standard Ethereum JSON-RPC interface on your local Solo network, letting you use familiar EVM tools without modification.

This guide walks you through:

  • Launching a Solo network with the JSON-RPC relay enabled.
  • Retrieving ECDSA accounts for EVM tooling.
  • Creating and configuring a Hardhat project against the relay.
  • Deploying and interacting with a Solidity contract.
  • Verifying transactions via the Explorer and Mirror Node.
  • Configuring ethers.js and MetaMask.

Prerequisites

Before proceeding, ensure you have completed the following:

  • System Readiness - your local environment meets all hardware and software requirements, including Docker and Solo.
  • Quickstart - you are comfortable running Solo deployments.

You will also need:

Step 1: Launch a Solo Network with the JSON-RPC Relay

The easiest way to start a Solo network with the relay pre-configured is via one-shot single deploy, which provisions the consensus node, mirror node, Hiero Mirror Node Explorer, and the Hiero JSON-RPC relay in a single step:

npx @hiero-ledger/solo one-shot single deploy

This command:

  • Creates a local Kind Kubernetes cluster.
  • Deploys a Hiero consensus node, mirror node, and Hiero Mirror Node Explorer.
  • Deploys the Hiero JSON-RPC relay and exposes it at http://localhost:37546 (Solo 0.63+).
  • Generates three groups of pre-funded accounts, including ECDSA (EVM-compatible) accounts.

Relay endpoint summary (Solo 0.63 and later):

PropertyValue
RPC URLhttp://localhost:37546
Chain ID298
Currency symbolHBAR

If you are using Solo 0.62 or earlier, the relay is at http://localhost:7546.

Adding the Relay to an Existing Deployment

If you already have a running Solo network without the relay, see Step 10: Deploy JSON-RPC Relay in the Step-by-Step Manual Deployment guide for full instructions, then return here once your relay is running on http://localhost:37546 (Solo 0.63+) or http://localhost:7546 (Solo 0.62 and earlier).

To remove the relay when you no longer need it, see Cleanup Step 1: Destroy JSON-RPC Relay in the same guide.

Step 2: Retrieve Your ECDSA Account and Private Key

one-shot single deploy creates ECDSA alias accounts, which are required for EVM tooling such as Hardhat, ethers.js, and MetaMask. These accounts and their private keys are saved to a cache directory on completion.

Note: ED25519 accounts are not compatible with Hardhat, ethers.js, or MetaMask when used via the JSON-RPC interface. Always use the ECDSA keys from accounts.json for EVM tooling.

  • To find your deployment name, run solo one-shot show deployment (see Capture your deployment name).

  • Then open the accounts file at:

    ~/.solo/one-shot-<deployment-name>/accounts.json

  • Open that file to retrieve your ECDSA keys and EVM address. Each account entry contains:

    • An ECDSA private key - 64 hex characters with a 0x prefix (e.g. 0x105d0050...).
    • An ECDSA public key - the corresponding public key.
    • An EVM address - derived from the public key (e.g. 0x70d379d473e2005bb054f50a1d9322f45acb215a). In Hiero terminology, this means the account has an EVM address aliased from its ECDSA public key.
    0x105d0050185ccb907fba04dd92d8de9e32c18305e097ab41dadda21489a211524
0x2e1d968b041d84dd120a5860cee60cd83f9374ef527ca86996317ada3d0d03e7
...

  • Export the private key for one account as an environment variable - never hardcode private keys in source files:

export SOLO_EVM_PRIVATE_KEY="0x105d0050185ccb907fba04dd92d8de9e32c18305e097ab41dadda21489a211524"

$env:SOLO_EVM_PRIVATE_KEY = '0x105d0050185ccb907fba04dd92d8de9e32c18305e097ab41dadda21489a211524'

Step 3: Create and Configure a Hardhat Project

A ready-to-run Hardhat project is provided in the Solo repository. Skip to Step 4 after cloning:

git clone https://github.com/hiero-ledger/solo.git
cd solo/examples/hardhat-with-solo/hardhat-example
npm install

Option B: Create a New Hardhat Project from Scratch

If you want to integrate Solo into your own project:

mkdir solo-hardhat && cd solo-hardhat
npm init -y
npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox
npx hardhat init

When prompted, choose TypeScript project or JavaScript project based on your preference.

Install dependencies:

npm install

Configure Hardhat to Connect to the Solo Relay

Create or update hardhat.config.ts to point at the Solo JSON-RPC relay. The chainId of 298 is required - Hardhat will reject transactions if it does not match the network:

import { defineConfig } from "hardhat/config";
import hardhatToolboxMochaEthers from "@nomicfoundation/hardhat-toolbox-mocha-ethers";

const config = defineConfig({
  plugins: [hardhatToolboxMochaEthers],
  solidity: "0.8.28",
  networks: {
    my_solo_deployment: {
      type: "http",
      url: "http://127.0.0.1:37546",
      chainId: 298,
      // Load from environment - never commit private keys to source control
      accounts: process.env.SOLO_EVM_PRIVATE_KEY
        ? [process.env.SOLO_EVM_PRIVATE_KEY]
        : [],
    },
  },
});

export default config;

Important: This is the Hardhat v3 config format used by the bundled example (Hardhat 3.x). Each network needs an explicit type: "http", and chainId: 298 must be set - without type/chainId, Hardhat v3 fails with HHE40000: No network with chain id "298" found when connecting to the relay. The network key (my_solo_deployment) must match the --network flag you pass to Hardhat commands.

Step 4: Deploy and Interact with a Solidity Contract

The Sample Contract

If using the pre-built Solo example, contracts/SimpleStorage.sol is included. For a new project, create contracts/SimpleStorage.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract SimpleStorage {
    uint256 private value;

    event ValueChanged(
        uint256 indexed oldValue,
        uint256 indexed newValue,
        address indexed changer
    );

    constructor(uint256 initial) {
        value = initial;
    }

    function get() external view returns (uint256) {
        return value;
    }

    function set(uint256 newValue) external {
        uint256 old = value;
        value = newValue;
        emit ValueChanged(old, newValue, msg.sender);
    }
}

Compile the Contract

npx hardhat compile

Expected output:

Compiled 1 Solidity file successfully (evm target: paris).

Run the Tests

npx hardhat test --network my_solo_deployment

For the pre-built example, the test suite covers three scenarios:

  SimpleStorage
    ✔ deploys with initial value
    ✔ updates value and emits ValueChanged event
    ✔ allows other accounts to set value

  3 passing (12s)

Deploy via a Script

To deploy SimpleStorage to your Solo network using a deploy script:

npx hardhat run scripts/deploy.ts --network my_solo_deployment

A minimal scripts/deploy.ts looks like:

Hardhat v3: The bundled example pins Hardhat 3.x, which removed the ethers named export from the hardhat module. Obtain ethers from the network connection with const { ethers } = await network.connect() instead of import { ethers } from "hardhat".

import { network } from "hardhat";

async function main() {
  const { ethers } = await network.connect();
  const SimpleStorage = await ethers.getContractFactory("SimpleStorage");
  const contract = await SimpleStorage.deploy(42);
  await contract.waitForDeployment();

  console.log("SimpleStorage deployed to:", await contract.getAddress());
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Step 5: Send a Transaction with ethers.js

To submit a transaction directly from a script using ethers.js via Hardhat:

import { network } from "hardhat";

async function main() {
  const { ethers } = await network.connect();
  const [sender] = await ethers.getSigners();
  console.log("Sender:", sender.address);

  const balance = await ethers.provider.getBalance(sender.address);
  console.log("Balance:", ethers.formatEther(balance), "HBAR");

  const tx = await sender.sendTransaction({
    to: sender.address,
    value: 10_000_000_000n,
  });

  await tx.wait();
  console.log("Transaction confirmed. Hash:", tx.hash);
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Run it with:

npx hardhat run scripts/send-tx.ts --network my_solo_deployment

Step 6: Verify Transactions

Confirm your transactions reached consensus using any of the following:

Hiero Mirror Node Explorer

http://localhost:38080/localnet/dashboard

Note: If you are using Solo 0.62 or earlier, the Explorer is at http://localhost:8080/localnet/dashboard.

Search by account address, transaction hash, or contract address to view transaction details and receipts.

Hiero Mirror Node REST API

http://localhost:38081/api/v1/transactions?limit=5

Returns the five most recent transactions in JSON format. Useful for scripted verification.

Note: localhost:5551 (the legacy Mirror Node REST API direct endpoint) is being phased out. Use localhost:38081 (Solo 0.63+) or localhost:8081 (Solo 0.62 and earlier) to ensure compatibility with all endpoints.

Hiero JSON RPC Relay (eth_getTransactionReceipt)

curl -X POST http://localhost:37546 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xYOUR_TX_HASH"],"id":1}'

Step 7: Configure MetaMask

To connect MetaMask to your local Solo network:

  1. Open MetaMask and go to Settings → Networks → Add a network → Add a network manually.

  2. Enter the following values:

    FieldValue
    Network nameSolo Local
    New RPC URLhttp://localhost:37546
    Chain ID298
    Currency symbolHBAR

    Note: If you are using Solo 0.62 or earlier, use http://localhost:7546 for the RPC URL.

  3. Click Save and switch to the Solo Local network.

  4. Import an account using an ECDSA private key from accounts.json:

    • Click the account icon → Import account.
    • Paste the private key (with 0x prefix).
    • Click Import.

Your MetaMask wallet is now connected to the local Solo network and funded with the pre-allocated HBAR balance.

Step 8: Tear Down the Network

When finished, destroy the Solo deployment and all associated containers:

npx @hiero-ledger/solo one-shot single destroy

If you added the relay manually to an existing deployment:

solo relay node destroy --deployment "${SOLO_DEPLOYMENT}"

Reference: Running the Full Example Automatically

The hardhat-with-solo example includes a Taskfile.yml that automates all steps - deploy network, install dependencies, compile, and test - in a single command:

cd solo/examples/hardhat-with-solo
task

To tear everything down:

task destroy

This is useful for CI pipelines. See the Solo deployment with Hardhat Example for full details.

Troubleshooting

SymptomLikely CauseFix
connection refused on port 37546Relay not runningRun one-shot single deploy or solo relay node add
invalid sender or signature errorUsing ED25519 key instead of ECDSAUse ECDSA keys from accounts.json
Hardhat chainId mismatch errorMissing or wrong chainId in configSet chainId: 298 in hardhat.config.ts
MetaMask shows wrong networkChain ID mismatchEnsure Chain ID is 298 in MetaMask network settings
INSUFFICIENT_TX_FEE on transactionAccount not fundedUse a pre-funded ECDSA account from accounts.json
Hardhat test timeoutNetwork not fully startedWait for one-shot to fully complete before running tests
Port 37546 already in useAnother process is using the portRun lsof -i :37546 and stop the conflicting process

Further Reading

3.4 - Using Network Load Generator with Solo

Learn how to run load tests against a Solo network using the Network Load Generator (NLG). Generate realistic transaction flows and stress-test your deployment to verify performance under load.

Using Network Load Generator with Solo

The Network Load Generator (NLG) is a benchmarking tool that stress tests Hiero networks by generating configurable transaction loads. Use it to validate the performance and stability of your Solo network before deploying to production or running integration tests.

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 and are familiar with the basic Solo workflow.

Step 1: Start a Load Test

Use the rapid-fire load start command to install the NLG Helm chart and begin a load test against your deployment.

   npx @hiero-ledger/solo@latest rapid-fire load start \
 --deployment <deployment-name> \
 --args '"-c 3 -a 10 -t 60"' \
 --test CryptoTransferLoadTest

Replace <deployment-name> with your deployment name - find it with solo one-shot show deployment (see Capture your deployment name).

The --args flag passes arguments directly to the NLG. In this example:

  • -c 3 — 3 concurrent threads
  • -a 10 — 10 accounts
  • -t 60 — run for 60 seconds

Step 2: Run Multiple Load Tests (Optional)

You can run additional load tests in parallel from a separate terminal. Each test runs independently against the same deployment:

    npx @hiero-ledger/solo@latest rapid-fire load start \
  --deployment <deployment-name> \
  --args '"-c 3 -a 10 -t 60"' \
  --test NftTransferLoadTest

Step 3: Stop a Specific Load Test

To stop a single running load test before it completes, use the stop command:

    npx @hiero-ledger/solo@latest rapid-fire load stop \
  --deployment <deployment-name> \
  --test CryptoTransferLoadTest

Step 4: Tear Down All Load Tests

To stop all running load tests and uninstall the NLG Helm chart:

    npx @hiero-ledger/solo@latest rapid-fire destroy all \
  --deployment <deployment-name>

Complete Example

For an end-to-end walkthrough with a full configuration, see the examples/rapid-fire.

Available Tests and Arguments

A full list of all available rapid-fire commands can be found in Solo CLI Reference.

3.5 - Deploying a Local Consensus Node Build

Test unreleased hiero-consensus-node changes end-to-end using Solo’s –local-build-path flag — no Docker image rebuild or registry push required.

Overview

Solo’s --local-build-path flag lets you deploy a network using a consensus node binary you compiled locally. Use this when you need to:

  • Test unreleased hiero-consensus-node code against a live Solo network.
  • Reproduce a bug with a specific build.
  • Iterate on platform changes without a full release cycle.

Solo validates the path for the expected apps/ and lib/ subdirectories, then uses kubectl cp to push the local binaries directly into the running node pods — no Docker image rebuild or registry push required.

Scope: This guide covers the consensus node local build workflow. Local build support for mirror node, block node, relay, and explorer requires additional engineering work and is not yet available as a first-class Solo feature.

Prerequisites

  • Solo CLI installed — if you have not yet deployed a network, follow the Quickstart first.

  • hiero-consensus-node cloned locally — see Step 1.

  • Java 25 (Temurin) — this is a hard Gradle toolchain requirement; Java 21 will fail with a cryptic toolchain error. Install with SDKMAN:

    sdk install java 25.0.2-tem

  • Gradle — the repository includes the Gradle wrapper (./gradlew); no separate Gradle install is needed.

Step 1: Build hiero-consensus-node

Clone the repository and run ./gradlew assemble. This compiles the consensus node and populates hedera-node/data/ with the runtime artifacts Solo needs:

  • hedera-node/data/lib/ — runtime dependency JARs
  • hedera-node/data/apps/HederaNode.jar — the main consensus node binary
git clone https://github.com/hiero-ledger/hiero-consensus-node.git
cd hiero-consensus-node
./gradlew assemble

To build a specific release tag, use --branch:

git clone https://github.com/hiero-ledger/hiero-consensus-node.git \
  --depth 1 --branch @<VERSION>
cd hiero-consensus-node
./gradlew assemble

Note: The initial Gradle build downloads dependencies and compiles all modules. Expect 10–30 minutes on a first run; subsequent incremental builds are faster.

Note: Solo copies data/lib/ and data/apps/ from your build path but skips data/config/ and data/keys/ — those come from the container image. To customise consensus node configuration, see Custom Application Properties.

Step 2: Deploy with your local build

Choose the path that matches your situation.

Option A — New cluster (Falcon deploy)

Creates a fresh Kind cluster and deploys the full Solo network from scratch, using your local build for the consensus node.

Create a values file with the --local-build-path flag:

# local-build-values.yaml
setup:
  --local-build-path: "/absolute/path/to/hiero-consensus-node/hedera-node/data"

Then deploy:

solo one-shot falcon deploy --values-file local-build-values.yaml

Use an absolute path — relative paths can behave unexpectedly depending on where Solo is invoked.

For a full deployment with mirror node, explorer, and relay, add the corresponding sections to your values file. See the One-Shot Falcon Deployment guide for the complete values file reference.

Option B — Existing cluster (consensus node setup)

If you already have a running Solo deployment and want to swap in a new consensus node binary without redeploying the whole network:

solo consensus node setup \
  --deployment <deployment-name> \
  --local-build-path /absolute/path/to/hiero-consensus-node/hedera-node/data

Replace <deployment-name> with your deployment name — retrieve it with:

cat ~/.solo/cache/last-one-shot-deployment.txt

Step 3: Verify the local build is running

Confirm that the consensus node gRPC port is reachable:

nc -zv localhost 35211

Expected output:

Connection to localhost port 35211 [tcp/*] succeeded!

Confirm that the pods are running your local build by inspecting the container images:

kubectl get pods -n <namespace> -o \
  jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

Replace <namespace> with your deployment namespace (default: one-shot). The consensus node pod should reference the image tag that matches your --release-tag (or the Solo built-in default if you omitted it). The key indicator is that the node started successfully with your local data/lib/ and data/apps/ artifacts copied in.

Step 4: Tear down

solo one-shot falcon destroy

Reference: ready-to-run example

The Solo repository ships a Task-based example that automates the full workflow — cloning at the correct versions, building the consensus node, generating an absolute-path values file, and deploying:

Run the full workflow with:

task

Troubleshooting

SymptomLikely causeFix
--local-build-path: path does not exist./gradlew assemble has not run, or the path is wrongConfirm: ls /absolute/path/to/hiero-consensus-node/hedera-node/data/apps/HederaNode.jar
./gradlew assemble fails with Unsupported class file major versionWrong Java versionCheck java -version; Java 25 (Temurin) is required. Install: sdk install java 25.0.2-tem
Consensus node pods crash on startBuild artifacts incompatible with the base container imageSet --release-tag in your values file to match the source tag you built from
nc -zv localhost 35211 fails after deployPort-forward diedRestore: kubectl port-forward svc/haproxy-node1-svc -n one-shot 35211:50211 &
Slow first deploymentMirror node, relay, and explorer images pulling for the first timeLet it complete; subsequent runs reuse the image cache

4 - Troubleshooting

Solutions to common issues when using Solo, plus guidance on getting help. This document covers installation problems, pod readiness issues, resource constraints, and how to find additional support.

This guide covers common issues you may encounter when using Solo and how to resolve them.

Quick Navigation

Use this page when something is failing and you need to diagnose or recover quickly.

If you are looking for setup or day-to-day usage guidance rather than failure diagnosis, start with these pages:

Error Code Reference

Every error Solo raises carries a structured code of the form SOLO-XXXX, an ownership classification (User, Infrastructure, or Solo), and a retryable flag. When a command fails with one of these codes, look it up in the Error Codes reference for a plain-language description of why it is thrown, along with its troubleshooting steps.

Codes are grouped by category — Configuration, Deployment, Component, Validation, System, and Internal. Solo’s CLI also prints a documentation link for each error (for example https://solo.hiero.org/docs/errors/SOLO-1001) that opens its page directly.

Anatomy of a Solo error

When a command fails with a coded error, Solo prints the code and message, suggested next steps, and a documentation link:

[SOLO-2002] A deployment named 'my-deployment' already exists. Please select a different name
  → Check existing deployments: solo deployment config list
  → Choose a different name for your deployment

Learn more: https://solo.hiero.org/docs/errors/SOLO-2002
  • [SOLO-NNNN] is the error code; its leading digit identifies the category.
  • → lines are suggested remediation steps, shown when the error provides them.
  • Learn more links to that error’s online reference page.

In the terminal, this appears inside a bordered ERROR box, followed by a tip suggesting solo deployment diagnostics logs or solo deployment diagnostics report to gather more detail.

Note: Add --dev to a command to see the full error cause chain and stack traces instead of the summarized form — useful when filing a bug report.

Common Issues and Solutions

Troubleshooting Installation and Upgrades

Installation and upgrade failures are common, especially when older installs or previous deployments are still present.

Symptoms

You are likely hitting an installation or upgrade problem if:

  • solo fails to start after changing versions.
  • solo one-shot single deploy fails early with validation or environment errors.
  • Commands report missing dependencies or incompatible versions.
  • A new deployment fails immediately after a previous network was not destroyed.
  • A global install fails with EEXIST: file already exists pointing at .../bin/solo. This happens when Solo is already installed under the other npm package name (@hiero-ledger/solo and @hashgraph/solo are mirrors that share the solo binary). See Resolving an EEXIST package-name conflict.

Quick Checks

  1. Confirm installation method

    If you previously installed Solo via npm and are now using Homebrew, remove the npm install to avoid conflicts. Solo is published under two npm names (@hiero-ledger/solo and @hashgraph/solo), so remove both:

    # Remove any npm-based Solo (if present)
if command -v npm >/dev/null 2>&1; then
  npm uninstall -g @hiero-ledger/solo || true
  npm uninstall -g @hashgraph/solo || true
fi

    Then reinstall Solo using the steps in the Quickstart. If a global npm install fails with EEXIST because both package names are present, see Resolving an EEXIST package-name conflict.

  2. Verify system resources

    • Ensure your machine and Docker (or other container runtime) meet the minimum requirements described in
      System readiness.

    • If Docker Desktop or your container runtime is configured below these values, increase the allocations and retry the install or deploy.

  3. Clean up previous deployments

    If an upgrade or redeploy fails, first run a standard destroy:

    solo one-shot single destroy

Pods not reaching Ready state

If pods remain in Pending, Init, ContainerCreating, or CrashLoopBackOff, follow this sequence to identify the blocker.

  1. Check readiness and restarts

    # Show readiness and restart count for each pod
kubectl get pods -n "${SOLO_NAMESPACE}" \
  -o custom-columns=NAME:.metadata.name,PHASE:.status.phase,READY:.status.containerStatuses[*].ready,RESTARTS:.status.containerStatuses[*].restartCount

  2. Inspect pod events

    # List all pods in your namespace
kubectl get pods -n "${SOLO_NAMESPACE}"

# Describe a specific pod to see events
kubectl describe pod -n "${SOLO_NAMESPACE}" <pod-name>

  3. Map symptoms to likely causes

    SymptomLikely causeNext step
    PendingInsufficient resourcesIncrease Docker memory/CPU allocation, then retry
    PendingStorage issuesCheck disk space, free space if needed, restart Docker
    CrashLoopBackOffContainer failing to startCheck pod logs: kubectl logs -n "${SOLO_NAMESPACE}" <pod-name>
    ImagePullBackOffCan’t pull container imagesCheck internet connectivity and Docker Hub rate limits

CrashLoopBackOff causes and remediation

If a pod repeatedly restarts and enters CrashLoopBackOff, inspect current logs, previous logs, and events:

# Current container logs
kubectl logs -n "${SOLO_NAMESPACE}" <pod-name>

# Previous container logs (captures startup failures)
kubectl logs -n "${SOLO_NAMESPACE}" <pod-name> --previous

# Pod events and failure reasons
kubectl describe pod -n "${SOLO_NAMESPACE}" <pod-name>

Common causes include invalid runtime configuration, missing dependencies, and insufficient memory.

  • Recommended remediation sequence:

    1. If events mention OOMKilled or repeated liveness probe failures, increase Docker CPU/RAM and retry.

    2. If the issue started after a failed upgrade or deploy, run the cleanup steps in Old installation artifacts and redeploy.

    3. If only one node is affected, refresh or restart it:

      solo consensus node refresh --node-aliases node1 --deployment "${SOLO_DEPLOYMENT}"
# or
solo consensus node restart --deployment "${SOLO_DEPLOYMENT}"

    Resource allocation:

    • Ensure your machine and Docker (or other container runtime) meet the minimum requirements described in System readiness.
    • On Docker Desktop, check: Settings > Resources.

Resource constraint errors (CPU / RAM / Disk)

Resource pressure is a common cause of Pending pods, slow startup, and repeated restarts.

  1. Check Kubernetes-level CPU and memory utilization:

    kubectl top nodes
kubectl top pods -n "${SOLO_NAMESPACE}"

  2. Check host and Docker disk usage:

    # Host disk availability
df -h

# Docker disk usage (if using Docker)
docker system df

  3. Compare against the recommended local baseline:

See System readiness for the recommended memory, CPU, and disk values.

JSON-RPC Relay Out of Memory

If the relay or relay-ws pods are being killed (OOMKilled) or restarting due to memory pressure, the sections below explain why this happens and how to resolve it.

Understanding the default memory configuration

Solo ships with a default memory limit of 88Mi and an explicit V8 old-space cap of 66MB (--max-old-space-size=66) for both the relay and WebSocket services. These values are tuned for the one-shot development profile and may not be sufficient for heavy workloads.

How Node.js memory works in containers

Since Node.js 12.7.0, Node.js reads the Linux cgroup memory limit set by Kubernetes to determine the V8 old-space heap size, rather than using the host’s physical memory. Based on V8’s internal heap sizing heuristics, this tends to be roughly ~50% of the container memory limit on 64-bit systems, though the exact value depends on V8 internals and varies at both ends of the memory spectrum.

A couple of things to be aware of:

  • cgroup v2 environments: many modern Linux distributions enable cgroup v2 by default, and Kubernetes 1.25 brought cgroup v2 support to GA. Older Node.js versions may not correctly detect the container limit under cgroup v2 and could silently fall back to the host’s physical memory, allocating a much larger heap than intended. This was improved in at least Node.js 20.3.0, which upgraded libuv to 1.45.0.
  • When --max-old-space-size is explicitly set (as in Solo’s default config), it overrides the auto-sizing entirely — the cgroup-based detection only kicks in when no explicit value is provided.

This means:

  • If you increase only the pod memory limit (e.g., to 256Mi) but leave NODE_OPTIONS unchanged, old space stays at 66 MB.
  • If you remove NODE_OPTIONS, Node.js will attempt to auto-size old space based on the container limit (roughly ~128 MB for a 256Mi pod on a modern Node.js version).

Adjusting memory for heavier workloads

Create a custom values file (e.g., custom-relay-values.yaml) and pass it when deploying:

# Option 1: Explicit old-space control (recommended for precise tuning)
relay:
  resources:
    limits:
      memory: 256Mi
  config:
    NODE_OPTIONS: '--max-old-space-size=192'
ws:
  resources:
    limits:
      memory: 256Mi
  config:
    NODE_OPTIONS: '--max-old-space-size=192'

# Option 2: Let Node.js auto-detect (simpler, old space ≈ 50% of limit)
# relay:
#   resources:
#     limits:
#       memory: 256Mi
#   config:
#     NODE_OPTIONS: ""
# ws:
#   resources:
#     limits:
#       memory: 256Mi
#   config:
#     NODE_OPTIONS: ""

Then deploy or upgrade with:

solo relay node add --deployment "${SOLO_DEPLOYMENT}" --values-file custom-relay-values.yaml
# or
solo relay node upgrade --deployment "${SOLO_DEPLOYMENT}" --values-file custom-relay-values.yaml

Connection refused errors

If you cannot connect to Solo network endpoints from your machine, use this sequence to isolate the issue.

  1. Verify services and endpoints inside the cluster

    # List all services
kubectl get svc -n "${SOLO_NAMESPACE}"

# Check if endpoints are populated
kubectl get endpoints -n "${SOLO_NAMESPACE}"

  2. Use manual port forwarding (bypass automation)

    If automatic port forwarding (from solo commands or your environment) is not working, forward the required services manually. The local ports below match the Solo 0.63+ defaults — adjust to any available port if needed:

    # Consensus node (gRPC) — local port 35211 → service port 50211
kubectl port-forward svc/haproxy-node1-svc -n "${SOLO_NAMESPACE}" 35211:50211 &

# Explorer UI — local port 38080 → service port 8080
kubectl port-forward svc/hiero-explorer -n "${SOLO_NAMESPACE}" 38080:8080 &

# Mirror node ingress (REST API) — local port 38081 → service port 80
kubectl port-forward svc/mirror-1-rest -n "${SOLO_NAMESPACE}" 38081:80 &

# Mirror node gRPC
kubectl port-forward svc/mirror-1-grpc -n "${SOLO_NAMESPACE}" 5600:5600 &

# JSON-RPC relay — local port 37546 → service port 7546
kubectl port-forward svc/relay-node1-hedera-json-rpc-relay -n "${SOLO_NAMESPACE}" 37546:7546 &

    Note: For Solo 0.62 and earlier, use local ports 50211, 8080, 5551, and 7546 respectively.

  3. Confirm the expected endpoints and ports

    After forwarding, connect to the local ports shown above (for example, http://localhost:38080 for the explorer).
    For the standard exposed endpoints after a successful one-shot deployment, see How to access exposed services (mirror node, relay, explorer).

Node synchronization issues

If nodes are not forming consensus or transactions are not being processed, follow these steps.

  1. Check node state and gossip logs:

    # Download state information for a node
solo consensus state download --deployment "${SOLO_DEPLOYMENT}" --node-aliases node1

# Check logs for gossip-related issues
kubectl logs -n "${SOLO_NAMESPACE}" network-node-0 | grep -i gossip

    Look for repeated connection failures, timeouts, or gossip disconnection messages.

  2. Restart problematic nodes:

    # Refresh a specific node
solo consensus node refresh --node-aliases node1 --deployment "${SOLO_DEPLOYMENT}"

# Or restart all nodes
solo consensus node restart --deployment "${SOLO_DEPLOYMENT}"

    After restarting, submit a small test transaction and verify that it reaches consensus.

Mirror node not importing records

If the mirror node is not showing new transactions, first confirm that records are being generated and imported.

  1. Verify the pinger is running

    The --pinger flag should be enabled when deploying the mirror node. The pinger sends periodic transactions so that record files are created.

    # Check if pinger pod is running
kubectl get pods -n "${SOLO_NAMESPACE}" | grep pinger

  2. Redeploy the mirror node with pinger enabled

    If the pinger is missing or misconfigured:

    # Destroy the existing mirror node
solo mirror node destroy --deployment "${SOLO_DEPLOYMENT}" --force

# Redeploy with pinger enabled
solo mirror node add \
  --deployment "${SOLO_DEPLOYMENT}" \
  --cluster-ref kind-${SOLO_CLUSTER_NAME} \
  --enable-ingress \
  --pinger

Helm repository errors

If you see errors such as repository name already exists, you likely have a conflicting Helm repo entry.

  1. List current Helm repositories:

    helm repo list

  2. Remove the conflicting repository:

    helm repo remove <repo-name>

# Example: remove hedera-json-rpc-relay
helm repo remove hedera-json-rpc-relay

Re-run the Solo command that configures Helm after removing the conflict.

Kind cluster issues

Problems starting or accessing the Kind cluster often present as cluster creation failures or missing nodes.

  1. Cluster will not start or is in a bad state:

    # Delete and recreate the cluster
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"

  2. Docker context or daemon issues

    Ensure Docker is running and the correct context is active:

    # Check Docker is running
docker ps

# On macOS/Windows, ensure Docker Desktop is started.
# On Linux, ensure the Docker daemon is running:
sudo systemctl start docker

Cleanup and reset (old installation artifacts)

Previous Solo installations can cause conflicts during new deployments.
For the full teardown and full reset procedure, see the Cleanup guide.

At a high level:

  1. Run a standard destroy first:

    solo one-shot single destroy

  2. If destroy fails or Solo state is corrupted, perform a full reset, which:

    • Deletes Solo-managed Kind clusters (names starting with solo).
    • Removes the Solo home directory (~/.solo).

Windows (PowerShell) issues

These issues are specific to running Solo natively from Windows PowerShell.

Paths use backslashes. Solo stores its files under $env:USERPROFILE\.solo on Windows - the equivalent of ~/.solo on macOS and Linux. When you copy a command that uses ~/.solo/..., replace it with $env:USERPROFILE\.solo\.... For example:

Get-Content $env:USERPROFILE\.solo\logs\solo.log -Wait -Tail 50

Environment variable syntax differs. PowerShell does not use export. Set a variable for the current session, or persist it for your user:

# Current session only
$env:SOLO_LOG_LEVEL = 'debug'

# Persist for your user (all future sessions)
[System.Environment]::SetEnvironmentVariable('SOLO_LOG_LEVEL', 'debug', 'User')

Removing a variable from the current session. Use Remove-Item on the Env: drive. Setting $env:VAR = '' only blanks the value; it does not remove the variable:

Remove-Item Env:\SOLO_LOG_LEVEL

Port-forwarding fails with listen EACCES. On Windows this is usually a WinNAT reserved-port-range conflict. Solo automatically restarts the WinNAT service and retries the port-forward. If the problem persists, restart WinNAT manually from an elevated PowerShell prompt:

net stop winnat
net start winnat

Collecting diagnostic information

Before seeking help, collect the following diagnostics so issues can be reproduced and analyzed.

Solo diagnostics

  1. Capture comprehensive diagnostics for the deployment:

    solo deployment diagnostics all --deployment "${SOLO_DEPLOYMENT}"

    This creates logs and diagnostic files under ~/.solo/logs/.

Key log files

These files are often requested when reporting issues:

FileDescription
~/.solo/logs/solo.logSolo CLI command logs (human-readable, pino-pretty)
~/.solo/logs/solo.ndjsonSolo CLI command logs (machine-readable JSON, for jq)

Kubernetes diagnostics

Collect basic cluster and namespace information:

# Cluster info
kubectl cluster-info

# All resources in the Solo namespace
kubectl get all -n "${SOLO_NAMESPACE}"

# Recent events in the namespace (sorted by time)
kubectl get events -n "${SOLO_NAMESPACE}" --sort-by='.lastTimestamp'

# Node and pod resource usage
kubectl top nodes
kubectl top pods -n "${SOLO_NAMESPACE}"

Getting Help

1. Check the Logs

Always start by examining logs:

# Solo logs
cat ~/.solo/logs/solo.log | tail -100

# Pod logs
kubectl logs -n "${SOLO_NAMESPACE}" <pod-name>

2. Documentation

3. GitHub Issues

Report bugs or request features:

When opening an issue, include:

  • Solo version (solo --version)
  • Operating system and version
  • Docker/Kubernetes versions
  • Steps to reproduce the issue
  • Relevant log output
  • Any error messages

4. Community Support

Join the community for discussions and help:

4.1 - Error Codes

Complete reference for all Solo error codes, including troubleshooting steps and ownership classification.

All Solo errors carry a structured code, an ownership classification, and troubleshooting steps. Click an error code to see its dedicated page.

Configuration

CodeClassOwnershipRetryable
SOLO-1001LocalConfigNotFoundSoloErrorUserNo
SOLO-1002WriteLocalConfigFileErrorInfrastructureNo
SOLO-1003RefreshLocalConfigSourceErrorInfrastructureNo
SOLO-1004RemoteConfigsMismatchSoloErrorInfrastructureNo

Deployment

CodeClassOwnershipRetryable
SOLO-2001CreateDeploymentSoloErrorInfrastructureYes
SOLO-2002DeploymentAlreadyExistsSoloErrorUserNo
SOLO-2003DeploymentNotFoundErrorUserNo
SOLO-2004DeploymentHasRemoteResourcesErrorUserNo
SOLO-2005DeploymentDeleteFailedErrorInfrastructureYes
SOLO-2006ClusterAddFailedErrorInfrastructureYes
SOLO-2007DeploymentListFailedErrorInfrastructureYes
SOLO-2008ClusterReferenceNotFoundErrorUserNo
SOLO-2009ClusterReferenceAlreadyExistsErrorUserNo
SOLO-2010NamespaceNotSetErrorUserNo
SOLO-2011NoClustersForDeploymentErrorUserNo
SOLO-2012ClusterReferenceResolutionFailedErrorSoloNo
SOLO-2013ContextNotFoundForClusterErrorUserNo
SOLO-2014NoDeploymentsFoundErrorUserNo
SOLO-2015DeploymentListPortsFailedErrorInfrastructureYes
SOLO-2016ClusterSetupFailedSoloErrorInfrastructureNo
SOLO-2017ClusterResetFailedSoloErrorInfrastructureNo
SOLO-2018MinioInstallFailedSoloErrorInfrastructureNo
SOLO-2019PrometheusInstallFailedSoloErrorInfrastructureNo
SOLO-2020MetricsServerInstallFailedSoloErrorInfrastructureNo
SOLO-2021ClusterRoleInstallFailedSoloErrorInfrastructureNo
SOLO-2022ClusterApiServerTimeoutSoloErrorInfrastructureYes
SOLO-2023KindClusterNetworkSetupFailedSoloErrorInfrastructureNo
SOLO-2024BackupExportFailedSoloErrorInfrastructureNo
SOLO-2025BackupImportFailedSoloErrorInfrastructureNo
SOLO-2026BackupRestoreClustersFailedSoloErrorInfrastructureNo
SOLO-2027DeployNetworkFailedSoloErrorInfrastructureNo
SOLO-2028InitFailedSoloErrorInfrastructureNo
SOLO-2029BlockNodeClusterContextNotFoundSoloErrorUserNo
SOLO-2030MirrorNodeClusterContextNotFoundSoloErrorUserNo

Component

CodeClassOwnershipRetryable
SOLO-3001NodeTransactionFailedSoloErrorInfrastructureNo
SOLO-3003NodeBuildUploadFailedSoloErrorInfrastructureYes
SOLO-3004NodeBuildCopyFailedSoloErrorInfrastructureYes
SOLO-3005NodeJfrExecutionFailedSoloErrorInfrastructureYes
SOLO-3006NodeJfrPidNotFoundSoloErrorSoloNo
SOLO-3007NodeDebugArchiveFailedSoloErrorSoloNo
SOLO-3008BlockNodeConfigFailedSoloErrorInfrastructureYes
SOLO-3009ChartInstallFailedSoloErrorInfrastructureYes
SOLO-3010NetworkDestroyFailedSoloErrorInfrastructureNo
SOLO-3011NodeNotReadySoloErrorInfrastructureNo
SOLO-3012RapidFireExecutionSoloErrorInfrastructureYes
SOLO-3013NodeStakeTransactionErrorSoloErrorInfrastructureYes
SOLO-3014NodePrepareUpgradeTransactionErrorSoloErrorInfrastructureYes
SOLO-3015NodeFreezeUpgradeTransactionErrorSoloErrorInfrastructureYes
SOLO-3016NodeFreezeTransactionErrorSoloErrorInfrastructureYes
SOLO-3017NodeUpdateTransactionErrorSoloErrorInfrastructureNo
SOLO-3018NodeDeleteTransactionErrorSoloErrorInfrastructureNo
SOLO-3019NodeCreateTransactionErrorSoloErrorInfrastructureNo
SOLO-3021AccountBalanceQueryFailedSoloErrorInfrastructureYes
SOLO-3022ExplorerDeployFailedSoloErrorInfrastructureNo
SOLO-3023ExplorerUpgradeFailedSoloErrorInfrastructureNo
SOLO-3024ExplorerDestroyFailedSoloErrorInfrastructureNo
SOLO-3025RelayDeployFailedSoloErrorInfrastructureNo
SOLO-3026RelayUpgradeFailedSoloErrorInfrastructureNo
SOLO-3027RelayDestroyFailedSoloErrorInfrastructureNo
SOLO-3028RelayNotRunningSoloErrorInfrastructureYes
SOLO-3029RelayNotReadySoloErrorInfrastructureYes
SOLO-3030RelayOperatorKeyRetrievalFailedSoloErrorInfrastructureYes
SOLO-3031MirrorNodeDeployFailedSoloErrorInfrastructureNo
SOLO-3032MirrorNodeUpgradeFailedSoloErrorInfrastructureNo
SOLO-3033MirrorNodeDestroyFailedSoloErrorInfrastructureNo
SOLO-3034MirrorNodeOperatorKeyRetrievalFailedSoloErrorInfrastructureYes
SOLO-3035OneShotDeployFailedSoloErrorInfrastructureNo
SOLO-3036OneShotDestroyFailedSoloErrorInfrastructureNo
SOLO-3037OneShotDeploymentInfoRetrievalFailedSoloErrorInfrastructureNo
SOLO-3038FalconValuesPreparationFailedSoloErrorInfrastructureNo
SOLO-3039BlockNodeDeployFailedSoloErrorInfrastructureNo
SOLO-3040BlockNodeDestroyFailedSoloErrorInfrastructureNo
SOLO-3041BlockNodeUpgradeFailedSoloErrorInfrastructureNo
SOLO-3042BlockNodeAddExternalFailedSoloErrorInfrastructureNo
SOLO-3043BlockNodeDeleteExternalFailedSoloErrorInfrastructureNo
SOLO-3044BlockNodeHealthCheckFailedSoloErrorInfrastructureYes
SOLO-3045RapidFireLoadStartFailedSoloErrorInfrastructureYes
SOLO-3046RapidFireLoadStopFailedSoloErrorInfrastructureNo
SOLO-3047RapidFireKillFailedSoloErrorInfrastructureNo
SOLO-3048AccountCreationFailedSoloErrorInfrastructureNo
SOLO-3049AccountKeyUpdateFailedSoloErrorInfrastructureNo
SOLO-3050AccountKeysBatchUpdateFailedSoloErrorInfrastructureNo
SOLO-3051AccountTransferFailedSoloErrorInfrastructureNo
SOLO-3052AccountInfoFailedSoloErrorInfrastructureNo
SOLO-3053AccountUpdateFailedSoloErrorInfrastructureNo
SOLO-3054AccountSecretCreationFailedSoloErrorInfrastructureNo
SOLO-3055EvmAddressRetrievalFailedSoloErrorInfrastructureNo
SOLO-3056NodeAccessConfigFailedSoloErrorInfrastructureNo
SOLO-3057NodeClientLoadFailedSoloErrorInfrastructureNo
SOLO-3058NodeClientRefreshFailedSoloErrorInfrastructureNo
SOLO-3059NodeClientSetupFailedSoloErrorInfrastructureNo
SOLO-3060SdkPingFailedSoloErrorInfrastructureYes
SOLO-3061NodeServicesRetrievalFailedSoloErrorInfrastructureNo
SOLO-3062GossipKeySecretCreationFailedSoloErrorInfrastructureNo
SOLO-3063TlsKeySecretCreationFailedSoloErrorInfrastructureNo
SOLO-3064TlsKeyGenerationFailedSoloErrorInfrastructureNo
SOLO-3065SigningKeyGenerationFailedSoloErrorInfrastructureNo
SOLO-3066GrpcTlsKeyGenerationFailedSoloErrorInfrastructureNo
SOLO-3067GrpcTlsCertMismatchSoloErrorUserNo
SOLO-3068GrpcWebTlsCertMismatchSoloErrorUserNo
SOLO-3069CertificateSecretCreationFailedSoloErrorInfrastructureNo
SOLO-3070CertificateParsingFailedSoloErrorUserNo
SOLO-3071CertificateFileNotFoundSoloErrorUserNo
SOLO-3072ExplorerTlsSecretCreationFailedSoloErrorInfrastructureNo
SOLO-3073PlatformFileNotFoundSoloErrorInfrastructureNo
SOLO-3074PlatformFileCopyFailedSoloErrorInfrastructureNo
SOLO-3075PlatformKeyFileMissingSoloErrorInfrastructureNo
SOLO-3076GenesisAdminKeySecretFailedSoloErrorInfrastructureNo
SOLO-3077GenesisDataGenerationFailedSoloErrorInfrastructureNo
SOLO-3078PostgresInitScriptCopyFailedSoloErrorInfrastructureNo
SOLO-3079PostgresInitScriptFailedSoloErrorInfrastructureYes
SOLO-3080MirrorPasswordSecretMissingSoloErrorInfrastructureNo
SOLO-3081FileContentVerificationFailedSoloErrorInfrastructureNo
SOLO-3082HederaFileCreationFailedSoloErrorInfrastructureNo
SOLO-3083HederaFileUpdateFailedSoloErrorInfrastructureNo
SOLO-3084HederaFileAppendFailedSoloErrorInfrastructureNo
SOLO-3085NodeStatusEmptyResponseSoloErrorInfrastructureNo
SOLO-3086NodeStatusMissingLineSoloErrorInfrastructureNo
SOLO-3087PredefinedAccountsCreationFailedSoloErrorInfrastructureNo
SOLO-3088FileContentMismatchSoloErrorInfrastructureNo
SOLO-3089NodeServiceNotFoundSoloErrorUserNo
SOLO-3090BlockNodeJfrCollectionFailedSoloErrorInfrastructureYes

Validation

CodeClassOwnershipRetryable
SOLO-4001MissingArgumentErrorUserNo
SOLO-4002IllegalArgumentErrorUserNo
SOLO-4003InvalidOutputFormatErrorUserNo
SOLO-4004ConsensusNodeCountRequiredErrorUserNo
SOLO-4005InvalidPortNumberErrorUserNo
SOLO-4006LocalBuildPathNotFoundSoloErrorUserNo
SOLO-4007LocalBuildMissingSubdirectoriesSoloErrorUserNo
SOLO-4008LocalBuildNoJarFilesSoloErrorUserNo
SOLO-4009NodeJarFilesNotInContainerSoloErrorSoloNo
SOLO-4010GrpcEndpointsRequiredSoloErrorUserNo
SOLO-4011OutputDirectoryNotSpecifiedSoloErrorUserNo
SOLO-4012InputDirectoryNotSpecifiedSoloErrorUserNo
SOLO-4013WrapsKeyPathNotFoundSoloErrorUserNo
SOLO-4014ConfigFileNotFoundSoloErrorUserNo
SOLO-4015NodeVersionMismatchSoloErrorUserNo
SOLO-4016UpgradeVersionNotFoundSoloErrorUserNo
SOLO-4017PvcFlagNotEnabledSoloErrorUserNo
SOLO-4018NonInteractivePromptSoloErrorUserNo
SOLO-4020WrapsVersionConstraintSoloErrorUserNo
SOLO-4021StateFilePathNotFoundSoloErrorUserNo
SOLO-4022StateFileNotFoundSoloErrorUserNo
SOLO-4023InvalidStateFileFormatSoloErrorUserNo
SOLO-4024InvalidStateZipFileNameSoloErrorUserNo
SOLO-4025ExplorerInvalidComponentIdSoloErrorUserNo
SOLO-4026RelayInvalidComponentIdSoloErrorUserNo
SOLO-4027OneShotCachedDeploymentNotFoundSoloErrorUserNo
SOLO-4028MirrorNodeInvalidComponentIdSoloErrorUserNo
SOLO-4029BlockNodeLocalImageNotFoundSoloErrorUserNo
SOLO-4030BlockNodeInvalidComponentIdSoloErrorSoloNo
SOLO-4033InvalidHbarAmountSoloErrorUserNo
SOLO-4034InvalidFileIdFormatSoloErrorUserNo
SOLO-4035InvalidEndpointFormatSoloErrorUserNo
SOLO-4036InvalidCommaSeparatedStringSoloErrorUserNo
SOLO-4037InvalidConfigNumberValueSoloErrorUserNo
SOLO-4038InvalidStorageTypeSoloErrorUserNo
SOLO-4039UnsupportedFlagFieldTypeSoloErrorSoloNo
SOLO-4040VersionDowngradeBlockedSoloErrorUserNo
SOLO-4041AdminKeysCountMismatchSoloErrorUserNo
SOLO-4042ComponentAlreadyExistsSoloErrorSoloNo
SOLO-4043ComponentIdRequiredSoloErrorSoloNo
SOLO-4044ComponentNotFoundSoloErrorSoloNo
SOLO-4045ComponentNotInRemoteConfigSoloErrorSoloNo
SOLO-4046UnknownComponentTypeSoloErrorSoloNo
SOLO-4047ConfigFileInvalidSoloErrorUserNo
SOLO-4048MultipleClustersFoundSoloErrorUserNo
SOLO-4049CacheNotMaterializedSoloErrorUserNo
SOLO-4050CacheImageTemplateUnknownSoloErrorUserNo
SOLO-4051InvalidKindNodeImageSoloErrorUserNo
SOLO-4052PathTraversalDetectedSoloErrorUserNo
SOLO-4053NodeAliasesMustBeArraySoloErrorSoloNo
SOLO-4054UnknownNodeAliasSoloErrorUserNo
SOLO-4055NodeAliasInferenceFailedSoloErrorUserNo
SOLO-4056NodeAliasParseFailedSoloErrorUserNo
SOLO-4057DomainNameParseFailedSoloErrorUserNo
SOLO-4058UnknownTemplateDependencySoloErrorSoloNo
SOLO-4059NoConsensusNodesFoundSoloErrorUserNo
SOLO-4060ServiceTypeMismatchSoloErrorInfrastructureNo
SOLO-4061BackupConfigNotFoundSoloErrorUserNo
SOLO-4062BackupConfigInvalidSoloErrorUserNo
SOLO-4063BackupConfigReadFailedSoloErrorInfrastructureNo
SOLO-4064BackupConfigMapKeyMissingSoloErrorInfrastructureNo
SOLO-4065BackupConfigParseFailedSoloErrorInfrastructureNo
SOLO-4066BackupInputDirectoryNotFoundSoloErrorUserNo
SOLO-4067BackupNoClusterDirectoriesSoloErrorUserNo
SOLO-4068BackupClusterValidationFailedSoloErrorUserNo
SOLO-4069BackupNoClusterInfoSoloErrorUserNo
SOLO-4070BackupNoComponentsSoloErrorUserNo
SOLO-4071BackupOptionsFileNotFoundSoloErrorUserNo
SOLO-4072BackupZipFileRequiredSoloErrorUserNo
SOLO-4073BackupInputPathNotFoundSoloErrorUserNo
SOLO-4074BackupInputMustBeZipSoloErrorUserNo
SOLO-4075BackupNoLogFilesSoloErrorUserNo
SOLO-4076FlagInputFailedSoloErrorUserNo
SOLO-4077ConfirmationRequiredSoloErrorUserNo

System

CodeClassOwnershipRetryable
SOLO-5001ResourceNotFoundErrorInfrastructureNo
SOLO-5002ClusterConnectionFailedErrorInfrastructureYes
SOLO-5003PortForwardRefreshFailedErrorInfrastructureYes
SOLO-5004PortForwardStatusFailedErrorInfrastructureYes
SOLO-5005NamespaceNotFoundSoloErrorUserNo
SOLO-5006PodNotFoundSoloErrorInfrastructureYes
SOLO-5007HaproxyPodsNotFoundSoloErrorInfrastructureYes
SOLO-5008LoadBalancerNotFoundSoloErrorInfrastructureYes
SOLO-5009KubeContextNotFoundSoloErrorSoloNo
SOLO-5010ConsensusNodeNotInConfigSoloErrorSoloNo
SOLO-5011K8sSecretCreateFailedSoloErrorInfrastructureYes
SOLO-5012StatesDirectoryNotFoundSoloErrorUserNo
SOLO-5013PortForwardMissingSoloErrorInfrastructureYes
SOLO-5014NoPvcFoundSoloErrorUserNo
SOLO-5015ClusterReferenceUndeterminedSoloErrorSoloNo
SOLO-5016UpgradeVersionFetchFailedSoloErrorInfrastructureYes
SOLO-5017MultipleDeploymentsFoundSoloErrorUserNo
SOLO-5018GrpcProxyEndpointFailedSoloErrorInfrastructureYes
SOLO-5019ExplorerPodNotFoundSoloErrorInfrastructureNo
SOLO-5020ExplorerNotInRemoteConfigSoloErrorUserNo
SOLO-5021RelayPodNotFoundSoloErrorInfrastructureNo
SOLO-5022RelayNotInRemoteConfigSoloErrorUserNo
SOLO-5023MirrorNodePodsNotFoundSoloErrorInfrastructureNo
SOLO-5024MirrorIngressControllerPodNotFoundSoloErrorInfrastructureNo
SOLO-5025MirrorNodeNotInRemoteConfigSoloErrorUserNo
SOLO-5026ClusterNotFoundInRemoteConfigSoloErrorUserNo
SOLO-5027GitHubApiRequestFailedErrorInfrastructureYes
SOLO-5028GitHubApiHttpResponseErrorInfrastructureYes
SOLO-5029GitHubApiResponseParseFailedErrorInfrastructureNo
SOLO-5030GitHubApiResponseMissingTagNameErrorInfrastructureNo
SOLO-5031BlockNodePodNotFoundSoloErrorInfrastructureYes
SOLO-5032BlockNodeNotReadySoloErrorInfrastructureYes
SOLO-5033BlockNodeNotInRemoteConfigSoloErrorUserNo
SOLO-5034ExternalBlockNodeNotInRemoteConfigSoloErrorUserNo
SOLO-5035HelmRepoSetupFailedSoloErrorInfrastructureNo
SOLO-5036HelmRepoCheckFailedSoloErrorInfrastructureNo
SOLO-5037HelmChartListFailedSoloErrorInfrastructureNo
SOLO-5038HelmChartGenericInstallFailedSoloErrorInfrastructureNo
SOLO-5039HelmChartUninstallFailedSoloErrorInfrastructureNo
SOLO-5040HelmChartUpgradeFailedSoloErrorInfrastructureNo
SOLO-5041FileNotFoundSoloErrorUserNo
SOLO-5042FileCopyFailedSoloErrorInfrastructureNo
SOLO-5043FileEmptySoloErrorUserNo
SOLO-5044FileInvalidJsonSoloErrorUserNo
SOLO-5045DirectoryCreationFailedSoloErrorInfrastructureNo
SOLO-5046ArchiveUnzipFailedSoloErrorInfrastructureNo
SOLO-5047ArchiveTarFailedSoloErrorInfrastructureNo
SOLO-5048ArchiveUntarFailedSoloErrorInfrastructureNo
SOLO-5049DependencyVersionCheckFailedSoloErrorInfrastructureNo
SOLO-5050DependencyNotFoundSoloErrorInfrastructureNo
SOLO-5051DependencyManagerNotFoundSoloErrorSoloNo
SOLO-5052DependencyInstallFailedSoloErrorInfrastructureNo
SOLO-5053DependencyInstallDirectoryConflictSoloErrorUserNo
SOLO-5054GitHubReleasesNotFoundSoloErrorInfrastructureYes
SOLO-5055GitHubReleaseTagNotFoundSoloErrorInfrastructureNo
SOLO-5056GitHubReleaseAssetNotFoundSoloErrorInfrastructureNo
SOLO-5057HomebrewInstallFailedSoloErrorInfrastructureNo
SOLO-5058PodmanMachineInspectFailedSoloErrorInfrastructureNo
SOLO-5059DockerAuthStaleSoloErrorUserNo
SOLO-5060PvcCreationFailedSoloErrorInfrastructureNo
SOLO-5061KubernetesApiInvalidResponseSoloErrorInfrastructureNo
SOLO-5062IngressClassListFailedSoloErrorInfrastructureNo
SOLO-5063MultipleItemsFoundSoloErrorSoloNo
SOLO-5064PodCreationFailedSoloErrorInfrastructureNo
SOLO-5065PackageDownloadFailedSoloErrorInfrastructureYes
SOLO-5066ChecksumReadFailedSoloErrorInfrastructureNo
SOLO-5067ContainerInvalidPathSoloErrorSoloNo
SOLO-5068ContainerOperationFailedSoloErrorInfrastructureNo
SOLO-5069PostgresPodNotFoundSoloErrorInfrastructureNo
SOLO-5070InitSystemFilesFailedSoloErrorInfrastructureNo
SOLO-5071CacheProviderNotConfiguredSoloErrorSoloNo
SOLO-5072PodTerminationTimeoutSoloErrorInfrastructureYes
SOLO-5073ClusterRoleCheckFailedSoloErrorInfrastructureNo
SOLO-5074UnsupportedLinuxDistributionSoloErrorInfrastructureNo
SOLO-5075BlockNodesJsonEmptySoloErrorUserNo
SOLO-9001TimeoutSoloErrorInfrastructureYes

Internal

CodeClassOwnershipRetryable
SOLO-9002UnsupportedOperationErrorSoloNo
SOLO-9003ReadRemoteConfigBeforeLoadErrorSoloNo
SOLO-9004WriteRemoteConfigBeforeLoadErrorSoloNo
SOLO-9005DataValidationErrorSoloNo
SOLO-9006LoggerMessageGroupNotFoundErrorSoloNo
SOLO-9007CommandReturnedFalseErrorSoloNo
SOLO-9008RemoteConfigUnsupportedComponentErrorSoloNo
SOLO-9009RemoteConfigDeploymentNotSetErrorSoloNo
SOLO-9010RemoteConfigContextUnavailableErrorSoloNo
SOLO-9011CacheImageTemplateUndeclaredErrorSoloNo
SOLO-9012InjectedFailureSoloErrorSoloNo

4.1.1 - Configuration

4.1.1.1 - SOLO-1001

LocalConfigNotFoundSoloError — Configuration

LocalConfigNotFoundSoloError

CodeSOLO-1001
CategoryConfiguration
OwnershipUser
RetryableNo

Description

Thrown when solo reads its local configuration but no file exists at the resolved path (~/.solo/local-config.yaml, or $SOLO_HOME/local-config.yaml when SOLO_HOME is set). The local config records cluster references, deployments, and the active user context, so most commands load it before doing any work. The file is missing because solo init has not yet run on this machine, because SOLO_HOME points at a different directory than the one the file was created in, or because it was manually moved or deleted.

Troubleshooting Steps

  1. Create a local config: solo deployment config create –deployment –namespace

4.1.1.2 - SOLO-1002

WriteLocalConfigFileError — Configuration

WriteLocalConfigFileError

CodeSOLO-1002
CategoryConfiguration
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot persist the local configuration to disk at ~/.solo/local-config.yaml (or $SOLO_HOME/local-config.yaml). The local config is rewritten whenever solo records a new cluster reference, deployment, or context, and this error wraps the underlying filesystem failure (cause). It means the data was prepared but could not be written: typical causes are missing write permissions on the ~/.solo directory, a read-only or full disk, or a parent directory that is missing or locked.

Troubleshooting Steps

  1. Check file system permissions for ~/.solo

4.1.1.3 - SOLO-1003

RefreshLocalConfigSourceError — Configuration

RefreshLocalConfigSourceError

CodeSOLO-1003
CategoryConfiguration
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo fails to reload the local configuration from its on-disk source — that is, the re-read and re-parse of ~/.solo/local-config.yaml (or $SOLO_HOME/local-config.yaml) did not complete; the underlying failure is wrapped in cause. Unlike LocalConfigNotFoundSoloError, the file is present: it could not be read (insufficient permissions, an I/O error) or its contents could not be parsed into the expected configuration because the file is malformed or corrupt.

Troubleshooting Steps

  1. Check file system permissions for ~/.solo
  2. Verify the config file exists: solo deployment config info

4.1.1.4 - SOLO-1004

RemoteConfigsMismatchSoloError — Configuration

RemoteConfigsMismatchSoloError

CodeSOLO-1004
CategoryConfiguration
OwnershipInfrastructure
RetryableNo

Description

Thrown when a deployment spans multiple clusters and solo finds that the remote configuration stored in two of them does not agree; the message names the two clusters whose copies diverged. solo keeps the remote config as a ConfigMap that must be an identical replica in every cluster of the deployment, so it compares them and raises this when they differ. The usual cause is a prior write that was applied to one cluster but not the others (a partial or failed update), a ConfigMap that was edited manually, or clusters that have otherwise drifted out of sync.

Troubleshooting Steps

  1. Inspect both configs: kubectl get configmap -n
  2. Sync manually before retrying

4.1.2 - Deployment

4.1.2.1 - SOLO-2001

CreateDeploymentSoloError — Deployment

CreateDeploymentSoloError

CodeSOLO-2001
CategoryDeployment
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo deployment config create cannot record a new deployment; the underlying failure is wrapped in cause. Creating a deployment writes its entry to the local configuration and provisions the associated namespace, so this is raised when that work fails — for example the local config could not be written, or the Kubernetes API rejected or could not create the namespace. It is retryable because a transient cluster or filesystem issue often clears on a second attempt.

Troubleshooting Steps

  1. Check the logs for details: tail -n 100 ~/.solo/logs/solo.log

4.1.2.2 - SOLO-2002

DeploymentAlreadyExistsSoloError — Deployment

DeploymentAlreadyExistsSoloError

CodeSOLO-2002
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when solo deployment config create is asked to create a deployment whose name is already present in the local configuration; the message names the conflicting deployment. Deployment names must be unique because solo keys each deployment’s namespace and cluster references by name, so it refuses to overwrite an existing entry. Choose a different name, or operate on the existing deployment instead of recreating it.

Troubleshooting Steps

  1. Check existing deployments: solo deployment config list
  2. Choose a different name for your deployment

4.1.2.3 - SOLO-2003

DeploymentNotFoundError — Deployment

DeploymentNotFoundError

CodeSOLO-2003
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when a command resolves a deployment by name but that name is not registered in the local configuration; the error message names the deployment that was requested. solo looks the deployment up to find its namespace and cluster references before acting, so the lookup fails when the --deployment value is misspelled, when the deployment was never created with solo deployment config create, or when it was removed by a prior delete. It can also surface after switching SOLO_HOME to a config that does not contain the deployment.

Troubleshooting Steps

  1. List available deployments: solo deployment config list
  2. Create a deployment if needed: solo deployment config create

4.1.2.4 - SOLO-2004

DeploymentHasRemoteResourcesError — Deployment

DeploymentHasRemoteResourcesError

CodeSOLO-2004
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when a deployment is deleted while it still has live components running in one of its clusters; the message names the deployment and the clusterReference where resources remain. Before removing a deployment’s local entry, solo checks each attached cluster and refuses to proceed if it still hosts components (mirror node, relay, explorer, block node, or the consensus network), since deleting the entry would orphan those running workloads. Destroy the components first, then delete the deployment.

Troubleshooting Steps

  1. Destroy all components in the deployment before deleting it:
  2. solo mirror node destroy
  3. solo relay node destroy
  4. solo explorer node destroy
  5. solo block node destroy
  6. solo consensus network destroy

4.1.2.5 - SOLO-2005

DeploymentDeleteFailedError — Deployment

DeploymentDeleteFailedError

CodeSOLO-2005
CategoryDeployment
OwnershipInfrastructure
RetryableYes

Description

Thrown when removing a deployment fails; the underlying failure is wrapped in cause. Deleting a deployment removes its entry from the local configuration and may reach into each attached cluster to clean up, so this is raised when that work cannot complete — most often because one of the deployment’s cluster references or its kubeconfig context is invalid or unreachable. It is retryable, since a transient connectivity problem often clears on a later attempt once the contexts are reachable again.

Troubleshooting Steps

  1. Check logs for details: tail -n 100 ~/.solo/logs/solo.log
  2. Verify cluster references and their contexts are valid: solo cluster-ref config list

4.1.2.6 - SOLO-2006

ClusterAddFailedError — Deployment

ClusterAddFailedError

CodeSOLO-2006
CategoryDeployment
OwnershipInfrastructure
RetryableYes

Description

Thrown when attaching a cluster to a deployment fails; the underlying failure is wrapped in cause. Attaching binds a registered cluster reference (and its kubeconfig context) to the deployment so components can be placed there, so this is raised when that step cannot complete — commonly because the cluster reference has not been created/connected yet, the kubeconfig context does not exist, or the cluster is unreachable. It is retryable, since a transient connectivity issue often clears once the reference and context are valid.

Troubleshooting Steps

  1. Verify the cluster context exists: kubectl config get-contexts
  2. Make sure the cluster reference is created: cluster-ref config connect
  3. Check logs for details: tail -n 100 ~/.solo/logs/solo.log

4.1.2.7 - SOLO-2007

DeploymentListFailedError — Deployment

DeploymentListFailedError

CodeSOLO-2007
CategoryDeployment
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo deployment config list cannot enumerate the configured deployments; the underlying failure is wrapped in cause. Listing reads the deployment entries from the local configuration and may consult the clusters they reference, so this is raised when that read fails — for example the local config could not be read or parsed, or a referenced cluster could not be queried. It is retryable because transient filesystem or cluster issues often resolve on a later attempt.

Troubleshooting Steps

  1. Check logs for details: tail -n 100 ~/.solo/logs/solo.log

4.1.2.8 - SOLO-2008

ClusterReferenceNotFoundError — Deployment

ClusterReferenceNotFoundError

CodeSOLO-2008
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when a command refers to a cluster reference that is not registered in the local configuration; the message names the missing reference. A cluster reference is the named link between solo and a kubeconfig context, created with solo cluster-ref config connect, so this is raised when the supplied name was never connected, was misspelled, or was disconnected. Connect the cluster reference (or correct the name) before retrying.

Troubleshooting Steps

  1. List available cluster references: solo cluster-ref config list
  2. Connect a cluster: solo cluster-ref config connect

4.1.2.9 - SOLO-2009

ClusterReferenceAlreadyExistsError — Deployment

ClusterReferenceAlreadyExistsError

CodeSOLO-2009
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when a cluster reference that is already attached to the deployment is added again; the message names the duplicate reference. solo keeps each cluster reference attached to a deployment at most once, so it rejects a second add rather than creating a conflicting duplicate entry. If you intend to re-add it (for example to change its binding), disconnect it first and then connect it again.

Troubleshooting Steps

  1. List current cluster references: solo cluster-ref config list
  2. Disconnect it first if you want to re-add it: solo cluster-ref config disconnect

4.1.2.10 - SOLO-2010

NamespaceNotSetError — Deployment

NamespaceNotSetError

CodeSOLO-2010
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when a command needs a target Kubernetes namespace but none could be resolved. solo determines the namespace from the --namespace flag or from the selected deployment’s configuration, so this is raised when neither is available — the flag was not passed and the deployment has no namespace recorded. Supply --namespace, or select a deployment whose configuration defines one.

Troubleshooting Steps

  1. Ensure a namespace is specified: pass –namespace to your command
  2. Check deployment config: solo deployment config info –deployment

4.1.2.11 - SOLO-2011

NoClustersForDeploymentError — Deployment

NoClustersForDeploymentError

CodeSOLO-2011
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when an operation targets a deployment that has no clusters attached; the message names the deployment. A deployment must have at least one cluster reference attached before solo can place or manage its components, so this is raised when the deployment exists but its cluster list is empty — typically because solo deployment cluster attach has not yet been run for it. Attach a cluster to the deployment before retrying.

Troubleshooting Steps

  1. Attach a cluster to the deployment: solo deployment cluster attach –deployment

4.1.2.12 - SOLO-2012

ClusterReferenceResolutionFailedError — Deployment

ClusterReferenceResolutionFailedError

CodeSOLO-2012
CategoryDeployment
OwnershipSolo
RetryableNo

Description

Thrown when solo cannot resolve which cluster reference a deployment should use; the message names the deployment. Internally a command expected the deployment to yield a single, unambiguous cluster reference (so it knows where to act) but the resolution returned nothing usable. While an unattached deployment is the visible trigger, this is classified as a Solo-owned error because the calling code should have ensured a cluster was attached before reaching this point — it points to a missing precondition in solo’s flow.

Troubleshooting Steps

  1. Verify the deployment has clusters attached: solo deployment config info
  2. Attach the cluster reference to the deployment: solo deployment cluster attach

4.1.2.13 - SOLO-2013

ContextNotFoundForClusterError — Deployment

ContextNotFoundForClusterError

CodeSOLO-2013
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when a cluster reference exists in the local configuration but has no kubeconfig context bound to it; the message names the cluster reference. solo needs the context to know which cluster the reference points at, so this is raised when the mapping is missing — usually because the reference was recorded without being connected to a context, or the binding was removed. Connect a kubeconfig context to the cluster reference before retrying.

Troubleshooting Steps

  1. Connect a kubeconfig context to the cluster: solo cluster-ref config connect

4.1.2.14 - SOLO-2014

NoDeploymentsFoundError — Deployment

NoDeploymentsFoundError

CodeSOLO-2014
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when a command needs at least one deployment to act on but the local configuration contains none. solo stores every deployment in local config and several commands assume one already exists, so this is raised when that list is empty — typically because no deployment has been created yet, or because they were all deleted (or the active SOLO_HOME/local config does not contain any). Create a deployment before running the command.

Troubleshooting Steps

  1. Create a deployment: solo deployment config create

4.1.2.15 - SOLO-2015

DeploymentListPortsFailedError — Deployment

DeploymentListPortsFailedError

CodeSOLO-2015
CategoryDeployment
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot enumerate the forwarded ports for a deployment; the underlying failure is wrapped in cause. Listing ports queries the Kubernetes API in the deployment’s namespace to discover the active port-forwards exposing its components, so this is raised when that query fails — typically because the cluster’s API server is unreachable or the namespace cannot be inspected. It is retryable, as a transient connectivity problem often clears on a later attempt.

Troubleshooting Steps

  1. Check logs for details: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the Kubernetes API server is reachable: kubectl cluster-info
  3. List port-forwards in the namespace to check for any issues: kubectl get port-forwards -n

4.1.2.16 - SOLO-2016

ClusterSetupFailedSoloError — Deployment

ClusterSetupFailedSoloError

CodeSOLO-2016
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cluster-ref config setup cannot install the cluster-level shared infrastructure that deployments depend on — the solo-cluster-setup chart and its components (Prometheus, MinIO, metrics-server, and the cluster role). It wraps the underlying failure (cause.message), which is most often a failed Helm release (bad chart version or values), an image that cannot be pulled, missing RBAC permissions on the target cluster, or a cluster that lacks the CPU/memory to schedule the new pods.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List installed Helm releases: helm list -A
  3. Inspect cluster pods: kubectl get pods -A
  4. Re-run cluster setup: solo cluster-ref config setup

4.1.2.17 - SOLO-2017

ClusterResetFailedSoloError — Deployment

ClusterResetFailedSoloError

CodeSOLO-2017
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cluster-ref config reset cannot tear down the cluster-level resources that setup installed (the solo-cluster-setup chart and its components); the underlying failure is wrapped in cause. It means the uninstall did not complete cleanly — for example a Helm release could not be removed, or the cluster API was unreachable mid-reset — so some resources may still be present. Inspect the remaining Helm releases and pods to see what was left behind.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect cluster state: kubectl get pods -A
  3. Check Helm releases still present: helm list -A
  4. Re-run cluster reset: solo cluster-ref config reset

4.1.2.18 - SOLO-2018

MinioInstallFailedSoloError — Deployment

MinioInstallFailedSoloError

CodeSOLO-2018
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown during cluster setup when the MinIO Operator Helm chart fails to install; the underlying failure is wrapped in cause. MinIO provides the S3-compatible object storage that solo’s cluster-level stack relies on, so its install is part of solo cluster-ref config setup. The failure is usually a Helm error (bad chart version or values), an image that cannot be pulled, or a cluster lacking the resources/connectivity to schedule the operator.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect cluster state: kubectl get pods -A
  3. Check Helm release status: helm list -A
  4. Verify cluster connectivity: kubectl cluster-info

4.1.2.19 - SOLO-2019

PrometheusInstallFailedSoloError — Deployment

PrometheusInstallFailedSoloError

CodeSOLO-2019
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown during cluster setup when the Prometheus stack Helm chart fails to install; the underlying failure is wrapped in cause. The Prometheus stack supplies the monitoring and metrics collection for the cluster-level stack installed by solo cluster-ref config setup. The failure is typically a Helm error (bad chart version or values), an image that cannot be pulled, or a cluster without the resources/connectivity to schedule its pods.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect cluster pods: kubectl get pods -A
  3. Check Helm release status: helm list -A
  4. Verify cluster connectivity: kubectl cluster-info

4.1.2.20 - SOLO-2020

MetricsServerInstallFailedSoloError — Deployment

MetricsServerInstallFailedSoloError

CodeSOLO-2020
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown during cluster setup when the metrics-server Helm chart fails to install; the underlying failure is wrapped in cause. metrics-server provides the resource-usage metrics API the cluster-level stack depends on, installed as part of solo cluster-ref config setup. The failure is usually a Helm error (bad chart version or values), an image that cannot be pulled, or a cluster lacking the resources/connectivity to schedule the pod.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect cluster pods: kubectl get pods -A
  3. Check Helm release status: helm list -A
  4. Verify cluster connectivity: kubectl cluster-info

4.1.2.21 - SOLO-2021

ClusterRoleInstallFailedSoloError — Deployment

ClusterRoleInstallFailedSoloError

CodeSOLO-2021
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown during cluster setup when the pod-monitor-role ClusterRole cannot be installed; the underlying failure is wrapped in cause. This ClusterRole grants the monitoring stack permission to scrape pods cluster-wide, so it is created as part of solo cluster-ref config setup. The failure most often means the current kubeconfig user lacks the RBAC permission to create ClusterRoles, but it can also stem from an API server that is unreachable or rejected the request.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify RBAC permissions: kubectl get clusterroles
  3. Inspect cluster state: kubectl get pods -A

4.1.2.22 - SOLO-2022

ClusterApiServerTimeoutSoloError — Deployment

ClusterApiServerTimeoutSoloError

CodeSOLO-2022
CategoryDeployment
OwnershipInfrastructure
RetryableYes

Description

Thrown when a cluster’s Kubernetes API server does not become ready within the allowed number of attempts; the message names the context and the maxAttempts tried, and wraps the last failure in cause. solo polls the API server before proceeding so it does not act against a cluster that is still starting, and raises this once polling is exhausted. It is retryable because a cluster that is merely slow to come up (for example a Kind cluster still initialising) often becomes ready shortly after; a persistent failure points to a cluster that is down, unreachable, or pointed at by the wrong context.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the cluster context is reachable: kubectl cluster-info –context
  3. Check cluster node status: kubectl get nodes
  4. Inspect cluster pods: kubectl get pods -A

4.1.2.23 - SOLO-2023

KindClusterNetworkSetupFailedSoloError — Deployment

KindClusterNetworkSetupFailedSoloError

CodeSOLO-2023
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot configure networking for a Kind cluster — either the Kind network setup itself or the MetalLB Helm repository configuration it depends on; the underlying failure is wrapped in cause. solo configures MetalLB so that LoadBalancer services in the local Kind cluster receive reachable addresses, and raises this when that setup fails. Common roots are Docker not running (Kind needs it), an unreachable or misconfigured Helm repository, or a problem with the Kind cluster’s Docker network.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Docker is running: docker ps
  3. Check existing Kind clusters: kind get clusters
  4. Verify Helm repository access: helm repo list

4.1.2.24 - SOLO-2024

BackupExportFailedSoloError — Deployment

BackupExportFailedSoloError

CodeSOLO-2024
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown during solo config ops backup when a particular resource cannot be exported into the backup; the message names the resourceType and wraps the underlying failure in cause. Backup reads each resource from the cluster and writes it to the backup archive, so this is raised when reading a resource or writing it out fails — for example the Kubernetes API is unreachable, the deployment or resource no longer exists, or the archive destination cannot be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Kubernetes connectivity: kubectl get pods -A
  3. Check that the deployment exists: solo deployment config list
  4. Run backup again: solo config ops backup

4.1.2.25 - SOLO-2025

BackupImportFailedSoloError — Deployment

BackupImportFailedSoloError

CodeSOLO-2025
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown during solo config ops restore-config when a particular resource cannot be imported from a backup; the message names the resourceType and wraps the underlying failure in cause. Restore reads each resource from the backup archive and applies it to the cluster, so this is raised when reading the archive entry or applying it fails — for example the backup archive is incomplete or corrupt, the resource is invalid, or the Kubernetes API is unreachable or rejected it.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Kubernetes connectivity: kubectl get pods -A
  3. Verify the backup archive is complete and valid
  4. Run restore: solo config ops restore-config

4.1.2.26 - SOLO-2026

BackupRestoreClustersFailedSoloError — Deployment

BackupRestoreClustersFailedSoloError

CodeSOLO-2026
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo config ops restore-clusters cannot recreate the clusters captured in a backup; the underlying failure is wrapped in cause. This step reads the backup archive and rebuilds the cluster(s) it describes (for example recreating a Kind cluster) before the rest of a restore can proceed, so the error means that rebuild failed. Common roots are an invalid or incomplete backup archive, an incorrect input directory, or Docker/Kind not being available to create the clusters.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the backup archive is valid and the input directory is correct
  3. Check Docker or Kind cluster availability: kind get clusters
  4. Run cluster restore: solo config ops restore-clusters

4.1.2.27 - SOLO-2027

DeployNetworkFailedSoloError — Deployment

DeployNetworkFailedSoloError

CodeSOLO-2027
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo consensus network deploy cannot bring up the consensus network; the underlying failure is wrapped in cause. This step installs the solo-deployment Helm chart that creates the consensus node pods and their supporting services, so the error means that install did not succeed. Typical roots are a Helm release failure (bad chart version or values), an image that cannot be pulled, insufficient cluster resources to schedule the nodes, or a loss of connectivity to the cluster during the deploy.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect consensus node pods: kubectl get pods -A
  3. Check Helm release status: helm list -A
  4. Verify cluster connectivity: kubectl cluster-info

4.1.2.28 - SOLO-2028

InitFailedSoloError — Deployment

InitFailedSoloError

CodeSOLO-2028
CategoryDeployment
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo init cannot complete the one-time setup it performs before other commands can run; when a cause is available its message is appended. solo init prepares the local environment — creating the ~/.solo working directory and verifying or installing the required external tools (kubectl, helm, kind, docker). This error means one of those steps failed, most often because a prerequisite is missing or could not be installed, or the working directory could not be created.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify all prerequisites are installed (kubectl, helm, kind, docker)
  3. Re-run initialization: solo init

4.1.2.29 - SOLO-2029

BlockNodeClusterContextNotFoundSoloError — Deployment

BlockNodeClusterContextNotFoundSoloError

CodeSOLO-2029
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when solo needs to act on a block node but cannot determine which cluster (kubeconfig context) it lives in; the message names the blockNodeId. solo maps each block node to a registered cluster reference to find the context for its operations, so this is raised when no such mapping resolves — typically because the block node is not associated with a registered cluster reference, or the referenced cluster is missing from the deployment configuration.

Troubleshooting Steps

  1. List registered cluster references: solo cluster-ref config list
  2. Verify the block node is associated with a registered cluster
  3. Check deployment configuration: solo deployment config info

4.1.2.30 - SOLO-2030

MirrorNodeClusterContextNotFoundSoloError — Deployment

MirrorNodeClusterContextNotFoundSoloError

CodeSOLO-2030
CategoryDeployment
OwnershipUser
RetryableNo

Description

Thrown when solo needs to act on a mirror node but cannot determine which cluster (kubeconfig context) it lives in; the message names the mirrorNodeId. solo maps each mirror node to a registered cluster reference to find the context for its operations, so this is raised when no such mapping resolves — typically because the mirror node is not associated with a registered cluster reference, or the referenced cluster is missing from the deployment configuration.

Troubleshooting Steps

  1. List registered cluster references: solo cluster-ref config list
  2. Verify the mirror node is associated with a registered cluster
  3. Check deployment configuration: solo deployment config info

4.1.3 - Component

4.1.3.1 - SOLO-3001

NodeTransactionFailedSoloError — Component

NodeTransactionFailedSoloError

CodeSOLO-3001
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a Hedera SDK transaction that solo submitted to a consensus node receives a receipt whose status is not SUCCESS. The error message carries the operation that failed and the raw network status code (for example node create transaction failed with status: INVALID_SIGNATURE). This means the network reached and rejected the transaction rather than failing to deliver it: common causes are a node that has not yet reached ACTIVE during setup, staking, or a network upgrade; an operator/admin key that does not match the account; or an address-book/state precondition that the transaction violated. The specific status code identifies which.

Troubleshooting Steps

  1. Check the solo logs for details: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the node pod is running: kubectl get pods -n -l solo.hedera.com/type=network-node
  3. Consult the Hedera documentation for the meaning of the status code

4.1.3.2 - SOLO-3003

NodeBuildUploadFailedSoloError — Component

NodeBuildUploadFailedSoloError

CodeSOLO-3003
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot upload the build.zip artifact; the underlying failure is wrapped in cause. solo uploads the packaged build so nodes can be provisioned from it, so this means the upload failed — for example the source file was missing or unreadable, or the destination was unreachable. It is retryable.

Troubleshooting Steps

  1. Review solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check node pod status: kubectl get pods -n -l solo.hedera.com/type=network-node
  3. Inspect the pod for more detail: kubectl describe pod -n

4.1.3.3 - SOLO-3004

NodeBuildCopyFailedSoloError — Component

NodeBuildCopyFailedSoloError

CodeSOLO-3004
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot copy a local build into a consensus node; the underlying failure is wrapped in cause. When running with a local platform build, solo copies the build artifacts into the node pod, so this means that copy failed — for example the pod was not reachable, the destination path was not writable, or the connection dropped mid-copy. It is retryable.

Troubleshooting Steps

  1. Check pod status: kubectl get pods -n -l solo.hedera.com/type=network-node
  2. Verify the local build path is valid and readable
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.4 - SOLO-3005

NodeJfrExecutionFailedSoloError — Component

NodeJfrExecutionFailedSoloError

CodeSOLO-3005
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a Java Flight Recorder (JFR) operation on a consensus node pod fails; the message names the operation and the pod. solo runs JFR commands inside the node container to capture profiling data, so this means that command failed — for example the pod was not reachable or the command returned an error. It is retryable.

Troubleshooting Steps

  1. Check if the node pod is running: kubectl get pod -n
  2. Verify the pod has jcmd available: kubectl exec -n – which jcmd
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.5 - SOLO-3006

NodeJfrPidNotFoundSoloError — Component

NodeJfrPidNotFoundSoloError

CodeSOLO-3006
CategoryComponent
OwnershipSolo
RetryableNo

Description

Thrown when solo cannot find the ServicesMain process id inside a consensus node pod; the message names the pod. JFR profiling must attach to the running node process, so this is raised when that process cannot be located — which points to an unexpected container state or a defect in how solo locates the process, and is treated as an internal Solo error.

Troubleshooting Steps

  1. Verify the consensus node is running inside the pod: kubectl exec – ps axww -o pid,command
  2. Check node startup logs: kubectl logs -n
  3. Restart the node if ServicesMain is absent: solo consensus node restart

4.1.3.6 - SOLO-3007

NodeDebugArchiveFailedSoloError — Component

NodeDebugArchiveFailedSoloError

CodeSOLO-3007
CategoryComponent
OwnershipSolo
RetryableNo

Description

Thrown when solo cannot create the debug archive it assembles for troubleshooting; the underlying failure is wrapped in cause. The archive bundles a node’s logs and diagnostic data, and reaching this failure points to a problem in solo’s archive-creation logic rather than user or infrastructure input, so it is treated as an internal Solo error and should be reported with the full error output.

Troubleshooting Steps

  1. Verify the output directory is writable
  2. Check available disk space: df -h
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.7 - SOLO-3008

BlockNodeConfigFailedSoloError — Component

BlockNodeConfigFailedSoloError

CodeSOLO-3008
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo fails while building the block-nodes configuration; the underlying failure is wrapped in cause. solo generates the configuration that tells consensus nodes how to reach the block nodes, so this means that generation step failed — for example required connection details could not be resolved. It is retryable, since a transient resolution problem often clears on a later attempt.

Troubleshooting Steps

  1. Check block node pod status: kubectl get pods -n -l block-node.hiero.com/type=block-node
  2. Check network node pod status: kubectl get pods -n -l solo.hedera.com/type=network-node
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log
  4. Verify the cluster is reachable: kubectl cluster-info –context

4.1.3.8 - SOLO-3009

ChartInstallFailedSoloError — Component

ChartInstallFailedSoloError

CodeSOLO-3009
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot install a Helm chart; the message names the chart and wraps the underlying failure in cause. solo installs charts to deploy its components, so this means the Helm install failed — for example a bad chart version or values, an image that cannot be pulled, or a cluster that is unreachable or short on resources. It is retryable, since transient registry or cluster issues often clear on a later attempt.

Troubleshooting Steps

  1. Check Helm release status: helm list -n
  2. Review Helm errors: helm status -n
  3. Verify the cluster is reachable: kubectl cluster-info –context
  4. Retry after inspecting solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.9 - SOLO-3010

NetworkDestroyFailedSoloError — Component

NetworkDestroyFailedSoloError

CodeSOLO-3010
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo consensus network destroy cannot tear down the consensus network; the underlying failure is wrapped in cause. Destroy uninstalls the network Helm release and removes its consensus node pods and resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

  1. Check remaining Helm releases: helm list -A
  2. Check for stuck namespaces: kubectl get namespaces
  3. Manually clean up: helm uninstall -n
  4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.10 - SOLO-3011

NodeNotReadySoloError — Component

NodeNotReadySoloError

CodeSOLO-3011
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a consensus node does not reach the expected status within the allotted polling attempts; the message names the node alias, the expected status, and the attempt count (attempt/maxAttempts). solo polls node status while waiting for nodes to come up or change state, and raises this once the attempts are exhausted without the node reaching the expected status — for example the node is crash-looping, stuck during startup, or unable to join the network.

Troubleshooting Steps

  1. Check node pod status: kubectl get pods -n -l solo.hedera.com/node-name=
  2. View node logs: kubectl logs -n -l solo.hedera.com/node-name=
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.11 - SOLO-3012

RapidFireExecutionSoloError — Component

RapidFireExecutionSoloError

CodeSOLO-3012
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a rapid-fire load test step fails to execute; the message describes the failing step and, when present, wraps the underlying cause. Rapid-fire runs load against the network, so this means one of its execution steps did not succeed. It is retryable, since transient cluster or network issues during the test often clear on a later attempt.

Troubleshooting Steps

  1. Check NLG pod logs for TPS output and errors: kubectl logs -n -l app.kubernetes.io/instance=network-load-generator
  2. Retry with lower load parameters or a reduced –max-tps value

4.1.3.12 - SOLO-3013

NodeStakeTransactionErrorSoloError — Component

NodeStakeTransactionErrorSoloError

CodeSOLO-3013
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a staking transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits staking transactions to configure how accounts and nodes stake, so this means the transaction was rejected or could not be submitted. It is retryable, since a transient network or node-readiness issue often clears on a later attempt.

Troubleshooting Steps

  1. Verify the treasury account has sufficient HBAR balance.
  2. Confirm the node is in ACTIVE status: kubectl get pods -n -l solo.hedera.com/type=network-node
  3. Check gRPC connectivity to the consensus node.
  4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.13 - SOLO-3014

NodePrepareUpgradeTransactionErrorSoloError — Component

NodePrepareUpgradeTransactionErrorSoloError

CodeSOLO-3014
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when the prepare-upgrade transaction fails to execute; when available the underlying failure is wrapped in cause. This transaction stages the upgrade artifacts on the network before a freeze-upgrade, so this means staging was rejected or could not be submitted — for example the upgrade file was not present or valid, or the network could not be reached. It is retryable.

Troubleshooting Steps

  1. Verify the node admin key is correct and loaded from the k8s secret.
  2. Confirm the freeze admin account has sufficient HBAR balance.
  3. Verify the upgrade zip file hash is correct.
  4. Check node client connection to the consensus network.
  5. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.14 - SOLO-3015

NodeFreezeUpgradeTransactionErrorSoloError — Component

NodeFreezeUpgradeTransactionErrorSoloError

CodeSOLO-3015
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a freeze-upgrade transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits this transaction to freeze the network in preparation for a software upgrade, so this means it was rejected or could not be submitted — for example the prepared upgrade was not staged, the admin key did not sign, or the network could not be reached. It is retryable.

Troubleshooting Steps

  1. Verify the node admin key is correct and loaded from the k8s secret.
  2. Confirm the freeze admin account has sufficient HBAR balance.
  3. Verify the nodes have completed the prepare upgrade step.
  4. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
  5. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.15 - SOLO-3016

NodeFreezeTransactionErrorSoloError — Component

NodeFreezeTransactionErrorSoloError

CodeSOLO-3016
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a freeze-only transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a freeze-only transaction to pause the network (for example before maintenance), so this means the transaction was rejected or could not be submitted. It is retryable, since a transient network or node-readiness problem often clears on a later attempt.

Troubleshooting Steps

  1. Verify the node admin key is correct and loaded from the k8s secret.
  2. Confirm the freeze admin account has the correct operator key set.
  3. Verify the freeze admin account has sufficient HBAR balance.
  4. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
  5. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.16 - SOLO-3017

NodeUpdateTransactionErrorSoloError — Component

NodeUpdateTransactionErrorSoloError

CodeSOLO-3017
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when the node-update transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a node-update transaction to change a consensus node’s address-book entry (keys or endpoints), so this means the transaction was rejected or could not be submitted — for example the signing key was wrong, the updated values were invalid, or the network could not be reached.

Troubleshooting Steps

  1. Verify the node admin key is correct and loaded from the k8s secret.
  2. Confirm the node client is connected to the consensus network.
  3. Check if the new account number is valid and funded.
  4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.17 - SOLO-3018

NodeDeleteTransactionErrorSoloError — Component

NodeDeleteTransactionErrorSoloError

CodeSOLO-3018
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when the node-delete transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a node-delete transaction to remove a consensus node from the address book, so this means the transaction was rejected or could not be submitted — for example the admin key did not sign, the target node id was invalid, or the network could not be reached.

Troubleshooting Steps

  1. Verify the node admin key is correct and loaded from the k8s secret.
  2. Confirm the node exists in the current address book.
  3. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
  4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.18 - SOLO-3019

NodeCreateTransactionErrorSoloError — Component

NodeCreateTransactionErrorSoloError

CodeSOLO-3019
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when the node-create transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a node-create transaction to add a consensus node to the network’s address book, so this means the transaction was rejected or could not be submitted — for example the admin key did not sign, the node endpoints or parameters were invalid, or the network could not be reached.

Troubleshooting Steps

  1. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
  2. Confirm the admin key is valid and the account has sufficient HBAR.
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.19 - SOLO-3021

AccountBalanceQueryFailedSoloError — Component

AccountBalanceQueryFailedSoloError

CodeSOLO-3021
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot read an account’s HBAR balance from the network via the Hedera SDK; the message names the account and, when present, wraps the underlying cause. solo queries balances to verify funding and confirm operations, so this is raised when the balance query does not return — typically because the target consensus node is unreachable or not yet ACTIVE, or the SDK client is misconfigured. It is retryable, since a transient network or node-readiness issue often clears on a later attempt.

Troubleshooting Steps

  1. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
  2. Confirm the account ID is valid and exists on the network.
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.20 - SOLO-3022

ExplorerDeployFailedSoloError — Component

ExplorerDeployFailedSoloError

CodeSOLO-3022
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo explorer node add cannot bring up the Hiero Explorer: the Helm release for the explorer chart failed to install, or its pods never reached a Ready state before solo stopped waiting. The original failure is wrapped in cause.message. Typical roots are an explorer image that cannot be pulled, misconfigured chart values (for example an unreachable mirror-node endpoint), a TLS/cert-manager prerequisite that is not ready, or insufficient cluster resources to schedule the pod.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect explorer pods: kubectl get pods -A -l app.kubernetes.io/component=hiero-explorer
  3. Inspect Helm release: helm status -n

4.1.3.21 - SOLO-3023

ExplorerUpgradeFailedSoloError — Component

ExplorerUpgradeFailedSoloError

CodeSOLO-3023
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo explorer node upgrade cannot upgrade the Hiero Explorer; the underlying failure is wrapped in cause. Upgrade re-applies the explorer Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect Helm release: helm status -n
  3. View explorer pod logs: kubectl logs -n

4.1.3.22 - SOLO-3024

ExplorerDestroyFailedSoloError — Component

ExplorerDestroyFailedSoloError

CodeSOLO-3024
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo explorer node destroy cannot tear down the Hiero Explorer; the underlying failure is wrapped in cause. Destroy uninstalls the explorer Helm release and removes its resources, so this means that teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List Helm releases: helm list -A
  3. Force-uninstall if stuck: helm uninstall -n

4.1.3.23 - SOLO-3025

RelayDeployFailedSoloError — Component

RelayDeployFailedSoloError

CodeSOLO-3025
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo relay node add cannot deploy the JSON-RPC relay; the underlying failure is wrapped in cause. Deploy installs the relay Helm release, so this means that install did not succeed — for example a Helm failure, an image that cannot be pulled, misconfigured values (such as an unreachable network or mirror-node endpoint), or insufficient cluster resources.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect relay pods: kubectl get pods -A -l app.kubernetes.io/instance=relay-
  3. Inspect Helm release: helm status -n

4.1.3.24 - SOLO-3026

RelayUpgradeFailedSoloError — Component

RelayUpgradeFailedSoloError

CodeSOLO-3026
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo relay node upgrade cannot upgrade the JSON-RPC relay; the underlying failure is wrapped in cause. Upgrade re-applies the relay Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect Helm release: helm status -n
  3. View relay pod logs: kubectl logs -n

4.1.3.25 - SOLO-3027

RelayDestroyFailedSoloError — Component

RelayDestroyFailedSoloError

CodeSOLO-3027
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo relay node destroy cannot tear down the JSON-RPC relay; the underlying failure is wrapped in cause. Destroy uninstalls the relay Helm release and removes its resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List Helm releases: helm list -A
  3. Force-uninstall if stuck: helm uninstall -n

4.1.3.26 - SOLO-3028

RelayNotRunningSoloError — Component

RelayNotRunningSoloError

CodeSOLO-3028
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a JSON-RPC relay that should be running is not; the message names the release and wraps the underlying failure in cause. solo checks that the relay pods are present and running before relying on it, so this means that check failed. It is retryable, since a relay that is still starting or briefly restarting often recovers on a later attempt.

Troubleshooting Steps

  1. Check relay pod status: kubectl get pods -A | grep
  2. View relay pod logs: kubectl logs -n -l app.kubernetes.io/instance=
  3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.27 - SOLO-3029

RelayNotReadySoloError — Component

RelayNotReadySoloError

CodeSOLO-3029
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a deployed JSON-RPC relay does not become ready in time; the message names the release and wraps the underlying failure in cause. solo waits for the relay pods to reach a Ready state after install, so this means that wait did not succeed in time. It is retryable, since a relay that is merely slow to start often becomes ready on a later attempt; a persistent failure points to a crash-looping or misconfigured relay.

Troubleshooting Steps

  1. Check relay pod status: kubectl get pods -A | grep
  2. Describe relay pods to check readiness probe failures: kubectl describe pods -A -l app.kubernetes.io/instance=
  3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.28 - SOLO-3030

RelayOperatorKeyRetrievalFailedSoloError — Component

RelayOperatorKeyRetrievalFailedSoloError

CodeSOLO-3030
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot retrieve the operator key the JSON-RPC relay needs; the underlying failure is wrapped in cause. The relay signs transactions with an operator account key that solo reads (for example from a secret), so this means that retrieval failed. It is retryable, since a transient cluster or lookup problem often clears on a later attempt.

Troubleshooting Steps

  1. Verify K8s API connectivity: kubectl get pods -n
  2. If an operator key secret exists, verify it has a privateKey field: kubectl get secret -n -o yaml | grep privateKey
  3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.29 - SOLO-3031

MirrorNodeDeployFailedSoloError — Component

MirrorNodeDeployFailedSoloError

CodeSOLO-3031
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo mirror node add cannot deploy the mirror node; the underlying failure is wrapped in cause. Deploy installs the mirror node Helm release (its importer, REST, and database components), so this means that install did not succeed — for example a Helm failure, an image that cannot be pulled, misconfigured values, or insufficient cluster resources.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect mirror node pods: kubectl get pods -A -l app.kubernetes.io/instance=mirror-
  3. Inspect Helm release: helm status -n

4.1.3.30 - SOLO-3032

MirrorNodeUpgradeFailedSoloError — Component

MirrorNodeUpgradeFailedSoloError

CodeSOLO-3032
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo mirror node upgrade cannot upgrade the mirror node; the underlying failure is wrapped in cause. Upgrade re-applies the mirror node Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect Helm release: helm status -n
  3. View mirror node pod logs: kubectl logs -n

4.1.3.31 - SOLO-3033

MirrorNodeDestroyFailedSoloError — Component

MirrorNodeDestroyFailedSoloError

CodeSOLO-3033
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo mirror node destroy cannot tear down the mirror node; the underlying failure is wrapped in cause. Destroy uninstalls the mirror node Helm release and removes its resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List Helm releases: helm list -A
  3. Force-uninstall if stuck: helm uninstall -n

4.1.3.32 - SOLO-3034

MirrorNodeOperatorKeyRetrievalFailedSoloError — Component

MirrorNodeOperatorKeyRetrievalFailedSoloError

CodeSOLO-3034
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot retrieve the operator key the mirror node needs; the underlying failure is wrapped in cause. solo reads the operator account key (for example from a secret) so the mirror node can perform its operations, so this means that retrieval failed. It is retryable, since a transient cluster or lookup problem often clears on a later attempt.

Troubleshooting Steps

  1. Verify K8s API connectivity: kubectl get pods -n
  2. If an operator key secret exists, verify it has a privateKey field: kubectl get secret -n -o yaml | grep privateKey
  3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.33 - SOLO-3035

OneShotDeployFailedSoloError — Component

OneShotDeployFailedSoloError

CodeSOLO-3035
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a one-shot deployment fails; the message describes the failing step and wraps the underlying failure in cause. One-shot mode brings up a complete network in a single command by running many deploy steps in sequence, so this means one of those steps did not succeed — the message identifies which, and common roots are Helm, image, or cluster-resource problems in the underlying step.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. If rollback was skipped, clean up partial resources: solo one-shot single destroy
  3. If nothing else works, remove the SOLO_HOME directory and delete the cluster:
  4. +kind delete cluster –name solo-cluster
  5. rm -rf ~/.solo

4.1.3.34 - SOLO-3036

OneShotDestroyFailedSoloError — Component

OneShotDestroyFailedSoloError

CodeSOLO-3036
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when destroying a one-shot deployment fails; the underlying failure is wrapped in cause. One-shot destroy tears down everything a one-shot deploy created, so this means that teardown did not complete — for example a Helm release or cluster could not be removed, or the cluster API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List remaining Helm releases: helm list -A
  3. Delete stuck resources manually: kubectl delete -n

4.1.3.35 - SOLO-3037

OneShotDeploymentInfoRetrievalFailedSoloError — Component

OneShotDeploymentInfoRetrievalFailedSoloError

CodeSOLO-3037
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot retrieve information about a one-shot deployment; the underlying failure is wrapped in cause. solo reads deployment details (such as component status and endpoints) to report them, so this means that lookup failed — for example the cluster was unreachable or the expected resources were not found.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify kubeconfig context is valid: kubectl cluster-info

4.1.3.36 - SOLO-3038

FalconValuesPreparationFailedSoloError — Component

FalconValuesPreparationFailedSoloError

CodeSOLO-3038
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot prepare the Falcon values file used during deployment; the underlying failure is wrapped in cause. solo assembles this Helm values file from configuration and runtime inputs before installing, so this means that preparation step failed — for example a required input was missing or invalid, or the file could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the profile YAML is valid: solo deployment profile validate

4.1.3.37 - SOLO-3039

BlockNodeDeployFailedSoloError — Component

BlockNodeDeployFailedSoloError

CodeSOLO-3039
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo block node add cannot deploy a block node; the underlying failure is wrapped in cause. Deploy installs the block node Helm release, so this means that install did not succeed — for example a Helm failure, an image that cannot be pulled, misconfigured values, or insufficient cluster resources.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
  3. Inspect Helm release: helm status -n
  4. Check Helm history: helm history -n

4.1.3.38 - SOLO-3040

BlockNodeDestroyFailedSoloError — Component

BlockNodeDestroyFailedSoloError

CodeSOLO-3040
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo block node destroy cannot tear down a block node; the underlying failure is wrapped in cause. Destroy uninstalls the block node Helm release and removes its resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
  3. Inspect Helm release: helm status -n
  4. Check Helm history: helm history -n

4.1.3.39 - SOLO-3041

BlockNodeUpgradeFailedSoloError — Component

BlockNodeUpgradeFailedSoloError

CodeSOLO-3041
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo block node upgrade cannot upgrade a block node; the underlying failure is wrapped in cause. Upgrade re-applies the block node Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
  3. Inspect Helm release: helm status -n
  4. Check Helm history: helm history -n

4.1.3.40 - SOLO-3042

BlockNodeAddExternalFailedSoloError — Component

BlockNodeAddExternalFailedSoloError

CodeSOLO-3042
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot register an external block node with the deployment; the underlying failure is wrapped in cause. Adding an external block node records a block node that runs outside this deployment so consensus nodes can use it, so this means that registration step failed — for example the provided endpoint was unreachable or the remote configuration could not be updated.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect the remote config for the registered node: solo deployment config info
  3. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
  4. If the issue persists, report it with your solo log

4.1.3.41 - SOLO-3043

BlockNodeDeleteExternalFailedSoloError — Component

BlockNodeDeleteExternalFailedSoloError

CodeSOLO-3043
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot remove an external block node from the deployment; the underlying failure is wrapped in cause. Removing an external block node updates the configuration so consensus nodes no longer use it, so this means that removal step failed — for example the remote configuration could not be updated.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect the remote config for the registered node: solo deployment config info
  3. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
  4. If the issue persists, report it with your solo log

4.1.3.42 - SOLO-3044

BlockNodeHealthCheckFailedSoloError — Component

BlockNodeHealthCheckFailedSoloError

CodeSOLO-3044
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when a block node health check does not pass; the message states the reason. solo health-checks a block node to confirm it is up and serving before relying on it, so this means the check reported the node unhealthy or could not reach it. It is retryable, since a block node that is still starting often passes on a later attempt.

Troubleshooting Steps

  1. Check block node pod status: kubectl get pods -A -l block-node.hiero.com/type=block-node
  2. Verify liveness endpoint manually: kubectl exec -n – curl http://localhost:/healthz/readyz
  3. Check pod logs: kubectl logs -n -l block-node.hiero.com/type=block-node
  4. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.3.43 - SOLO-3045

RapidFireLoadStartFailedSoloError — Component

RapidFireLoadStartFailedSoloError

CodeSOLO-3045
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot start a rapid-fire load run; the underlying failure is wrapped in cause. This step launches the load generator against the network, so this means startup failed — for example the load-test workload could not be created or scheduled. It is retryable, since transient cluster issues often clear on a later attempt.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check NLG pod status: kubectl get pods -n -l app.kubernetes.io/instance=network-load-generator
  3. Describe NLG pods for scheduling or image-pull errors: kubectl describe pods -n -l app.kubernetes.io/instance=network-load-generator
  4. Check the NLG Helm release: helm status network-load-generator -n

4.1.3.44 - SOLO-3046

RapidFireLoadStopFailedSoloError — Component

RapidFireLoadStopFailedSoloError

CodeSOLO-3046
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot stop a rapid-fire load run; the underlying failure is wrapped in cause. This step halts the running load generator, so this means the stop did not succeed — for example the workload could not be reached or removed.

Troubleshooting Steps

  1. Check solo logs for the root cause: tail -n 100 ~/.solo/logs/solo.log
  2. Check NLG pod status: kubectl get pods -n -l app.kubernetes.io/instance=network-load-generator
  3. Check for running NLG Java processes: kubectl exec -n – ps aux | grep java
  4. To force-stop, uninstall the NLG chart: helm uninstall network-load-generator -n

4.1.3.45 - SOLO-3047

RapidFireKillFailedSoloError — Component

RapidFireKillFailedSoloError

CodeSOLO-3047
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot stop a running rapid-fire load test; the message names the test class and wraps the underlying failure in cause. This step terminates the load generator, so this means the stop did not succeed — for example the load-test pod or process could not be reached or signaled.

Troubleshooting Steps

  1. Check if the test process is still running: kubectl exec -n – ps aux | grep
  2. Manually kill the process: kubectl exec -n – pkill -f
  3. To stop the load test entirely, uninstall the NLG chart: helm uninstall network-load-generator -n

4.1.3.46 - SOLO-3048

AccountCreationFailedSoloError — Component

AccountCreationFailedSoloError

CodeSOLO-3048
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when creating a Hedera account through the SDK fails; the underlying failure is wrapped in cause. solo creates accounts (for example operator or treasury accounts) during network setup, so this means the create transaction did not succeed — commonly because the network rejected it (insufficient payer balance, key problems) or the consensus node could not be reached.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Check node logs for errors: kubectl logs -n
  4. Create a new account: solo ledger account create

4.1.3.47 - SOLO-3049

AccountKeyUpdateFailedSoloError — Component

AccountKeyUpdateFailedSoloError

CodeSOLO-3049
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when updating the keys on a Hedera account fails; the message names the account. solo rotates account keys (for example replacing genesis keys) with an update transaction, so this means that transaction did not succeed — commonly because the existing key did not sign correctly, the new key is invalid, or the network rejected or could not be reached.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Verify the account ID is correct and the account exists on the network

4.1.3.48 - SOLO-3050

AccountKeysBatchUpdateFailedSoloError — Component

AccountKeysBatchUpdateFailedSoloError

CodeSOLO-3050
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a batch key-update over several accounts does not fully succeed; the message reports how many accounts were not updated. solo updates account keys in bulk during setup and raises this when one or more of those updates is rejected — typically due to signing or key problems on the affected accounts, or transient network failures while submitting the batch.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Verify operator account has sufficient permissions
  4. Update individual accounts: solo ledger account update

4.1.3.49 - SOLO-3051

AccountTransferFailedSoloError — Component

AccountTransferFailedSoloError

CodeSOLO-3051
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when an HBAR transfer transaction fails; the underlying failure is wrapped in cause. solo transfers HBAR to fund accounts during setup and account operations, so this means the transfer was rejected or could not be submitted — commonly an insufficient sender balance, a signing problem, or an unreachable consensus node.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Verify the sender account has sufficient HBAR balance

4.1.3.50 - SOLO-3052

AccountInfoFailedSoloError — Component

AccountInfoFailedSoloError

CodeSOLO-3052
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot retrieve an account’s information from the network via the SDK; the underlying failure is wrapped in cause. It means the account-info query did not return — for example the account does not exist, the consensus node is unreachable or not yet ACTIVE, or the SDK client is misconfigured.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Verify the account ID exists on the network

4.1.3.51 - SOLO-3053

AccountUpdateFailedSoloError — Component

AccountUpdateFailedSoloError

CodeSOLO-3053
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when updating a Hedera account’s properties fails; the message names the account. solo submits an account-update transaction to change account settings, so this means that transaction did not succeed — for example the account’s key did not sign, the requested change was invalid, or the network rejected or could not be reached.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Verify the account exists on the network: solo ledger account update

4.1.3.52 - SOLO-3054

AccountSecretCreationFailedSoloError — Component

AccountSecretCreationFailedSoloError

CodeSOLO-3054
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot store an account’s key material as a Kubernetes secret; the message names the account. After creating or updating an account, solo persists its keys in a cluster secret so other components can use them, so this is raised when that secret cannot be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Kubernetes connectivity: kubectl get pods -n
  3. Check existing secrets: kubectl get secrets -n
  4. Verify RBAC permissions allow secret creation

4.1.3.53 - SOLO-3055

EvmAddressRetrievalFailedSoloError — Component

EvmAddressRetrievalFailedSoloError

CodeSOLO-3055
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot determine the EVM address associated with a Hedera account; the message names the account. solo derives or looks up the account EVM (alias) address for EVM-compatible workflows, so this is raised when that lookup fails — for example the account has no EVM address, or its account info could not be retrieved from the network.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Verify the account ID is valid and the account exists on the network

4.1.3.54 - SOLO-3056

NodeAccessConfigFailedSoloError — Component

NodeAccessConfigFailedSoloError

CodeSOLO-3056
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot configure access to a consensus node; the underlying failure is wrapped in cause. This step establishes the connection (such as a port-forward) and credentials needed to reach a node, so this means that configuration failed — for example the node pod or service was not reachable, or a required port-forward could not be created.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus node pods are running: kubectl get pods -n
  3. Check node logs: kubectl logs -n
  4. Restart the consensus node: solo consensus node restart

4.1.3.55 - SOLO-3057

NodeClientLoadFailedSoloError — Component

NodeClientLoadFailedSoloError

CodeSOLO-3057
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot load the Hedera SDK client used to talk to the network; the underlying failure is wrapped in cause. The client is built from network and node connection details plus operator credentials, so this means that load step failed — for example the node services or endpoints could not be resolved, or the operator key was missing or invalid.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus node pods are running: kubectl get pods -n
  3. Inspect node pod logs: kubectl logs -n
  4. Verify network port-forwards are active: solo deployment refresh port-forwards

4.1.3.56 - SOLO-3058

NodeClientRefreshFailedSoloError — Component

NodeClientRefreshFailedSoloError

CodeSOLO-3058
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot refresh the Hedera SDK client’s view of the network; the underlying failure is wrapped in cause. solo refreshes the client when the network’s nodes or endpoints change, so this means re-resolving the connection details failed — for example node services could not be retrieved or the new endpoints were unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus node pods are running: kubectl get pods -n
  3. Inspect node pod logs: kubectl logs -n
  4. Verify network port-forwards are active: solo deployment refresh port-forwards

4.1.3.57 - SOLO-3059

NodeClientSetupFailedSoloError — Component

NodeClientSetupFailedSoloError

CodeSOLO-3059
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot set up the Hedera SDK client for the network; the underlying failure is wrapped in cause. Setup wires the client to the network node endpoints and operator account before any SDK calls, so this means that configuration step failed — for example endpoints could not be resolved or operator credentials were missing or invalid.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus node pods are running: kubectl get pods -n
  3. Check port-forward status: solo deployment refresh port-forwards
  4. Inspect node logs: kubectl logs -n

4.1.3.58 - SOLO-3060

SdkPingFailedSoloError — Component

SdkPingFailedSoloError

CodeSOLO-3060
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo SDK ping to a network node does not succeed within the allowed retries; the message names the node alias and the number of retries tried. solo pings nodes to confirm they are reachable and responsive before relying on them, and raises this once retries are exhausted. It is retryable because a node that is merely slow to start often responds on a later attempt; a persistent failure points to a node that is down or unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the node pod is running: kubectl get pods -n -l solo.hedera.com/node-name=
  3. Inspect node logs: kubectl logs -n
  4. Check port-forward status: solo deployment refresh port-forwards
  5. Restart the node: solo consensus node restart

4.1.3.59 - SOLO-3061

NodeServicesRetrievalFailedSoloError — Component

NodeServicesRetrievalFailedSoloError

CodeSOLO-3061
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot retrieve the Kubernetes services for the network’s consensus nodes; the underlying failure is wrapped in cause. solo reads these services to discover node endpoints, so this means the lookup failed — for example the namespace is wrong, the services do not exist yet, or the Kubernetes API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List Kubernetes services in the namespace: kubectl get svc -n
  3. Verify consensus nodes are deployed: kubectl get pods -n

4.1.3.60 - SOLO-3062

GossipKeySecretCreationFailedSoloError — Component

GossipKeySecretCreationFailedSoloError

CodeSOLO-3062
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot store a consensus node’s gossip keys as a Kubernetes secret; the message names the node alias. Gossip keys secure node-to-node communication and are mounted from a cluster secret, so this means that secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check existing secrets: kubectl get secrets -n
  3. Verify RBAC permissions allow secret creation in the namespace
  4. Re-run node setup: solo consensus node setup

4.1.3.61 - SOLO-3063

TlsKeySecretCreationFailedSoloError — Component

TlsKeySecretCreationFailedSoloError

CodeSOLO-3063
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot store a generated TLS key as a Kubernetes secret; when available the underlying failure is wrapped in cause. solo persists TLS keys in cluster secrets so components can mount them, so this means the secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check existing secrets: kubectl get secrets -n
  3. Verify RBAC permissions allow secret creation in the namespace
  4. Re-run node setup: solo consensus node setup

4.1.3.62 - SOLO-3064

TlsKeyGenerationFailedSoloError — Component

TlsKeyGenerationFailedSoloError

CodeSOLO-3064
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot generate a TLS key; the message includes the underlying error text. solo generates TLS keys to secure node communication, so this means generation failed — for example the key-generation tooling errored or a working file could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify required key generation tools are available
  3. Re-run node setup: solo consensus node setup

4.1.3.63 - SOLO-3065

SigningKeyGenerationFailedSoloError — Component

SigningKeyGenerationFailedSoloError

CodeSOLO-3065
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot generate a node signing key; the underlying failure is wrapped in cause. Signing keys establish a consensus node identity, so this means generation failed — for example the key-generation tooling errored or a working file could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify key generation tools are available
  3. Re-run key generation: solo keys consensus

4.1.3.64 - SOLO-3066

GrpcTlsKeyGenerationFailedSoloError — Component

GrpcTlsKeyGenerationFailedSoloError

CodeSOLO-3066
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot generate the gRPC TLS key for a consensus node; the underlying failure is wrapped in cause. solo generates this key to secure node gRPC traffic, so this means key generation failed — for example the key-generation tooling errored or a working file could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify key generation tools are available
  3. Re-run node setup: solo consensus node setup

4.1.3.65 - SOLO-3067

GrpcTlsCertMismatchSoloError — Component

GrpcTlsCertMismatchSoloError

CodeSOLO-3067
CategoryComponent
OwnershipUser
RetryableNo

Description

Thrown when the gRPC TLS certificate and key supplied by the user do not correspond; the message lists the certificate and key paths. solo pairs each provided certificate with its key for node gRPC TLS, so this means the structures do not match — typically a certificate and key from different pairs, or paths that were swapped or point to the wrong files.

Troubleshooting Steps

  1. Ensure the number of certificate paths matches the number of key paths
  2. Each certificate must have a corresponding private key in the same position
  3. Verify the certificate and key files exist at the specified paths

4.1.3.66 - SOLO-3068

GrpcWebTlsCertMismatchSoloError — Component

GrpcWebTlsCertMismatchSoloError

CodeSOLO-3068
CategoryComponent
OwnershipUser
RetryableNo

Description

Thrown when the gRPC Web TLS certificate and key supplied by the user do not correspond; the message lists the certificate and key paths. solo pairs each provided certificate with its key for the node’s gRPC Web TLS, so this means the structures do not match — typically a certificate and key from different pairs, or paths that were swapped or point to the wrong files.

Troubleshooting Steps

  1. Ensure the number of certificate paths matches the number of key paths
  2. Each certificate must have a corresponding private key in the same position
  3. Verify the certificate and key files exist at the specified paths

4.1.3.67 - SOLO-3069

CertificateSecretCreationFailedSoloError — Component

CertificateSecretCreationFailedSoloError

CodeSOLO-3069
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot create the TLS certificate secret for a consensus node; the message names the node alias. solo stores node certificates as Kubernetes secrets so they can be mounted, so this means the secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check existing secrets: kubectl get secrets -n
  3. Verify RBAC permissions allow secret creation
  4. Re-run node setup: solo consensus node setup

4.1.3.68 - SOLO-3070

CertificateParsingFailedSoloError — Component

CertificateParsingFailedSoloError

CodeSOLO-3070
CategoryComponent
OwnershipUser
RetryableNo

Description

Thrown when solo cannot parse a certificate input the user provided; the message names the input, its type, and the line and index of the offending entry. solo parses each supplied certificate to validate and use it, so this means the content is not valid for the expected format — for example a malformed or truncated certificate, or the wrong kind of file supplied.

Troubleshooting Steps

  1. Verify the certificate input format is correct for the expected type
  2. Check the value at line , position of the input
  3. Ensure certificate values are properly formatted (PEM or DER encoded)

4.1.3.69 - SOLO-3071

CertificateFileNotFoundSoloError — Component

CertificateFileNotFoundSoloError

CodeSOLO-3071
CategoryComponent
OwnershipUser
RetryableNo

Description

Thrown when a certificate file the user referenced does not exist at the given path; the message names the path and input type, with the line and index of the offending entry. solo reads certificate files from the paths provided on the command line or in configuration, so this means the file is missing or the path is wrong — for example a typo, a relative path resolved from an unexpected directory, or a file that was moved.

Troubleshooting Steps

  1. Verify the file exists at the path:
  2. Ensure the path is absolute or relative to the working directory
  3. Check file permissions allow reading the certificate file

4.1.3.70 - SOLO-3072

ExplorerTlsSecretCreationFailedSoloError — Component

ExplorerTlsSecretCreationFailedSoloError

CodeSOLO-3072
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot create the TLS certificate secret used by the Hiero Explorer; when available the underlying failure is wrapped in cause. The explorer is served over TLS using a certificate stored as a Kubernetes secret, so this means that secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check existing secrets: kubectl get secrets -n
  3. Verify RBAC permissions allow secret creation
  4. Re-deploy the explorer: solo explorer node add

4.1.3.71 - SOLO-3073

PlatformFileNotFoundSoloError — Component

PlatformFileNotFoundSoloError

CodeSOLO-3073
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a platform file solo needs does not exist; the message names the path. solo reads platform artifacts from expected locations during setup, so this means the file is missing — for example the platform build was incomplete, an earlier download or extract step did not produce it, or the path is wrong.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the file exists at:
  3. Ensure the node build artifacts are present and the build path is correct

4.1.3.72 - SOLO-3074

PlatformFileCopyFailedSoloError — Component

PlatformFileCopyFailedSoloError

CodeSOLO-3074
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot copy platform files into a consensus node pod; the message names the source files, the pod, and the destination directory, and wraps the underlying failure in cause. solo copies platform artifacts into the node container during setup, so this means the copy failed — for example the pod was not reachable, the destination path was not writable, or the connection dropped mid-copy.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the pod is running: kubectl get pod -n
  3. Check available disk space in the pod
  4. Inspect pod logs: kubectl logs -n

4.1.3.73 - SOLO-3075

PlatformKeyFileMissingSoloError — Component

PlatformKeyFileMissingSoloError

CodeSOLO-3075
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a required key file is missing; the message names the file. solo expects certain key files to be present when provisioning a node, so this means one of them was not found — for example key generation did not produce it, or it was not copied into the expected location.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the key file exists at:
  3. Re-generate keys if needed: solo keys consensus
  4. Re-run node setup: solo consensus node setup

4.1.3.74 - SOLO-3076

GenesisAdminKeySecretFailedSoloError — Component

GenesisAdminKeySecretFailedSoloError

CodeSOLO-3076
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot store a genesis account’s admin key as a Kubernetes secret; the message names the account. During genesis setup solo persists admin keys in cluster secrets for later use, so this is raised when that secret cannot be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check existing secrets: kubectl get secrets -n
  3. Verify RBAC permissions allow secret creation
  4. Redeploy the network: solo consensus network deploy

4.1.3.75 - SOLO-3077

GenesisDataGenerationFailedSoloError — Component

GenesisDataGenerationFailedSoloError

CodeSOLO-3077
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo fails to generate the genesis data used to bootstrap a new network; the underlying failure is wrapped in cause. Genesis generation produces the initial accounts, keys, and configuration the network starts from, so this means that generation step did not complete — for example required inputs were missing or invalid, or a file could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify all consensus node configurations are correct
  3. Check deployment configuration: solo deployment config info
  4. Redeploy the network: solo consensus network deploy

4.1.3.76 - SOLO-3078

PostgresInitScriptCopyFailedSoloError — Component

PostgresInitScriptCopyFailedSoloError

CodeSOLO-3078
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot copy the mirror node Postgres initialization script into its container; the message names the namespace and wraps the underlying failure in cause. solo copies this script into the database container before running it, so this means the copy failed — for example the target container or pod was not reachable, or the destination was not writable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the Postgres pod is running: kubectl get pods -n -l app.kubernetes.io/name=postgresql
  3. Inspect Postgres pod logs: kubectl logs -n
  4. Re-deploy the mirror node: solo mirror node add

4.1.3.77 - SOLO-3079

PostgresInitScriptFailedSoloError — Component

PostgresInitScriptFailedSoloError

CodeSOLO-3079
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when the mirror node Postgres initialization script fails to run; the message includes the number of attempts made and wraps the underlying failure. solo runs this script to initialize the mirror node database, so this means execution did not succeed across the attempts tried — for example the database was not ready or the script returned an error. It is retryable, since a database that is still starting often accepts the script on a later attempt.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect Postgres pod logs: kubectl logs -n
  3. Check Postgres pod status: kubectl describe pod -n
  4. Re-deploy the mirror node: solo mirror node add

4.1.3.78 - SOLO-3080

MirrorPasswordSecretMissingSoloError — Component

MirrorPasswordSecretMissingSoloError

CodeSOLO-3080
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when the mirror node database owner credential is absent from the expected secret — specifically MIRROR_IMPORTER_DB_OWNER is not present in the mirror-passwords secret. solo reads this secret to obtain the importer’s database owner, so this means the secret exists without the required key, or was not populated as expected during deployment.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect the mirror-passwords secret: kubectl get secret mirror-passwords -n -o jsonpath="{.data}"
  3. Re-deploy the mirror node to recreate secrets: solo mirror node add

4.1.3.79 - SOLO-3081

FileContentVerificationFailedSoloError — Component

FileContentVerificationFailedSoloError

CodeSOLO-3081
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo’s verification of a file’s content fails; the message describes what was being verified. solo verifies file content at certain steps to ensure it matches the expected value, so this means that check did not pass — the content was missing, incomplete, or different from what was required.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running and healthy: kubectl get pods -n
  3. Inspect node logs for errors: kubectl logs -n

4.1.3.80 - SOLO-3082

HederaFileCreationFailedSoloError — Component

HederaFileCreationFailedSoloError

CodeSOLO-3082
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a Hedera File Service create transaction returns a non-success status; the message includes the network status. solo uses the File Service to store artifacts on the network (such as upgrade files), so this means the file create was rejected — the specific status code identifies why, for example a payer or signature problem or an invalid file.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Consult the Hedera documentation for the meaning of the status code

4.1.3.81 - SOLO-3083

HederaFileUpdateFailedSoloError — Component

HederaFileUpdateFailedSoloError

CodeSOLO-3083
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a Hedera File Service update transaction returns a non-success status; the message includes the network status. solo updates network-stored files (such as upgrade files) via the File Service, so this means the update was rejected — the specific status code identifies why.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Consult the Hedera documentation for the meaning of the status code

4.1.3.82 - SOLO-3084

HederaFileAppendFailedSoloError — Component

HederaFileAppendFailedSoloError

CodeSOLO-3084
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a Hedera File Service append transaction returns a non-success status; the message includes the chunk index and the network status. Large files are uploaded in chunks, so this means appending a particular chunk was rejected — the specific status code identifies why, for example a size limit or a payer or signature problem.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Consult the Hedera documentation for the meaning of the status code

4.1.3.83 - SOLO-3085

NodeStatusEmptyResponseSoloError — Component

NodeStatusEmptyResponseSoloError

CodeSOLO-3085
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a consensus node’s status check returns an empty response. solo queries each node’s status endpoint to determine its state, so an empty reply means the node returned nothing usable — typically because the node is not yet serving its status endpoint, or the request reached a target that is not ready.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the consensus node pod is running: kubectl get pods -n
  3. Inspect node logs: kubectl logs -n

4.1.3.84 - SOLO-3086

NodeStatusMissingLineSoloError — Component

NodeStatusMissingLineSoloError

CodeSOLO-3086
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when a consensus node’s status check response is missing the expected status line. solo parses the status output to read the node’s current state, so this means the response came back but did not contain the line solo needs — usually because the node is still starting and has not produced full status output, or the output format was unexpected.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the consensus node pod is running: kubectl get pods -n
  3. Inspect node logs: kubectl logs -n

4.1.3.85 - SOLO-3087

PredefinedAccountsCreationFailedSoloError — Component

PredefinedAccountsCreationFailedSoloError

CodeSOLO-3087
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo fails to create the set of predefined accounts it seeds into a new network; the underlying failure is wrapped in cause. These accounts are created during setup to provide ready-to-use funded accounts, so this means one of those creations did not succeed — commonly a network rejection, a signing or key problem, or an unreachable consensus node.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify consensus nodes are running: kubectl get pods -n
  3. Check node logs for errors: kubectl logs -n

4.1.3.86 - SOLO-3088

FileContentMismatchSoloError — Component

FileContentMismatchSoloError

CodeSOLO-3088
CategoryComponent
OwnershipInfrastructure
RetryableNo

Description

Thrown when content read back from the network does not match what solo uploaded. After uploading a file (for example via the Hedera File Service), solo re-reads it and compares, so this means the round-trip verification failed — the stored content differs from what was sent, indicating the upload was incomplete or corrupted.

Troubleshooting Steps

  1. Retry the file upload — transient network issues can cause partial or corrupt writes
  2. Check solo logs for chunk append errors: tail -n 100 ~/.solo/logs/solo.log
  3. Verify consensus nodes are healthy: kubectl get pods -n
  4. Check node logs for transaction errors: kubectl logs -n
  5. Confirm no concurrent process modified the same Hedera file during the upload

4.1.3.87 - SOLO-3089

NodeServiceNotFoundSoloError — Component

NodeServiceNotFoundSoloError

CodeSOLO-3089
CategoryComponent
OwnershipUser
RetryableNo

Description

Thrown when solo cannot resolve the Kubernetes service for a specific consensus node; the message names the node alias. solo expects each node to expose a service it can reach, so this is raised when no matching service is found — typically because the node alias does not correspond to a deployed node, or the selected deployment or namespace does not contain it.

Troubleshooting Steps

  1. Verify that node ‘’ exists in the deployment: solo deployment info
  2. List all node services in the namespace: kubectl get svc -n
  3. Check that the consensus node pod is running: kubectl get pods -n -l app=
  4. Check solo logs for more context: tail -n 100 ~/.solo/logs/solo.log

4.1.3.88 - SOLO-3090

BlockNodeJfrCollectionFailedSoloError — Component

BlockNodeJfrCollectionFailedSoloError

CodeSOLO-3090
CategoryComponent
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo block node collect-jfr cannot collect the Java Flight Recorder recording from a block node; the underlying failure is wrapped in cause. Retryable, since a transient pod or cluster-API problem often clears on a later attempt.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
  3. Verify the block node was deployed with Java Flight Recorder enabled
  4. Verify the cluster is reachable: kubectl cluster-info –context

4.1.4 - Validation

4.1.4.1 - SOLO-4001

MissingArgumentError — Validation

MissingArgumentError

CodeSOLO-4001
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when code reaches a point that requires a value but the value is absent or empty; the error message describes the argument that was expected. In most cases this is a required CLI flag or configuration value that the command was invoked without (for example a deployment selection left empty). It is also used as an internal guard when a method is called without a mandatory argument, in which case it points to a defect in the calling code rather than to user input.

Troubleshooting Steps

  1. Provide the missing argument. Run solo –help for usage information

4.1.4.2 - SOLO-4002

IllegalArgumentError — Validation

IllegalArgumentError

CodeSOLO-4002
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an argument value is not legal for the operation; the message states the reason, and the offending value is attached. solo validates argument values before using them, so this means a provided value was out of range, malformed, or otherwise unacceptable.

Troubleshooting Steps

  1. An argument has an valid value or format.
  2. Verify the argument value before retrying

4.1.4.3 - SOLO-4003

InvalidOutputFormatError — Validation

InvalidOutputFormatError

CodeSOLO-4003
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an output format is not one of the allowed values; the message names the offending value and the allowed set (json, yaml, wide). solo formats command output according to this flag, so this means an unsupported value was supplied.

Troubleshooting Steps

  1. Valid output formats are: json, yaml, wide

4.1.4.4 - SOLO-4004

ConsensusNodeCountRequiredError — Validation

ConsensusNodeCountRequiredError

CodeSOLO-4004
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the consensus node count flag is required but missing; the message names the flag and the phase in which it is needed. solo needs to know how many consensus nodes to act on, so this means the flag must be supplied at that phase.

Troubleshooting Steps

  1. Specify the number of consensus nodes using the – flag, e.g. – 3

4.1.4.5 - SOLO-4005

InvalidPortNumberError — Validation

InvalidPortNumberError

CodeSOLO-4005
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown while validating a port value supplied through a CLI flag or configuration field, when the value does not denote a usable TCP/UDP port: it is not an integer, or it falls outside the valid range of 1–65535. The error message echoes the offending value. This is raised before solo tries to bind, forward, or configure the port, so it reflects bad input (a typo, a non-numeric string, or 0/a negative/too-large number) rather than a port that is already in use.

Troubleshooting Steps

  1. Port numbers must be integers between 1 and 65535

4.1.4.6 - SOLO-4006

LocalBuildPathNotFoundSoloError — Validation

LocalBuildPathNotFoundSoloError

CodeSOLO-4006
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a local build path does not exist; the message names it. solo reads platform artifacts from this path, so this means it is missing or the path is wrong.

Troubleshooting Steps

  1. Verify the path exists: ls -la
  2. Set the correct path: solo consensus node setup –local-build-path
  3. Build the platform locally and point to the data/ directory output

4.1.4.7 - SOLO-4007

LocalBuildMissingSubdirectoriesSoloError — Validation

LocalBuildMissingSubdirectoriesSoloError

CodeSOLO-4007
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a local build path is missing the required apps and lib subdirectories; the message names the path. solo expects a local platform build to contain both, so this means the path does not point at a complete build.

Troubleshooting Steps

  1. Verify the directory structure: ls -la
  2. Ensure the path points to the data/ directory of the Hedera platform build
  3. Expected layout: /apps/.jar and /lib/.jar (set via –local-build-path)

4.1.4.8 - SOLO-4008

LocalBuildNoJarFilesSoloError — Validation

LocalBuildNoJarFilesSoloError

CodeSOLO-4008
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when no jar files are found in a local build subdirectory; the message names the subdirectory. solo expects the build subdirectories to contain jars, so this means the build is incomplete or the path is wrong.

Troubleshooting Steps

  1. List files in the directory: ls -la
  2. Ensure a complete platform build was performed before using –local-build-path
  3. Expected: /apps/HederaNode.jar and /lib/*.jar

4.1.4.9 - SOLO-4009

NodeJarFilesNotInContainerSoloError — Validation

NodeJarFilesNotInContainerSoloError

CodeSOLO-4009
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when no JAR files are found in the expected directory inside a node container; the message names the node alias and the directory. The platform software should have been copied to the node before starting it, so their absence indicates an internal ordering or setup defect and is treated as an internal Solo error.

Troubleshooting Steps

  1. Run setup before starting: solo consensus node setup
  2. Verify the directory inside the pod: kubectl exec -n – ls
  3. Re-copy platform software: solo consensus node setup –local-build-path

4.1.4.10 - SOLO-4010

GrpcEndpointsRequiredSoloError — Validation

GrpcEndpointsRequiredSoloError

CodeSOLO-4010
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when --grpc-endpoints is required for the chosen endpoint type but was not provided; the message names the endpoint type. Certain endpoint types need explicit gRPC endpoints, so this means the flag must be supplied for that type.

Troubleshooting Steps

  1. Provide gRPC endpoints: solo consensus node add –grpc-endpoints ip:port,...
  2. Or switch endpoint type: solo consensus node add –endpoint-type FQDN
  3. Review flag usage: solo consensus node add –help

4.1.4.11 - SOLO-4011

OutputDirectoryNotSpecifiedSoloError — Validation

OutputDirectoryNotSpecifiedSoloError

CodeSOLO-4011
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an output directory is required but --output-dir was not set. solo exports context data to this directory, so this means the flag must be provided.

Troubleshooting Steps

  1. Provide the output directory: solo node –output-dir
  2. Run with –help to see required flags: solo node –help

4.1.4.12 - SOLO-4012

InputDirectoryNotSpecifiedSoloError — Validation

InputDirectoryNotSpecifiedSoloError

CodeSOLO-4012
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an input directory is required but --input-dir was not set. solo reads context data from this directory, so this means the flag must be provided.

Troubleshooting Steps

  1. Provide the input directory: solo node –input-dir
  2. Run with –help to see required flags: solo node –help

4.1.4.13 - SOLO-4013

WrapsKeyPathNotFoundSoloError — Validation

WrapsKeyPathNotFoundSoloError

CodeSOLO-4013
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the WRAPs key path does not exist; the message names the path. solo reads the WRAPs key from this path, so this means it is missing or the path is wrong.

Troubleshooting Steps

  1. Verify the path: ls -la
  2. Set the correct path: solo consensus node add –wraps-key-path
  3. Or omit the flag to download WRAPs keys automatically

4.1.4.14 - SOLO-4014

ConfigFileNotFoundSoloError — Validation

ConfigFileNotFoundSoloError

CodeSOLO-4014
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a configuration file referenced by a flag does not exist; the message names the flag and the absolute and relative paths tried. solo reads the file from the provided path, so this means it is missing or the path is wrong — for example a typo or a relative path resolved from an unexpected directory.

Troubleshooting Steps

  1. Verify the file exists: ls -la
  2. Set the correct file path for the – flag
  3. Run with –help for configuration file flags: solo consensus node setup –help

4.1.4.15 - SOLO-4015

NodeVersionMismatchSoloError — Validation

NodeVersionMismatchSoloError

CodeSOLO-4015
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the consensus node version saved in the remote config differs from the requested version; the message names both. solo guards against mixing versions, so this means the requested version does not match what the deployment recorded — align the versions.

Troubleshooting Steps

  1. Check the saved version: solo deployment config info –deployment
  2. Use the same version: solo consensus node setup –release-tag
  3. Or upgrade the network first: solo consensus network upgrade –upgrade-version

4.1.4.16 - SOLO-4016

UpgradeVersionNotFoundSoloError — Validation

UpgradeVersionNotFoundSoloError

CodeSOLO-4016
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a requested upgrade version does not exist; the message names the version. solo looks up upgrade versions before using them, so this means the version is not available — for example a wrong or not-yet-published version.

Troubleshooting Steps

  1. Check valid release versions: https://github.com/hashgraph/hedera-services/releases
  2. Use a published release tag: solo consensus network upgrade –upgrade-version v0.x.y

4.1.4.17 - SOLO-4017

PvcFlagNotEnabledSoloError — Validation

PvcFlagNotEnabledSoloError

CodeSOLO-4017
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an operation needs PVCs but the PVCs flag is not enabled. Adding a node requires persistent storage, so this means PVCs must be enabled first.

Troubleshooting Steps

  1. Redeploy with PVCs enabled: solo consensus network deploy –pvcs true
  2. Check the current deployment configuration: solo deployment config info –deployment
  3. PVCs are required for node add operations to persist state across pod restarts

4.1.4.18 - SOLO-4018

NonInteractivePromptSoloError — Validation

NonInteractivePromptSoloError

CodeSOLO-4018
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when solo would need to prompt for input but is running non-interactively. A required value was not supplied and solo cannot ask for it (for example in CI or with prompts disabled), so provide the missing value explicitly (such as via the deployment flag).

Troubleshooting Steps

  1. Provide required flags explicitly instead of relying on interactive prompts
  2. Use to specify the deployment name
  3. Run with –help to see all available flags: solo consensus node –help

4.1.4.19 - SOLO-4020

WrapsVersionConstraintSoloError — Validation

WrapsVersionConstraintSoloError

CodeSOLO-4020
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when --wraps is used with a consensus node version below the minimum required; the message names the minimum version. WRAPs support requires a sufficiently new node version, so this means the selected version is too old.

Troubleshooting Steps

  1. Upgrade consensus node first: solo consensus network upgrade –upgrade-version
  2. Or disable WRAPs: solo consensus network deploy –wraps false

4.1.4.20 - SOLO-4021

StateFilePathNotFoundSoloError — Validation

StateFilePathNotFoundSoloError

CodeSOLO-4021
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the provided state file path does not exist; the message names the path (or notes it was not specified). solo needs a valid path to the state file, so this means the path is missing or wrong.

Troubleshooting Steps

  1. Verify the path exists: ls -la <path ?? ‘'>
  2. Download a valid state file first: solo consensus state download
  3. Then provide either the downloaded .zip file or the download parent directory using –state-file
  4. When a directory is provided, Solo looks for state files under: /states//

4.1.4.21 - SOLO-4022

StateFileNotFoundSoloError — Validation

StateFileNotFoundSoloError

CodeSOLO-4022
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a state file does not exist or is not a regular file; the message names the path. solo reads saved state from this file, so this means it is missing or the path points at something that is not a file.

Troubleshooting Steps

  1. Verify the file exists and is a regular file: ls -la
  2. Make sure the path points to a .zip file, not a directory or missing symlink target.
  3. Download a valid state file first: solo consensus state download
  4. When using a directory, pass the parent directory; Solo looks under /states//.

4.1.4.22 - SOLO-4023

InvalidStateFileFormatSoloError — Validation

InvalidStateFileFormatSoloError

CodeSOLO-4023
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a state file is not a .zip; the message names the path. solo expects saved state as a zip archive, so this means a non-zip file was supplied.

Troubleshooting Steps

  1. Use a state file ending in .zip with –state-file <stateFile.zip>
  2. Download a valid state file first: solo consensus state download
  3. If passing a directory instead, Solo will select node-specific state files from /states//.

4.1.4.23 - SOLO-4024

InvalidStateZipFileNameSoloError — Validation

InvalidStateZipFileNameSoloError

CodeSOLO-4024
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a state zip file name is invalid; the message names it. solo expects state zip files to follow a specific naming convention, so this means the name does not match it.

Troubleshooting Steps

  1. Download a valid state file first: solo consensus state download
  2. Or rename the state zip file to use only letters, numbers, dots, underscores, and hyphens.
  3. The file name must not start with a hyphen and must not contain slashes, spaces, shell syntax, or path traversal.
  4. Example valid name: node1-state.zip

4.1.4.24 - SOLO-4025

ExplorerInvalidComponentIdSoloError — Validation

ExplorerInvalidComponentIdSoloError

CodeSOLO-4025
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an explorer component id is not valid; the message includes the value and its runtime type. solo expects component ids in a specific form, so this means the supplied id is malformed or of the wrong type.

Troubleshooting Steps

  1. Inspect remote config state for corruption: kubectl get configmap solo-remote-config -n -o yaml
  2. Check solo logs for config loading errors: tail -n 100 ~/.solo/logs/solo.log
  3. If the issue persists, this may be an internal bug — report it with your solo log

4.1.4.25 - SOLO-4026

RelayInvalidComponentIdSoloError — Validation

RelayInvalidComponentIdSoloError

CodeSOLO-4026
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a relay component id is not valid; the message includes the value and its runtime type. solo expects component ids in a specific form, so this means the supplied id is malformed or of the wrong type.

Troubleshooting Steps

  1. Inspect remote config state for corruption: kubectl get configmap solo-remote-config -n -o yaml
  2. Check solo logs for config loading errors: tail -n 100 ~/.solo/logs/solo.log
  3. If the issue persists, this may be an internal bug — report it with your solo log

4.1.4.26 - SOLO-4027

OneShotCachedDeploymentNotFoundSoloError — Validation

OneShotCachedDeploymentNotFoundSoloError

CodeSOLO-4027
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a cached one-shot deployment cannot be found; the message carries a hint about what was expected. One-shot mode reuses a cached deployment, so this means none matched — for example it was never created or has been cleared.

Troubleshooting Steps

  1. List available deployments: solo deployment config list
  2. Specify the deployment explicitly with –deployment)

4.1.4.27 - SOLO-4028

MirrorNodeInvalidComponentIdSoloError — Validation

MirrorNodeInvalidComponentIdSoloError

CodeSOLO-4028
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a mirror node component id is not valid; the message includes the value and its runtime type. solo expects component ids in a specific form, so this means the supplied id is malformed or of the wrong type.

Troubleshooting Steps

  1. Inspect remote config state for corruption: kubectl get configmap solo-remote-config -n -o yaml
  2. Check solo logs for config loading errors: tail -n 100 ~/.solo/logs/solo.log
  3. If the issue persists, this may be an internal bug — report it with your solo log

4.1.4.28 - SOLO-4029

BlockNodeLocalImageNotFoundSoloError — Validation

BlockNodeLocalImageNotFoundSoloError

CodeSOLO-4029
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a local block node image with the given tag does not exist; the message names the tag. solo expects the referenced local image to be present (for example built or loaded into the cluster), so this means it is missing — build or load the image, or correct the tag.

Troubleshooting Steps

  1. Verify the image exists locally: docker images | grep
  2. Pull the image if missing: docker pull /block-node:
  3. Ensure the tag is a valid semantic version

4.1.4.29 - SOLO-4030

BlockNodeInvalidComponentIdSoloError — Validation

BlockNodeInvalidComponentIdSoloError

CodeSOLO-4030
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a block node component id is not the expected type or format; the message includes the value and its runtime type. solo expects component ids in a specific form, so an invalid value passed internally points to a defect in the calling code and is treated as an internal Solo error.

Troubleshooting Steps

  1. Inspect remote config for corruption: kubectl get configmap solo-remote-config -n -o yaml
  2. Check solo logs for config loading errors: tail -n 100 ~/.solo/logs/solo.log
  3. If the issue persists, this may be an internal bug — report it with your solo log

4.1.4.30 - SOLO-4033

InvalidHbarAmountSoloError — Validation

InvalidHbarAmountSoloError

CodeSOLO-4033
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an HBAR amount is invalid; the message includes the offending value. solo parses HBAR amounts from flags and config, so this means the value is not a valid amount — for example non-numeric, or negative where it is not allowed.

Troubleshooting Steps

  1. Provide a valid positive numeric HBAR amount (e.g., 100 or 0.5)
  2. Run solo ledger account create –help for usage information

4.1.4.31 - SOLO-4034

InvalidFileIdFormatSoloError — Validation

InvalidFileIdFormatSoloError

CodeSOLO-4034
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a file ID is not in the expected 0.0.<number> format; the message includes the offending value and an example. solo parses Hedera file IDs from input, so this means the value is malformed.

Troubleshooting Steps

  1. Provide a file ID in the format 0.0. (e.g., 0.0.150)
  2. Run solo ledger file –help for usage information

4.1.4.32 - SOLO-4035

InvalidEndpointFormatSoloError — Validation

InvalidEndpointFormatSoloError

CodeSOLO-4035
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an endpoint is not in the expected url:port format; the message includes the offending value. solo parses endpoints from flags and config, so this means the value is malformed — provide it as url:port.

Troubleshooting Steps

  1. Provide the endpoint in url:port format (e.g., 127.0.0.1:50211)
  2. Run solo –help for usage information

4.1.4.33 - SOLO-4036

InvalidCommaSeparatedStringSoloError — Validation

InvalidCommaSeparatedStringSoloError

CodeSOLO-4036
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an input is not a valid comma-separated string; the message includes the offending value. solo parses comma-separated lists from flags and config, so this means the value could not be parsed as such — for example stray separators or empty entries.

Troubleshooting Steps

  1. Provide a comma-separated list of values (e.g., node1,node2,node3)
  2. Do not include spaces around commas unless they are part of the values

4.1.4.34 - SOLO-4037

InvalidConfigNumberValueSoloError — Validation

InvalidConfigNumberValueSoloError

CodeSOLO-4037
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a numeric configuration value cannot be parsed; the message names the value and wraps the underlying failure in cause. solo expects a number here, so this means the provided value is not numeric or is not in the accepted form.

Troubleshooting Steps

  1. Provide a valid integer or decimal number for this configuration option
  2. Run solo –help for usage information

4.1.4.35 - SOLO-4038

InvalidStorageTypeSoloError — Validation

InvalidStorageTypeSoloError

CodeSOLO-4038
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a storage type value is invalid; the message includes the offending value. solo accepts a fixed set of storage types, so this means the supplied value is not one of them.

Troubleshooting Steps

  1. Provide a valid storage type value
  2. Run solo –help for usage information and supported storage types

4.1.4.36 - SOLO-4039

UnsupportedFlagFieldTypeSoloError — Validation

UnsupportedFlagFieldTypeSoloError

CodeSOLO-4039
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a flag is declared with a field type solo does not support; the message names the flag and the field type. solo maps flag field types to handling logic, so an unsupported type indicates an internal flag-definition defect and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.37 - SOLO-4040

VersionDowngradeBlockedSoloError — Validation

VersionDowngradeBlockedSoloError

CodeSOLO-4040
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an upgrade target version is older than the currently deployed version; the message names the component, the target and current versions, and the flag to use. solo blocks downgrades to prevent accidental rollbacks, so this means the requested version is too old — choose a version equal to or newer than the deployed one.

Troubleshooting Steps

  1. Specify a version equal to or newer than the currently deployed version () using
  2. Downgrades are not supported — check the available releases before upgrading

4.1.4.38 - SOLO-4041

AdminKeysCountMismatchSoloError — Validation

AdminKeysCountMismatchSoloError

CodeSOLO-4041
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the number of admin public keys provided does not match the number of consensus nodes; the message reports both counts. solo expects one DER-encoded ED25519 public key per node, so this means the supplied comma-separated list is the wrong length — provide exactly one key per node.

Troubleshooting Steps

  1. Provide exactly comma-separated DER encoded ED25519 public keys, one for each consensus node
  2. Run solo consensus network deploy –help for usage information

4.1.4.39 - SOLO-4042

ComponentAlreadyExistsSoloError — Validation

ComponentAlreadyExistsSoloError

CodeSOLO-4042
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a component being added already exists in the remote configuration; the message names the component id. solo expects to add each component once, so a duplicate id at this point indicates an internal bookkeeping defect and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.40 - SOLO-4043

ComponentIdRequiredSoloError — Validation

ComponentIdRequiredSoloError

CodeSOLO-4043
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a component id is required but was not provided; the message echoes the value. solo needs an id to locate or record a component, so a missing value passed internally points to a defect in the calling code and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.41 - SOLO-4044

ComponentNotFoundSoloError — Validation

ComponentNotFoundSoloError

CodeSOLO-4044
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a component cannot be found during an operation; the message names the component id, its type, and the operation attempted. solo expected the component to be present at this point, so its absence indicates an internal inconsistency and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.42 - SOLO-4045

ComponentNotInRemoteConfigSoloError — Validation

ComponentNotInRemoteConfigSoloError

CodeSOLO-4045
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a component of a given type and id is not present in the remote configuration; the message names both. solo expected the component to be recorded, so its absence here indicates an internal inconsistency and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.43 - SOLO-4046

UnknownComponentTypeSoloError — Validation

UnknownComponentTypeSoloError

CodeSOLO-4046
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when solo encounters a component type it does not recognize; the message names the type and, when present, the component id. solo dispatches on known component types, so an unknown value indicates an internal inconsistency and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.44 - SOLO-4047

ConfigFileInvalidSoloError — Validation

ConfigFileInvalidSoloError

CodeSOLO-4047
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a configuration file is empty or contains invalid content. solo reads this file to drive a command, so this means it had no usable content — for example an empty file or content that does not match the expected format.

Troubleshooting Steps

  1. Verify the configuration file is a valid YAML or JSON document
  2. Check that the file is not empty and contains the expected fields
  3. Run solo config ops backup to export a valid configuration for reference

4.1.4.45 - SOLO-4048

MultipleClustersFoundSoloError — Validation

MultipleClustersFoundSoloError

CodeSOLO-4048
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when several clusters are available but none was selected; the message lists them. solo cannot guess which cluster to use, so it asks you to disambiguate with --cluster-ref.

Troubleshooting Steps

  1. Specify the cluster reference using the –cluster-ref flag
  2. List available cluster references: solo cluster-ref config list

4.1.4.46 - SOLO-4049

CacheNotMaterializedSoloError — Validation

CacheNotMaterializedSoloError

CodeSOLO-4049
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the cache is used before it has been materialized. solo requires the cache to be populated before it can be read, so this means a read happened too early in the workflow — materialize the cache first.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Run the cache pull step before using cached images: solo cache image –help

4.1.4.47 - SOLO-4050

CacheImageTemplateUnknownSoloError — Validation

CacheImageTemplateUnknownSoloError

CodeSOLO-4050
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a cache image template key is not recognized; the message names the key. solo resolves image versions against a known set of template keys, so this means the supplied key is not one of them — for example a typo or an unsupported template.

Troubleshooting Steps

  1. Verify the cache image template key is correct in your configuration
  2. Declare the template in the templates section before using it in version fields

4.1.4.48 - SOLO-4051

InvalidKindNodeImageSoloError — Validation

InvalidKindNodeImageSoloError

CodeSOLO-4051
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a Kind node image reference is invalid; the message includes the offending value. solo uses this image to create the Kind cluster nodes, so this means the reference is malformed — provide a valid image reference.

Troubleshooting Steps

  1. Provide a valid Kind node image reference (e.g., kindest/node:v1.27.0)
  2. Check the Kind documentation for supported image formats

4.1.4.49 - SOLO-4052

PathTraversalDetectedSoloError — Validation

PathTraversalDetectedSoloError

CodeSOLO-4052
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a resolved path falls outside the allowed base directory; the message names the resolved path and the base. solo blocks path traversal for safety, so this means the supplied path escaped the permitted directory — for example .. segments or an absolute path outside the base.

Troubleshooting Steps

  1. Provide a path that is within the allowed base directory
  2. Avoid using “..” path components that escape the base directory

4.1.4.50 - SOLO-4053

NodeAliasesMustBeArraySoloError — Validation

NodeAliasesMustBeArraySoloError

CodeSOLO-4053
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a node-aliases value is not an array of strings where one was required. solo expects this value to already be normalized to an array internally, so a non-array here points to a defect in the calling code and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.51 - SOLO-4054

UnknownNodeAliasSoloError — Validation

UnknownNodeAliasSoloError

CodeSOLO-4054
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when solo cannot resolve a node ID from a node alias; the message names the alias. solo maps aliases to node IDs, so this means the alias is not recognized — for example a typo or an alias not present in the deployment.

Troubleshooting Steps

  1. Verify the node alias ‘’ is registered in the current deployment
  2. Check registered nodes: solo deployment config info

4.1.4.52 - SOLO-4055

NodeAliasInferenceFailedSoloError — Validation

NodeAliasInferenceFailedSoloError

CodeSOLO-4055
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when solo cannot infer a node alias from address data; the message includes the offending data. solo derives aliases from address-book data, so this means the data did not yield a usable alias — for example a malformed or unexpected entry.

Troubleshooting Steps

  1. Verify the address data format is correct
  2. Ensure the address book contains valid node alias information

4.1.4.53 - SOLO-4056

NodeAliasParseFailedSoloError — Validation

NodeAliasParseFailedSoloError

CodeSOLO-4056
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when solo cannot parse a node alias from input; the message includes the offending value. solo parses node aliases from flags and config, so this means the value could not be parsed as an alias.

Troubleshooting Steps

  1. Verify the node alias format (expected: node where N is a positive integer)
  2. Check deployment configuration for valid node aliases: solo deployment config info

4.1.4.54 - SOLO-4057

DomainNameParseFailedSoloError — Validation

DomainNameParseFailedSoloError

CodeSOLO-4057
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when solo cannot parse a domain name from the provided data; the message includes the offending input. solo parses domain names from configuration and flags, so this means the value is not a parseable domain — for example a malformed or empty value.

Troubleshooting Steps

  1. Verify the domain name format is correct
  2. Check the address book configuration for valid domain names

4.1.4.55 - SOLO-4058

UnknownTemplateDependencySoloError — Validation

UnknownTemplateDependencySoloError

CodeSOLO-4058
CategoryValidation
OwnershipSolo
RetryableNo

Description

Thrown when a template references a dependency solo does not know; the message names the dependency. Templates may only reference declared dependencies, so an unknown one indicates an internal template defect and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.4.56 - SOLO-4059

NoConsensusNodesFoundSoloError — Validation

NoConsensusNodesFoundSoloError

CodeSOLO-4059
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when no consensus nodes are found to operate on. solo derives the node set from the deployment and --node-aliases, so this means neither yielded any nodes — check your deployment or the --node-aliases input.

Troubleshooting Steps

  1. Verify the deployment has consensus nodes configured: solo deployment config info
  2. Deploy consensus nodes: solo consensus node setup
  3. Use –node-aliases to specify target nodes explicitly

4.1.4.57 - SOLO-4060

ServiceTypeMismatchSoloError — Validation

ServiceTypeMismatchSoloError

CodeSOLO-4060
CategoryValidation
OwnershipInfrastructure
RetryableNo

Description

Thrown when a Kubernetes service is not the expected network-node service; the message names the service. solo expects a service of a specific kind when resolving node endpoints, so this means the service exists but is of the wrong type — indicating an unexpected cluster state.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect Kubernetes services: kubectl get svc -n
  3. Verify the network is deployed correctly: solo consensus network deploy

4.1.4.58 - SOLO-4061

BackupConfigNotFoundSoloError — Validation

BackupConfigNotFoundSoloError

CodeSOLO-4061
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the backup configuration file does not exist; the message names the path. solo reads this file to run a backup or restore, so this means it is missing or the path is wrong — for example a typo or a file that was moved.

Troubleshooting Steps

  1. Verify the configuration file exists at:
  2. Export a new backup to generate a configuration file: solo config ops backup

4.1.4.59 - SOLO-4062

BackupConfigInvalidSoloError — Validation

BackupConfigInvalidSoloError

CodeSOLO-4062
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the backup configuration file is empty or invalid. solo reads this file to drive a backup or restore, so this means it contained no usable configuration — for example an empty file or content that does not match the expected format.

Troubleshooting Steps

  1. Verify the configuration file is a valid YAML or JSON document and is not empty
  2. Export a new backup to generate a valid configuration file: solo config ops backup

4.1.4.60 - SOLO-4063

BackupConfigReadFailedSoloError — Validation

BackupConfigReadFailedSoloError

CodeSOLO-4063
CategoryValidation
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot read the backup configuration file; the message names the path and wraps the underlying failure in cause. solo reads this file during restore, so this means it could not be read — for example missing permissions or an I/O error.

Troubleshooting Steps

  1. Verify the file exists and is readable:
  2. Check file permissions
  3. Export a new backup to regenerate the configuration file: solo config ops backup

4.1.4.61 - SOLO-4064

BackupConfigMapKeyMissingSoloError — Validation

BackupConfigMapKeyMissingSoloError

CodeSOLO-4064
CategoryValidation
OwnershipInfrastructure
RetryableNo

Description

Thrown when the backup ConfigMap does not contain a required key; the message names the missing key. solo reads specific keys from the backup ConfigMap during restore, so this means the ConfigMap exists but is missing data it needs — indicating an incomplete or unexpected backup source.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the Kubernetes ConfigMap contains the expected data
  3. Re-export the backup to regenerate the ConfigMap: solo config ops backup

4.1.4.62 - SOLO-4065

BackupConfigParseFailedSoloError — Validation

BackupConfigParseFailedSoloError

CodeSOLO-4065
CategoryValidation
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot parse the backup configuration; the underlying failure is wrapped in cause. solo parses the backup configuration to drive a restore, so this means the content could not be parsed — for example malformed YAML or an unexpected structure.

Troubleshooting Steps

  1. Verify the backup configuration file is valid YAML or JSON
  2. Check that the configuration was exported with a compatible Solo version
  3. Re-export the backup to regenerate the configuration: solo config ops backup –deployment

4.1.4.63 - SOLO-4066

BackupInputDirectoryNotFoundSoloError — Validation

BackupInputDirectoryNotFoundSoloError

CodeSOLO-4066
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the backup input directory does not exist; the message names it. solo reads backup data from this directory during restore, so this means it is missing or the path is wrong.

Troubleshooting Steps

  1. Verify the directory exists at:
  2. Use –input-dir to specify the correct path to the backup directory
  3. Run solo config ops restore-clusters –help for usage information

4.1.4.64 - SOLO-4067

BackupNoClusterDirectoriesSoloError — Validation

BackupNoClusterDirectoriesSoloError

CodeSOLO-4067
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the backup input directory contains no per-cluster directories; the message names the directory. A valid backup groups data under cluster directories, so this means none were found — the directory is not a valid backup or is empty.

Troubleshooting Steps

  1. Verify the input directory contains cluster subdirectories:
  2. Ensure you are pointing to the correct backup directory
  3. Re-export the backup: solo config ops backup

4.1.4.65 - SOLO-4068

BackupClusterValidationFailedSoloError — Validation

BackupClusterValidationFailedSoloError

CodeSOLO-4068
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when a backup input directory does not contain the expected solo-remote-config.yaml; the message names the path and the expected <input-dir>/<cluster-ref>/configmaps/solo-remote-config.yaml structure. solo validates the backup layout before restoring, so this means the directory is not a valid backup or the wrong path was given.

Troubleshooting Steps

  1. Verify the backup archive was exported with compatible Solo and cluster versions
  2. Check cluster references: solo cluster-ref config list
  3. Re-export the backup from the original cluster: solo config ops backup

4.1.4.66 - SOLO-4069

BackupNoClusterInfoSoloError — Validation

BackupNoClusterInfoSoloError

CodeSOLO-4069
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the backup configuration file contains no cluster information. solo reads cluster details from the backup config to restore, so this means that section is missing or empty — indicating an incomplete or invalid backup config.

Troubleshooting Steps

  1. Verify the backup configuration file contains cluster information
  2. Ensure the backup was exported with a compatible Solo version
  3. Re-export the backup: solo config ops backup

4.1.4.67 - SOLO-4070

BackupNoComponentsSoloError — Validation

BackupNoComponentsSoloError

CodeSOLO-4070
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the deployment state to restore contains no components. solo restores components recorded in the backup, so this means none were found to restore — for example an empty or incomplete backup.

Troubleshooting Steps

  1. Verify the backup archive contains component state information
  2. Ensure the backup was exported from a deployment with active components
  3. Re-export the backup: solo config ops backup

4.1.4.68 - SOLO-4071

BackupOptionsFileNotFoundSoloError — Validation

BackupOptionsFileNotFoundSoloError

CodeSOLO-4071
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the restore options file does not exist; the message names it. solo reads restore options from this file, so this means it is missing or the path is wrong.

Troubleshooting Steps

  1. Verify the options file exists at:
  2. Run solo config ops restore-network –help for usage information

4.1.4.69 - SOLO-4072

BackupZipFileRequiredSoloError — Validation

BackupZipFileRequiredSoloError

CodeSOLO-4072
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when --zip-password is used without --zip-file. A password applies to a specific zip archive, so this means the required --zip-file was not provided — supply it or omit the password.

Troubleshooting Steps

  1. Provide the –zip-file flag when using –zip-password
  2. Run solo config ops restore-clusters –help for usage information

4.1.4.70 - SOLO-4073

BackupInputPathNotFoundSoloError — Validation

BackupInputPathNotFoundSoloError

CodeSOLO-4073
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when the backup input path does not exist; the message names it. solo reads the backup from this path, so this means it is missing or the path is wrong.

Troubleshooting Steps

  1. Verify the input path exists:
  2. Use –input-dir or –zip-file to specify the correct backup path
  3. Run solo config ops restore-clusters –help for usage information

4.1.4.71 - SOLO-4074

BackupInputMustBeZipSoloError — Validation

BackupInputMustBeZipSoloError

CodeSOLO-4074
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when --zip-password is used but the input path is not a .zip file. A password only applies to a zip archive, so this means the supplied input is not a zip — provide a .zip file or omit the password.

Troubleshooting Steps

  1. Provide a .zip archive as the input path when using –zip-password
  2. Run solo config ops restore-clusters –help for usage information

4.1.4.72 - SOLO-4075

BackupNoLogFilesSoloError — Validation

BackupNoLogFilesSoloError

CodeSOLO-4075
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when no log files are found to restore for a context; the message names the context. solo restores log files captured in the backup, so this means none were present for that context.

Troubleshooting Steps

  1. Verify the backup archive contains log files for context ‘’
  2. Check the backup directory structure for expected log files
  3. Re-export the backup to include log files: solo config ops backup

4.1.4.73 - SOLO-4076

FlagInputFailedSoloError — Validation

FlagInputFailedSoloError

CodeSOLO-4076
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when input validation for a flag fails; the message names the flag and wraps the underlying failure in cause. solo validates and coerces flag inputs before using them, so this means the provided value did not pass validation — correct the flag value.

Troubleshooting Steps

  1. Verify the value provided for – is valid
  2. Run solo –help for usage information and accepted flag values

4.1.4.74 - SOLO-4077

ConfirmationRequiredSoloError — Validation

ConfirmationRequiredSoloError

CodeSOLO-4077
CategoryValidation
OwnershipUser
RetryableNo

Description

Thrown when an action requires interactive confirmation but solo cannot ask for it (for example when running with –quiet or –force, or in a non-interactive environment such as CI). Rather than proceed without the user’s consent, solo refuses and asks the user to confirm interactively.

Troubleshooting Steps

  1. Re-run the command interactively (without –quiet or –force) so the confirmation prompt can be shown

4.1.5 - System

4.1.5.1 - SOLO-5001

ResourceNotFoundError — System

ResourceNotFoundError

CodeSOLO-5001
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when an expected resource cannot be found; the message names the resource and, when available, wraps the underlying cause. solo looks up Kubernetes and related resources by name as it works, so this means the resource was absent where it was expected — for example it was not yet created, was deleted, or was searched for in the wrong place.

Troubleshooting Steps

  1. Make sure the requested resource exists and is reachable, if not file a bug report: https://github.com/hiero-ledger/solo/issues

4.1.5.2 - SOLO-5002

ClusterConnectionFailedError — System

ClusterConnectionFailedError

CodeSOLO-5002
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot establish a connection to the Kubernetes API server for a cluster reference; the message names the cluster reference and the kubeconfig context it tried. solo resolves the context from kubeconfig and connects before running any cluster operation, so this fires when that handshake fails: the context names a server that is unreachable or no longer exists, the cluster has not been started yet (for example a Kind cluster that was never created or was deleted), credentials have expired, or a transient network/DNS problem interrupted the call. It is retryable because a cluster that is still coming up, or a brief network blip, often resolves on a later attempt.

Troubleshooting Steps

  1. Verify the kubeconfig context is correct and the cluster is reachable: kubectl cluster-info –context

4.1.5.3 - SOLO-5003

PortForwardRefreshFailedError — System

PortForwardRefreshFailedError

CodeSOLO-5003
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot refresh its port-forwards; when available the underlying failure is wrapped in cause. solo periodically re-establishes port-forwards so endpoints stay reachable, so this means that refresh failed — for example a target pod was unavailable or the API connection dropped. It is retryable.

Troubleshooting Steps

  1. Check the all pods exist and are running: kubectl get pods -n
  2. Check the port-forwards of your deployment: solo deployment config ports –deployment
  3. Restart the port-forward: solo deployment refresh port-forwards –deployment

4.1.5.4 - SOLO-5004

PortForwardStatusFailedError — System

PortForwardStatusFailedError

CodeSOLO-5004
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot display port-forward status; when available the underlying failure is wrapped in cause. solo reads the state of active port-forwards to report it, so this means that status query failed — for example the cluster API was unreachable. It is retryable.

Troubleshooting Steps

  1. Check the all pods exist and are running: kubectl get pods -n
  2. Restart the port-forward: solo deployment refresh port-forwards –deployment

4.1.5.5 - SOLO-5005

NamespaceNotFoundSoloError — System

NamespaceNotFoundSoloError

CodeSOLO-5005
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a referenced Kubernetes namespace does not exist; the message names the namespace. solo operates within a deployment namespace, so this means the namespace is absent — for example it was never created, was deleted, or the wrong name was supplied.

Troubleshooting Steps

  1. List existing namespaces: kubectl get namespaces
  2. Check the active deployment: solo deployment config info –deployment
  3. Redeploy the network to re-create the namespace: solo consensus network deploy

4.1.5.6 - SOLO-5006

PodNotFoundSoloError — System

PodNotFoundSoloError

CodeSOLO-5006
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo queries Kubernetes for the pod backing a consensus node alias and the lookup returns no pod; the message names the alias. solo needs the pod to run commands, copy files, or check status on a node, so this fires when no pod matches the expected labels in the namespace. Because pod scheduling is asynchronous, it can appear briefly during startup before the pod exists, which is why it is retryable; if it persists, the pod failed to schedule or start, was evicted, or the node was never deployed. This is the base error for the component-specific variants (explorer, relay, mirror-node, block-node, and Postgres pod-not-found errors).

Troubleshooting Steps

  1. Check pod status: kubectl get pods -n -l solo.hedera.com/node-name=
  2. Describe the pod for events: kubectl describe pod -n -l solo.hedera.com/node-name=
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.5.7 - SOLO-5007

HaproxyPodsNotFoundSoloError — System

HaproxyPodsNotFoundSoloError

CodeSOLO-5007
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot find any HAProxy pods. solo relies on HAProxy pods to route traffic to consensus nodes, so this is raised when none are present in the namespace. It is retryable because the pods may still be scheduling; if it persists, HAProxy failed to start or was not deployed.

Troubleshooting Steps

  1. Check HAProxy pod status: kubectl get pods -n -l solo.hedera.com/type=haproxy
  2. Check the active deployment: solo deployment config info –deployment
  3. Redeploy the network if HAProxy is missing: solo consensus network deploy

4.1.5.8 - SOLO-5008

LoadBalancerNotFoundSoloError — System

LoadBalancerNotFoundSoloError

CodeSOLO-5008
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot find the expected load balancer. solo looks up the load balancer that exposes a service externally, so this is raised when none is present yet. It is retryable because the load balancer may still be provisioning (for example waiting on MetalLB or a cloud provider); a persistent failure points to a networking misconfiguration.

Troubleshooting Steps

  1. Check load balancer service status: kubectl get svc -n -l solo.hedera.com/type=network-node
  2. Ensure your cloud provider supports LoadBalancer services
  3. Review cloud provisioning logs for LB assignment delays

4.1.5.9 - SOLO-5009

KubeContextNotFoundSoloError — System

KubeContextNotFoundSoloError

CodeSOLO-5009
CategorySystem
OwnershipSolo
RetryableNo

Description

Thrown when solo cannot determine the Kubernetes context for a node; the message names the node alias. By this point the node context should already be resolvable from configuration, so reaching it indicates an internal inconsistency and is treated as an internal Solo error.

Troubleshooting Steps

  1. Check active deployments: solo deployment config info
  2. Verify that the node alias is registered: kubectl get configmap -n -o yaml
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.5.10 - SOLO-5010

ConsensusNodeNotInConfigSoloError — System

ConsensusNodeNotInConfigSoloError

CodeSOLO-5010
CategorySystem
OwnershipSolo
RetryableNo

Description

Thrown when solo looks up a consensus node by alias but it is not present in the configuration; the message names the alias. By this point the node should already be known, so reaching it indicates an internal inconsistency between the requested alias and the loaded configuration, and is treated as an internal Solo error.

Troubleshooting Steps

  1. List registered nodes: solo deployment config info –deployment
  2. Verify the node alias: kubectl get configmap -n -o yaml | grep nodeAlias
  3. Re-run with a valid alias: solo node –node-aliases

4.1.5.11 - SOLO-5011

K8sSecretCreateFailedSoloError — System

K8sSecretCreateFailedSoloError

CodeSOLO-5011
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot create a Kubernetes secret; the message describes the secret and, when available, wraps the underlying cause. solo stores keys and credentials as cluster secrets, so this means the secret could not be created — for example the namespace is missing, the API rejected the request, or a transient API error occurred. It is retryable.

Troubleshooting Steps

  1. Check RBAC permissions: kubectl auth can-i create secrets -n
  2. Inspect existing secrets: kubectl get secrets -n
  3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log
  4. Verify the cluster is reachable: kubectl cluster-info –context

4.1.5.12 - SOLO-5012

StatesDirectoryNotFoundSoloError — System

StatesDirectoryNotFoundSoloError

CodeSOLO-5012
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when the states directory for a node does not exist; the message names the node alias and the expected directory. solo reads saved consensus state from this directory, so this means it is missing or the path is wrong — for example no state was exported for the node, or the wrong path was supplied.

Troubleshooting Steps

  1. Verify the states directory exists: ls -la
  2. Check that the state download succeeded: solo consensus node states
  3. Use the correct –inputDir path structure: /states///

4.1.5.13 - SOLO-5013

PortForwardMissingSoloError — System

PortForwardMissingSoloError

CodeSOLO-5013
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when a configured port-forward is not present; the message names the component, its id, and the local-to-pod port mapping. solo expects each configured port-forward to be active so the component is reachable, so this means it is missing — for example it was never established or was dropped. It is retryable, since re-establishing the port-forward often succeeds.

Troubleshooting Steps

  1. Check port-forward status: solo deployment diagnostics connections –deployment
  2. Re-establish port forwards: solo consensus node start
  3. Verify the pod is running: kubectl get pods -n

4.1.5.14 - SOLO-5014

NoPvcFoundSoloError — System

NoPvcFoundSoloError

CodeSOLO-5014
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when no PersistentVolumeClaims are found in a namespace where they were expected; the message names the namespace. Some operations require PVCs that are created only when persistent storage is enabled at deployment, so this means PVCs were not enabled for the network — redeploy with PVCs enabled.

Troubleshooting Steps

  1. Redeploy with PVCs enabled: solo consensus network deploy –pvcs true

4.1.5.15 - SOLO-5015

ClusterReferenceUndeterminedSoloError — System

ClusterReferenceUndeterminedSoloError

CodeSOLO-5015
CategorySystem
OwnershipSolo
RetryableNo

Description

Thrown during initialization when solo cannot determine which cluster reference to use. solo expects the active cluster reference to be resolvable at this point, so reaching this indicates an internal initialization or ordering defect rather than user input, and is treated as an internal Solo error.

Troubleshooting Steps

  1. Check the remote config: kubectl get configmap -n -o yaml
  2. Verify cluster references: solo deployment config info –deployment
  3. Re-initialize solo if needed: solo init
  4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.5.16 - SOLO-5016

UpgradeVersionFetchFailedSoloError — System

UpgradeVersionFetchFailedSoloError

CodeSOLO-5016
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot fetch a requested upgrade version; the message names the version and wraps the underlying failure in cause. solo downloads upgrade artifacts for the chosen version, so this means the fetch did not complete — for example the version assets were unreachable or the download errored. It is retryable, since transient network issues often clear on a later attempt.

Troubleshooting Steps

  1. Check internet connectivity
  2. Verify the version exists: https://github.com/hashgraph/hedera-services/releases
  3. Retry the upgrade: solo consensus network upgrade –upgrade-version

4.1.5.17 - SOLO-5017

MultipleDeploymentsFoundSoloError — System

MultipleDeploymentsFoundSoloError

CodeSOLO-5017
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a command needs a single deployment but several are configured and none was selected; the message names the source (local or remote) and the deployments found. solo cannot guess which one to use, so it asks you to disambiguate with --deployment.

Troubleshooting Steps

  1. List existing deployments: solo deployment config list
  2. Specify the deployment explicitly: solo node –deployment

4.1.5.18 - SOLO-5018

GrpcProxyEndpointFailedSoloError — System

GrpcProxyEndpointFailedSoloError

CodeSOLO-5018
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot set the gRPC Web proxy endpoint. solo configures this endpoint so gRPC Web clients can reach the network, so this means that configuration step failed — for example the target service or port-forward was not reachable. It is retryable, since a transient connectivity issue often clears on a later attempt.

Troubleshooting Steps

  1. Check node update transaction logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify gRPC endpoints are reachable: kubectl get svc -n
  3. Retry the node update: solo consensus node update

4.1.5.19 - SOLO-5019

ExplorerPodNotFoundSoloError — System

ExplorerPodNotFoundSoloError

CodeSOLO-5019
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot find a Hiero Explorer pod. solo locates the explorer pod to operate on it or check its status, so this is raised when no matching pod exists in the namespace — for example the explorer failed to start, was removed, or was never deployed.

Troubleshooting Steps

  1. Check pod status: kubectl get pods -A | grep explorer
  2. Describe pods to check for crashes or evictions: kubectl describe pods -A -l app.kubernetes.io/component=hiero-explorer
  3. Check recent namespace events: kubectl get events -n –sort-by=.lastTimestamp

4.1.5.20 - SOLO-5020

ExplorerNotInRemoteConfigSoloError — System

ExplorerNotInRemoteConfigSoloError

CodeSOLO-5020
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when no Hiero Explorer component is present in the deployment remote configuration. solo looks the explorer up in the remote config before acting on it, so this means none is recorded — typically because the explorer was never deployed for this deployment, or was already removed.

Troubleshooting Steps

  1. List components in remote config: solo deployment config info
  2. Deploy the explorer first: solo explorer deploy

4.1.5.21 - SOLO-5021

RelayPodNotFoundSoloError — System

RelayPodNotFoundSoloError

CodeSOLO-5021
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot find a JSON-RPC relay pod. solo locates the relay pod to operate on it or check status, so this is raised when no matching pod exists in the namespace — for example the relay failed to start, was removed, or was never deployed.

Troubleshooting Steps

  1. Check pod status: kubectl get pods -A | grep relay
  2. Describe pods to check for crashes or evictions: kubectl describe pods -A -l app.kubernetes.io/instance=relay-
  3. Check recent namespace events: kubectl get events -n –sort-by=.lastTimestamp

4.1.5.22 - SOLO-5022

RelayNotInRemoteConfigSoloError — System

RelayNotInRemoteConfigSoloError

CodeSOLO-5022
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when no JSON-RPC relay is present in the deployment remote configuration. solo looks the relay up in the remote config before acting on it, so this means none is recorded — typically because it was never deployed for this deployment, or was already removed.

Troubleshooting Steps

  1. List components in remote config: solo deployment config info
  2. Deploy the relay first: solo relay deploy

4.1.5.23 - SOLO-5023

MirrorNodePodsNotFoundSoloError — System

MirrorNodePodsNotFoundSoloError

CodeSOLO-5023
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot find any deployed mirror-node pods; the message names the release and namespace. solo locates the mirror node pods to operate on them, so this is raised when none match in the namespace — for example the release failed to deploy, was removed, or the wrong release or namespace was targeted.

Troubleshooting Steps

  1. Check pod status: kubectl get pods -n | grep
  2. Inspect Helm release: helm status -n

4.1.5.24 - SOLO-5024

MirrorIngressControllerPodNotFoundSoloError — System

MirrorIngressControllerPodNotFoundSoloError

CodeSOLO-5024
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot find the mirror ingress controller pod. solo locates this pod to manage ingress for the mirror node, so this is raised when no matching pod exists in the namespace — for example it failed to start or was not deployed.

Troubleshooting Steps

  1. Check ingress controller pod status: kubectl get pods -A | grep ingress
  2. Describe pods to check for crashes or evictions: kubectl describe pods -A -l app.kubernetes.io/name=haproxy-ingress
  3. Check recent namespace events: kubectl get events -n –sort-by=.lastTimestamp

4.1.5.25 - SOLO-5025

MirrorNodeNotInRemoteConfigSoloError — System

MirrorNodeNotInRemoteConfigSoloError

CodeSOLO-5025
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when no mirror node is present in the deployment remote configuration. solo looks the mirror node up in the remote config before acting on it, so this means none is recorded — typically because it was never deployed for this deployment, or was already removed.

Troubleshooting Steps

  1. List components in remote config: solo deployment config info
  2. Deploy the mirror node first: solo mirror node add –deployment

4.1.5.26 - SOLO-5026

ClusterNotFoundInRemoteConfigSoloError — System

ClusterNotFoundInRemoteConfigSoloError

CodeSOLO-5026
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a referenced cluster is not present in the deployment remote configuration; the message names the cluster reference. solo expects the cluster to be recorded in the remote config before acting on it, so this means the reference does not match any recorded cluster — typically a misspelled name or a cluster that was never attached to the deployment.

Troubleshooting Steps

  1. List configured cluster references: solo cluster-ref list
  2. Inspect the remote config to see which clusters block nodes reference: kubectl get configmap solo-remote-config -n -o yaml
  3. If the cluster was renamed or removed, the deployment config may need to be repaired

4.1.5.27 - SOLO-5027

GitHubApiRequestFailedError — System

GitHubApiRequestFailedError

CodeSOLO-5027
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when a GitHub API request cannot be completed; the message names the URL and wraps the underlying failure in cause. The request did not produce a usable HTTP response at all — for example a network or DNS failure, or a dropped connection. It is retryable, since transient network problems often clear on a later attempt.

Troubleshooting Steps

  1. Check network connectivity and GitHub availability, then retry. If the issue persists, confirm proxy/firewall settings.

4.1.5.28 - SOLO-5028

GitHubApiHttpResponseError — System

GitHubApiHttpResponseError

CodeSOLO-5028
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when a GitHub API request returns a non-success HTTP status; the message names the URL and the status code. solo calls the GitHub API to discover releases and download assets, so this means GitHub responded with an error status — for example rate limiting, a missing resource, or a server error. It is retryable, since transient statuses such as rate limits often clear on a later attempt.

Troubleshooting Steps

  1. Verify GitHub API accessibility and credentials/rate limits, then retry.

4.1.5.29 - SOLO-5029

GitHubApiResponseParseFailedError — System

GitHubApiResponseParseFailedError

CodeSOLO-5029
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot parse a GitHub API response; the message names the URL and wraps the underlying failure in cause. solo parses release metadata from the API, so this means the body could not be parsed — for example it was not valid JSON or did not match the expected structure.

Troubleshooting Steps

  1. Inspect the GitHub API response shape and endpoint contract.

4.1.5.30 - SOLO-5030

GitHubApiResponseMissingTagNameError — System

GitHubApiResponseMissingTagNameError

CodeSOLO-5030
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when a GitHub API response is missing the expected tag_name field; the message names the URL. solo reads tag_name to identify a release version, so this means the response came back without it — indicating an unexpected response shape from the API.

Troubleshooting Steps

  1. Confirm the repository has a latest release and that the GitHub API response contains expected release fields.

4.1.5.31 - SOLO-5031

BlockNodePodNotFoundSoloError — System

BlockNodePodNotFoundSoloError

CodeSOLO-5031
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot find a running block node pod. solo locates the block node pod to run commands or check its status, so this is raised when no matching pod exists in the namespace. It is retryable because pod scheduling is asynchronous and the pod may appear shortly; if it persists, the block node failed to start or was never deployed.

Troubleshooting Steps

  1. Check pod status: kubectl get pods -A -l block-node.hiero.com/type=block-node
  2. Describe pods to check for crashes or evictions: kubectl describe pods -A -l block-node.hiero.com/type=block-node
  3. Check recent namespace events: kubectl get events -n –sort-by=.lastTimestamp

4.1.5.32 - SOLO-5032

BlockNodeNotReadySoloError — System

BlockNodeNotReadySoloError

CodeSOLO-5032
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when a deployed block node does not become ready; the message names the release and wraps the underlying failure in cause. solo waits for the block node pods to reach a Ready state, so this means that wait did not succeed. It is retryable, since a block node that is merely slow to start often becomes ready on a later attempt; a persistent failure points to a crash-looping or misconfigured block node.

Troubleshooting Steps

  1. Check block node pod status: kubectl get pods -A | grep
  2. Describe pods for readiness probe failures: kubectl describe pods -A -l app.kubernetes.io/instance=
  3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.5.33 - SOLO-5033

BlockNodeNotInRemoteConfigSoloError — System

BlockNodeNotInRemoteConfigSoloError

CodeSOLO-5033
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a referenced block node is not present in the deployment remote configuration; when provided, the message includes its identifier. solo looks components up in the remote config before acting on them, so this means the block node id does not match any recorded component — typically because it was never added, was already removed, or the wrong id was supplied.

Troubleshooting Steps

  1. List all registered components: solo deployment config info
  2. Verify you are targeting the correct deployment and namespace
  3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.5.34 - SOLO-5034

ExternalBlockNodeNotInRemoteConfigSoloError — System

ExternalBlockNodeNotInRemoteConfigSoloError

CodeSOLO-5034
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a referenced external block node is not present in the deployment remote configuration; when provided, the message includes its id. solo looks external block nodes up in the remote config before acting on them, so this means the id does not match any recorded external block node — typically because it was never added or the wrong id was supplied.

Troubleshooting Steps

  1. Register the external block node first: solo block node add-external
  2. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.5.35 - SOLO-5035

HelmRepoSetupFailedSoloError — System

HelmRepoSetupFailedSoloError

CodeSOLO-5035
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot set up the Helm chart repositories; the underlying failure is wrapped in cause. solo adds and updates the repositories its charts come from, so this means that setup failed — for example a repository URL was unreachable or the Helm CLI errored.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List configured Helm repositories: helm repo list
  3. Verify network connectivity to chart repository URLs
  4. Update Helm repositories: helm repo update

4.1.5.36 - SOLO-5036

HelmRepoCheckFailedSoloError — System

HelmRepoCheckFailedSoloError

CodeSOLO-5036
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot check the configured Helm chart repositories; the underlying failure is wrapped in cause. solo verifies repositories before installing charts from them, so this means that check failed — for example the Helm CLI errored or a repository was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. List configured Helm repositories: helm repo list
  3. Verify network connectivity to chart repository URLs
  4. Update Helm repositories: helm repo update

4.1.5.37 - SOLO-5037

HelmChartListFailedSoloError — System

HelmChartListFailedSoloError

CodeSOLO-5037
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot list installed Helm charts; the underlying failure is wrapped in cause. solo lists releases to check what is installed, so this means the helm list failed — for example the Helm CLI errored or the cluster API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Kubernetes connectivity: kubectl cluster-info
  3. List Helm releases manually: helm list -A

4.1.5.38 - SOLO-5038

HelmChartGenericInstallFailedSoloError — System

HelmChartGenericInstallFailedSoloError

CodeSOLO-5038
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot install a Helm chart release; the message names the release and wraps the underlying failure in cause. This is the generic install failure used by the Helm client, so it means the helm install did not succeed — for example a bad chart version or values, an image that cannot be pulled, or a cluster that is unreachable or short on resources.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect the Helm release: helm status -n
  3. Check Helm release history: helm history -n
  4. Inspect failing pods: kubectl get pods -A

4.1.5.39 - SOLO-5039

HelmChartUninstallFailedSoloError — System

HelmChartUninstallFailedSoloError

CodeSOLO-5039
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot uninstall a Helm chart release; the message names the release and wraps the underlying failure in cause. solo uninstalls releases during teardown, so this means the helm uninstall did not complete — for example the release was not found, a resource could not be deleted, or the cluster API was unreachable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Check if the release still exists: helm list -n
  3. Inspect the release status: helm status -n
  4. Check remaining pods: kubectl get pods -A

4.1.5.40 - SOLO-5040

HelmChartUpgradeFailedSoloError — System

HelmChartUpgradeFailedSoloError

CodeSOLO-5040
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot upgrade a Helm chart release; the message names the release and wraps the underlying failure in cause. solo upgrades releases to change chart version or values, so this means the helm upgrade did not succeed — for example a bad chart or values, an image that cannot be pulled, or a cluster issue.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect the release status: helm status -n
  3. Review upgrade history: helm history -n
  4. Check failing pods: kubectl get pods -A

4.1.5.41 - SOLO-5041

FileNotFoundSoloError — System

FileNotFoundSoloError

CodeSOLO-5041
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a file solo was asked to use does not exist; the message names the path. solo reads files from paths provided on the command line or in configuration, so this means the file is missing or the path is wrong — for example a typo or a file that was moved or deleted.

Troubleshooting Steps

  1. Verify the file exists at:
  2. Check the path is correct and the file has not been deleted

4.1.5.42 - SOLO-5042

FileCopyFailedSoloError — System

FileCopyFailedSoloError

CodeSOLO-5042
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when a file copy operation fails; the underlying failure is wrapped in cause. solo copies files between local paths and pods during setup, so this means the copy did not complete — for example the source was unreadable, the destination was not writable, or the connection dropped.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the source file exists and is readable
  3. Check that the destination directory exists and is writable
  4. Verify sufficient disk space is available

4.1.5.43 - SOLO-5043

FileEmptySoloError — System

FileEmptySoloError

CodeSOLO-5043
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a file solo was asked to read is empty; the message names the path. solo expects the referenced file to contain data, so this means it exists but has no content — for example the wrong file was supplied or it was not fully written.

Troubleshooting Steps

  1. Verify the file contains valid content:
  2. The file must not be empty to be processed

4.1.5.44 - SOLO-5044

FileInvalidJsonSoloError — System

FileInvalidJsonSoloError

CodeSOLO-5044
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when a file solo was asked to parse does not contain valid JSON; the message names the path. solo parses JSON from user-provided files, so this means the content could not be parsed — for example a syntax error, a truncated file, or a non-JSON file supplied.

Troubleshooting Steps

  1. Verify the file at contains valid JSON
  2. Check for syntax errors such as missing commas, brackets, or quotes

4.1.5.45 - SOLO-5045

DirectoryCreationFailedSoloError — System

DirectoryCreationFailedSoloError

CodeSOLO-5045
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot create a directory; the underlying failure is wrapped in cause. solo creates working and output directories as it runs, so this means the directory could not be created — for example missing permissions, a read-only or full disk, or a conflicting existing path.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the parent directory exists and is writable
  3. Check available disk space

4.1.5.46 - SOLO-5046

ArchiveUnzipFailedSoloError — System

ArchiveUnzipFailedSoloError

CodeSOLO-5046
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot unzip an archive; the message names the source and wraps the underlying failure in cause. solo unzips downloaded packages and state archives, so this means the unzip failed — for example the zip is corrupt or truncated, a wrong password was supplied, or the destination could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the archive is a valid zip file:
  3. Ensure the archive is not corrupted
  4. Check available disk space in the destination

4.1.5.47 - SOLO-5047

ArchiveTarFailedSoloError — System

ArchiveTarFailedSoloError

CodeSOLO-5047
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot create a tar archive from a source path; the message names the source and wraps the underlying failure in cause. solo packages directories into tar archives (for example to bundle state or logs), so this means the archiving step failed — for example the source path was unreadable, a file changed during archiving, or the destination could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the source path exists and is readable:
  3. Check available disk space for the output archive

4.1.5.48 - SOLO-5048

ArchiveUntarFailedSoloError — System

ArchiveUntarFailedSoloError

CodeSOLO-5048
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot extract a tar archive; the message names the archive and wraps the underlying failure in cause. solo unpacks tar archives it downloads or restores, so this means extraction failed — for example the archive is corrupt or truncated, or the destination directory could not be written.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the archive is a valid tar file:
  3. Check the archive is not corrupted
  4. Verify available disk space in the extraction destination

4.1.5.49 - SOLO-5049

DependencyVersionCheckFailedSoloError — System

DependencyVersionCheckFailedSoloError

CodeSOLO-5049
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot determine the installed version of a dependency; the message names the dependency and, when present, wraps the underlying cause (otherwise it notes the tool may not be installed or on PATH). solo checks tool versions to confirm they meet its requirements, so this means the version check could not run or its output could not be parsed.

Troubleshooting Steps

  1. Verify is installed and available in your PATH
  2. Check the installation: which
  3. Run solo init to install missing dependencies: solo init

4.1.5.50 - SOLO-5050

DependencyNotFoundSoloError — System

DependencyNotFoundSoloError

CodeSOLO-5050
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when a required dependency is not found; the message names it. solo expects certain external tools to be available, so this means the dependency could not be located — for example it is not installed or not on PATH.

Troubleshooting Steps

  1. Install the missing dependency:
  2. Run solo init to install all required dependencies: solo init
  3. Verify the dependency is in your PATH: which

4.1.5.51 - SOLO-5051

DependencyManagerNotFoundSoloError — System

DependencyManagerNotFoundSoloError

CodeSOLO-5051
CategorySystem
OwnershipSolo
RetryableNo

Description

Thrown when no dependency manager is registered for a requested dependency; the message names the dependency. solo routes each managed dependency to a registered manager that knows how to install and verify it, so a missing registration points to an internal wiring defect and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.5.52 - SOLO-5052

DependencyInstallFailedSoloError — System

DependencyInstallFailedSoloError

CodeSOLO-5052
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot install a managed dependency; the message names the executable and wraps the underlying failure in cause. solo installs tools like kubectl, helm, and kind when they are missing, so this means installation failed — for example the download failed, the archive was invalid, or the target directory was not writable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify network connectivity for downloading the dependency
  3. Check available disk space
  4. Re-run initialization: solo init

4.1.5.53 - SOLO-5053

DependencyInstallDirectoryConflictSoloError — System

DependencyInstallDirectoryConflictSoloError

CodeSOLO-5053
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when the chosen installation directory is the same as the temporary directory used during install. solo installs managed dependencies (such as kubectl, helm, kind) into a target directory distinct from its temp workspace, so this means the configured paths collide — choose a different installation directory.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Configure separate installation and temporary directories in your Solo configuration

4.1.5.54 - SOLO-5054

GitHubReleasesNotFoundSoloError — System

GitHubReleasesNotFoundSoloError

CodeSOLO-5054
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when a GitHub repository reports no releases. solo lists releases to choose a version to download, so this means the repository returned an empty release list. It is retryable, since a transient API issue can return empty results that resolve on a later attempt.

Troubleshooting Steps

  1. Verify network connectivity and GitHub availability
  2. Check if GitHub API rate limits have been exceeded
  3. Verify proxy or firewall settings allow access to api.github.com

4.1.5.55 - SOLO-5055

GitHubReleaseTagNotFoundSoloError — System

GitHubReleaseTagNotFoundSoloError

CodeSOLO-5055
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when no GitHub release exists for a requested tag; the message names the tag. solo looks up releases by tag to download a specific version, so this means that tag has no release — for example a wrong or not-yet-published version.

Troubleshooting Steps

  1. Verify the release tag ‘’ exists in the GitHub repository
  2. Check the GitHub releases page for available versions
  3. Verify network connectivity to api.github.com

4.1.5.56 - SOLO-5056

GitHubReleaseAssetNotFoundSoloError — System

GitHubReleaseAssetNotFoundSoloError

CodeSOLO-5056
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when no GitHub release asset matches the running platform and architecture; the message names the platform and arch. solo selects the release asset built for the current OS and CPU, so this means the release exists but has no matching asset — for example the platform or architecture is unsupported by that release.

Troubleshooting Steps

  1. Verify a release asset is available for your platform () and architecture ()
  2. Check the GitHub releases page for supported platforms
  3. Consider installing the dependency manually

4.1.5.57 - SOLO-5057

HomebrewInstallFailedSoloError — System

HomebrewInstallFailedSoloError

CodeSOLO-5057
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot install Homebrew. On macOS solo may use Homebrew to install some dependencies, so this means the Homebrew installation did not succeed — for example the install script failed or could not be downloaded.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify network connectivity
  3. Install Homebrew manually from https://brew.sh
  4. Re-run initialization after installing Homebrew: solo init

4.1.5.58 - SOLO-5058

PodmanMachineInspectFailedSoloError — System

PodmanMachineInspectFailedSoloError

CodeSOLO-5058
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot inspect the Podman machine; the underlying failure is wrapped in cause. When using Podman, solo inspects the machine to read its configuration, so this means that inspection failed — for example Podman is not installed, the machine is not running, or the command errored.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Podman is installed: podman –version
  3. List Podman machines: podman machine list
  4. Start the Podman machine if it is not running: podman machine start

4.1.5.59 - SOLO-5059

DockerAuthStaleSoloError — System

DockerAuthStaleSoloError

CodeSOLO-5059
CategorySystem
OwnershipUser
RetryableNo

Description

Thrown when solo detects stale Docker authentication for the GitHub Container Registry (GHCR). solo needs valid GHCR credentials to pull images, so this means the cached Docker auth is expired or invalid — re-authenticate to GHCR to refresh it.

Troubleshooting Steps

  1. Re-authenticate with the GitHub Container Registry: docker login ghcr.io
  2. Verify your GitHub Personal Access Token has the read:packages scope
  3. Clear stale credentials: docker logout ghcr.io

4.1.5.60 - SOLO-5060

PvcCreationFailedSoloError — System

PvcCreationFailedSoloError

CodeSOLO-5060
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot create a PersistentVolumeClaim. solo provisions PVCs for components that need persistent storage, so this means the create request failed — for example the API rejected the spec, or no StorageClass could satisfy it.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify available storage in the cluster: kubectl get pv
  3. Check if a StorageClass is configured: kubectl get storageclass
  4. Inspect PVC events: kubectl describe pvc -n

4.1.5.61 - SOLO-5061

KubernetesApiInvalidResponseSoloError — System

KubernetesApiInvalidResponseSoloError

CodeSOLO-5061
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when the Kubernetes API returns an incorrect or unexpected response. solo expects well-formed responses from the API, so this means a call returned something it could not interpret — for example a malformed or partial response, often indicating an API server problem.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Kubernetes API server is reachable: kubectl cluster-info
  3. Check kubeconfig context: kubectl config current-context
  4. Inspect Kubernetes API server health

4.1.5.62 - SOLO-5062

IngressClassListFailedSoloError — System

IngressClassListFailedSoloError

CodeSOLO-5062
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot list Kubernetes IngressClasses; the underlying failure is wrapped in cause. solo reads IngressClasses to configure ingress for components, so this means the lookup failed — for example the cluster API was unreachable or the current user lacks permission.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Kubernetes connectivity: kubectl cluster-info
  3. List IngressClasses manually: kubectl get ingressclass
  4. Ensure the Kubernetes API server supports IngressClass resources (requires v1.18+)

4.1.5.63 - SOLO-5063

MultipleItemsFoundSoloError — System

MultipleItemsFoundSoloError

CodeSOLO-5063
CategorySystem
OwnershipSolo
RetryableNo

Description

Thrown when a Kubernetes lookup that expected a single resource matches more than one; the filters used are attached to the error. solo expects these filtered lookups to be unique, so multiple matches indicate an internal assumption was violated (for example over-broad filters), and it is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.5.64 - SOLO-5064

PodCreationFailedSoloError — System

PodCreationFailedSoloError

CodeSOLO-5064
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot create a Kubernetes pod. solo creates helper or workload pods as part of its operations, so this means the create request did not yield a running pod — for example the API rejected the spec, scheduling failed, or required resources were unavailable.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Inspect pod events: kubectl get events -n
  3. Check resource quotas: kubectl describe namespace
  4. Verify node resource availability: kubectl get nodes

4.1.5.65 - SOLO-5065

PackageDownloadFailedSoloError — System

PackageDownloadFailedSoloError

CodeSOLO-5065
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when solo cannot download a package; the message names the URL and wraps the underlying failure in cause. solo downloads packages such as platform builds and tools, so this means the download did not complete — for example the URL was unreachable, returned an error, or the connection dropped. It is retryable, since transient network issues often clear on a later attempt.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify network connectivity
  3. Check if proxy or firewall settings block access to the download URL
  4. Verify the download URL is accessible

4.1.5.66 - SOLO-5066

ChecksumReadFailedSoloError — System

ChecksumReadFailedSoloError

CodeSOLO-5066
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot read a checksum file; the message names the file. solo reads checksum files to verify downloaded artifacts, so this means the file could not be read — for example it is missing, empty, or unreadable due to permissions or an interrupted download.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the checksum file exists and is readable:
  3. Re-download the package to regenerate the checksum file

4.1.5.67 - SOLO-5067

ContainerInvalidPathSoloError — System

ContainerInvalidPathSoloError

CodeSOLO-5067
CategorySystem
OwnershipSolo
RetryableNo

Description

Thrown when solo is given an invalid path for a container operation; the message names the context and the path. solo validates container paths before using them for copy or exec operations, so an invalid value here (for example an empty or malformed path passed internally) points to a defect in the calling code and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.5.68 - SOLO-5068

ContainerOperationFailedSoloError — System

ContainerOperationFailedSoloError

CodeSOLO-5068
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when an operation against a container fails; the message names the operation and wraps the underlying failure in cause. solo runs operations such as exec and file copy inside pod containers, so this means that operation failed — for example the container was not reachable, the command errored, or the connection dropped.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the pod is running: kubectl get pods -n
  3. Inspect pod logs: kubectl logs -n
  4. Check pod status: kubectl describe pod -n

4.1.5.69 - SOLO-5069

PostgresPodNotFoundSoloError — System

PostgresPodNotFoundSoloError

CodeSOLO-5069
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot find the Postgres pod; the message names the namespace. solo locates the mirror node Postgres pod to operate on the database, so this is raised when no matching pod exists in the namespace — for example the database failed to start or was not deployed.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify Postgres pods are running: kubectl get pods -n -l app.kubernetes.io/name=postgresql
  3. Inspect Postgres deployment: kubectl describe deployment -n
  4. Re-deploy the mirror node to recreate Postgres: solo mirror node add

4.1.5.70 - SOLO-5070

InitSystemFilesFailedSoloError — System

InitSystemFilesFailedSoloError

CodeSOLO-5070
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot initialize its system files; the underlying failure is wrapped in cause. solo lays down the files it needs under its home directory during initialization, so this means that step failed — for example the directory was not writable or a file could not be created.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify write permissions for the Solo home directory (~/.solo)
  3. Check available disk space
  4. Re-run initialization: solo init

4.1.5.71 - SOLO-5071

CacheProviderNotConfiguredSoloError — System

CacheProviderNotConfiguredSoloError

CodeSOLO-5071
CategorySystem
OwnershipSolo
RetryableNo

Description

Thrown when a cache is built before its required provider or engine has been set; the message names the cache and which piece is missing. solo requires both to be configured before constructing the cache, so reaching this points to an internal setup or ordering defect rather than user input, and is treated as an internal Solo error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.5.72 - SOLO-5072

PodTerminationTimeoutSoloError — System

PodTerminationTimeoutSoloError

CodeSOLO-5072
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when pods do not terminate within the allotted time; the message names the namespace and the label selector being waited on. solo waits for matching pods to disappear during teardown, so this means they were still present when the deadline passed — for example a pod is stuck terminating or has a finalizer. It is retryable, since termination often completes shortly after.

Troubleshooting Steps

  1. List pods still present: kubectl get pods -n -l <labels.join(’,’)>
  2. Describe stuck pods for termination events: kubectl describe pod -n -l <labels.join(’,’)>
  3. Check for finalizers blocking deletion: kubectl get pod -n -l <labels.join(’,’)> -o jsonpath=’{.items[*].metadata.finalizers}'
  4. Force-delete stuck pods if safe: kubectl delete pod -n -l <labels.join(’,’)> –force –grace-period=0
  5. Check solo logs for context: tail -n 100 ~/.solo/logs/solo.log

4.1.5.73 - SOLO-5073

ClusterRoleCheckFailedSoloError — System

ClusterRoleCheckFailedSoloError

CodeSOLO-5073
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when solo cannot check whether a Kubernetes ClusterRole exists; the message names the role and wraps the underlying failure in cause. solo queries for ClusterRoles before installing or relying on them, so this means the lookup failed — for example the Kubernetes API was unreachable or the current user lacks permission to read ClusterRoles.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify RBAC permissions: kubectl get clusterroles
  3. Inspect cluster state: kubectl get pods -A

4.1.5.74 - SOLO-5074

UnsupportedLinuxDistributionSoloError — System

UnsupportedLinuxDistributionSoloError

CodeSOLO-5074
CategorySystem
OwnershipInfrastructure
RetryableNo

Description

Thrown when Solo cannot determine a supported native package manager for the current Linux distribution, so it cannot automatically install system dependencies (git, iptables, podman). Solo supports apt-get (Debian/Ubuntu), dnf (Fedora/RHEL), yum (RHEL 7/CentOS 7), zypper (openSUSE), pacman (Arch) and apk (Alpine).

Troubleshooting Steps

  1. Install one of the supported package managers (apt-get, dnf, yum, zypper, pacman, apk), or
  2. Install Solo and its dependencies (podman, git, iptables) manually, then re-run: solo init

4.1.5.75 - SOLO-5075

BlockNodesJsonEmptySoloError — System

BlockNodesJsonEmptySoloError

CodeSOLO-5075
CategorySystem
OwnershipUser
RetryableNo

Troubleshooting Steps

  1. Ensure at least one block node is deployed: solo block-node deploy
  2. Check the block node mapping flags: –block-node-mapping or –external-block-node-mapping
  3. List all registered components: solo deployment config info
  4. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

4.1.5.76 - SOLO-9001

TimeoutSoloError — System

TimeoutSoloError

CodeSOLO-9001
CategorySystem
OwnershipInfrastructure
RetryableYes

Description

Thrown when a bounded operation does not finish within the time solo allows for it. solo guards long-running waits with deadlines — most often while polling for a Kubernetes pod or service to become Ready, but also for Hedera SDK calls and other long-running CLI steps — and raises this once the deadline passes without the expected condition being met. It signals that the operation was still in progress (or stuck), not that it definitively failed, which is why it is retryable: a resource that is merely slow to stabilise often succeeds on a later run or with a larger timeout. It is the base error for more specific timeouts such as PodTerminationTimeoutSoloError and ClusterApiServerTimeoutSoloError.

Troubleshooting Steps

  1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
  2. Verify the target resource or service is responding
  3. Check Kubernetes pod status: kubectl get pods -A
  4. Increase the timeout if the operation is expected to take longer

4.1.6 - Internal

4.1.6.1 - SOLO-9002

UnsupportedOperationError — Internal

UnsupportedOperationError

CodeSOLO-9002
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when execution reaches a branch that is intentionally not implemented or not supported — for example an abstract operation a subclass was expected to override, a not-yet-built feature path, or an input variant the code does not handle; the message states the reason. Because solo should never route a real command into such a path, this is classified as a defect in solo itself rather than a user or infrastructure problem, and reaching it should be reported with the full error output and the command that triggered it.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.2 - SOLO-9003

ReadRemoteConfigBeforeLoadError — Internal

ReadRemoteConfigBeforeLoadError

CodeSOLO-9003
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when code reads the remote-configuration runtime state before it has been loaded from the cluster. solo fetches the remote config (a ConfigMap) into memory in an explicit load step that must run before any read, so this is a lifecycle guard: reaching it means a command path accessed the remote config without first loading it, or ran the steps out of order. It indicates a defect in solo rather than a user or infrastructure problem.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.3 - SOLO-9004

WriteRemoteConfigBeforeLoadError — Internal

WriteRemoteConfigBeforeLoadError

CodeSOLO-9004
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when code modifies or persists the remote configuration before it has been loaded from the cluster. solo must load the remote config (a ConfigMap) into memory before mutating it, so that writes are applied on top of the current cluster state rather than an empty one; this guard fires when a command path attempts a write without that load having run, or runs the steps out of order. It indicates a defect in solo itself.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.4 - SOLO-9005

DataValidationError — Internal

DataValidationError

CodeSOLO-9005
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when an internal consistency check finds a value that differs from what solo required at that point; the message reports the context together with the expected and actual values. solo uses these assertions to verify invariants as data moves between steps — for example confirming that a downloaded artifact’s checksum matches the expected hash before it is used. A mismatch points to a logic error or a broken assumption inside solo rather than to bad user input or an infrastructure fault, so it is treated as an internal defect and should be reported with the full error output.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.5 - SOLO-9006

LoggerMessageGroupNotFoundError — Internal

LoggerMessageGroupNotFoundError

CodeSOLO-9006
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when the logging subsystem is asked for a message group by a key that was never registered. solo groups related log messages under named keys, and this is raised when code references a group that does not exist — typically a typo in the key or a group that was renamed or never added. It points to a defect in solo rather than to user input.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.6 - SOLO-9007

CommandReturnedFalseError — Internal

CommandReturnedFalseError

CodeSOLO-9007
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when a command handler returns false from a path that requires it to return true to signal success; the message names the command namespace and command that did so. solo treats the boolean return of these handlers as a success flag, so a false here means the handler completed without throwing yet reported failure — an unexpected internal outcome that indicates a defect in solo rather than invalid user input.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.7 - SOLO-9008

RemoteConfigUnsupportedComponentError — Internal

RemoteConfigUnsupportedComponentError

CodeSOLO-9008
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when the remote configuration contains a component whose type solo does not recognise; the message reports the offending componentType. solo dispatches on the component type when reading the remote config’s component inventory, and raises this for any value outside the known set. It usually means the remote config was written by an incompatible solo version or was hand-edited into an invalid state, and is treated as an internal defect.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.8 - SOLO-9009

RemoteConfigDeploymentNotSetError — Internal

RemoteConfigDeploymentNotSetError

CodeSOLO-9009
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown while loading the remote configuration when the selected deployment is not present in the local configuration; the message names the deployment that was expected. solo uses the deployment entry in local config to locate the namespace and clusters whose remote config it should read, so this fires when that entry is missing at a point where it should already have been established. It reflects a broken internal precondition (a missing or out-of-order setup step) rather than direct user input.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.9 - SOLO-9010

RemoteConfigContextUnavailableError — Internal

RemoteConfigContextUnavailableError

CodeSOLO-9010
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown when remote-configuration access needs a Kubernetes context to reach the cluster but none is available: no context was passed to the call and solo could not fall back to a default one (for example because the current kubeconfig has no current-context to resolve). Because callers are expected to supply or have already resolved a context by this point, reaching it indicates a broken internal assumption in solo rather than a user error.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.10 - SOLO-9011

CacheImageTemplateUndeclaredError — Internal

CacheImageTemplateUndeclaredError

CodeSOLO-9011
CategoryInternal
OwnershipSolo
RetryableNo

Description

Thrown while rendering cache image targets when a version field holds a value that looks like a template key (all uppercase letters, digits, and underscores) but is not among the declared templates; the message names the offending key. The renderer treats such a value as a reference to a named template and refuses to emit it verbatim, so the key must first be declared in the template set. Reaching it points to a missing template declaration in solo’s configuration rather than to user input.

Troubleshooting Steps

  1. This is an internal Solo error. File a bug report: https://github.com/hiero-ledger/solo/issues

4.1.6.11 - SOLO-9012

InjectedFailureSoloError — Internal

InjectedFailureSoloError

CodeSOLO-9012
CategoryInternal
OwnershipSolo
RetryableNo

Description

Deliberately thrown by solo’s fault-injection hook to exercise failure and recovery paths during testing — it does not represent a genuine problem with your network or environment. When the SOLO_FAIL_AFTER_STEP environment variable is set, the orchestrator compares it against each step title and raises this error immediately after the matching step completes; the message names that step. If you encounter it without intending to test fault handling, it means SOLO_FAIL_AFTER_STEP is set in your environment — unset it to stop the injected failure.

Troubleshooting Steps

  1. This error is intended for testing purposes.
  2. If you did not expect to see this error unset your environment variable: SOLO_FAIL_AFTER_STEP

5 - Community Contributions

Set up a local development environment and contribute to the Solo project. This document covers prerequisites, local setup, running tests, code formatting, version updates, cluster inspection, and pull request requirements for contributors.

How to Contribute to Solo

This document describes how to set up a local development environment and contribute to the Solo project.

Prerequisites

  • Node.js (use the version specified in the repository, if applicable)
  • npm
  • Docker or Podman
  • Kubernetes (local cluster such as kind, k3d, or equivalent)
  • task (Taskfile runner)
  • Git
  • K9s (optional)

Initial setup

  1. Clone the repository:

    git clone https://github.com/hiero-ledger/solo.git
cd solo

  2. Install dependencies:

    npm install

  3. Install solo as a local CLI:

    npm link

    Notes:

    • This only needs to be done once.
    • If solo already exists in your PATH, remove it first.
    • Alternatively, run commands via npm run solo-test -- <COMMAND> <ARGS>.

  4. Run the CLI:

    solo

Logs and debugging

  • Solo writes two log files under $HOME/.solo/logs/ (on native Windows, $env:USERPROFILE\.solo\logs\):

    $HOME/.solo/logs/solo.ndjson   # newline-delimited JSON (authoritative)
$HOME/.solo/logs/solo.log      # pretty, human-readable

  • For human-readable tailing, use solo.log:

    tail -f $HOME/.solo/logs/solo.log

    Get-Content $env:USERPROFILE\.solo\logs\solo.log -Wait -Tail 50

  • For structured filtering, use solo.ndjson (jq on bash, ConvertFrom-Json in PowerShell):

    tail -f $HOME/.solo/logs/solo.ndjson | jq

    Get-Content $env:USERPROFILE\.solo\logs\solo.ndjson -Wait -Tail 50 | ConvertFrom-Json

How to Run the Tests

  • Unit tests:

    task test

  • List all integration and E2E tasks:

    task --list-all

Code formatting

Before committing any changes, always run:

task format

How to Update Component Versions

  • Edit the component’s version inside /version.ts

How to Inspect the Cluster

When debugging, it helps to inspect resources and logs in the Kubernetes cluster.

Kubectl

Common kubectl commands:

  • kubectl get pods -A
  • kubectl get svc -A
  • kubectl get ingress -A
  • kubectl describe pod <pod-name> -n <namespace>
  • kubectl logs <pod-name> -n <namespace>

Official documentation: kubectl reference

K9s is the primary tool used by the Solo team to inspect and debug Solo deployments.

Why K9s:

  • Terminal UI that makes it faster to navigate Kubernetes resources
  • Quickly view logs, events, and descriptions
  • Simple and intuitive

Start K9s:

k9s -A

Official documentation: K9s commands

Pull Request Requirements

DCO (Developer Certificate of Origin) and Signed Commits

Two separate requirements are enforced on this repository:

1) DCO Sign-off (required)

Refer to the Hiero Ledger contributing docs under sign-off: CONTRIBUTING.md#sign-off

Optional: configure Git to always add the sign-off automatically:

git config --global format.signoff true

2) Cryptographically Signed Commits (required)

In addition to the DCO sign-off, the repository also enforces a GitHub rule that blocks commits that are not signed and verified.

This means your commits must be cryptographically signed using GPG or SSH and show a Verified badge on GitHub.

If your commits are not signed, they will be rejected even if the DCO check passes.

To enable commit signing, see GitHub documentation:

After setup, verify signing is enabled:

git config --global commit.gpgsign true

Both are required:

  • DCO sign-off line (-s)
  • Cryptographic signature (Verified commit)

Conventional Commit PR titles (required)

Pull request titles must follow Conventional Commits.

Examples:

  • feat: add support for grpc-web fqdn endpoints
  • fix: correct version resolution for platform components
  • docs: update contributing guide
  • chore: bump dependency versions

This is required for consistent release notes and changelog generation.

Additional guidelines

  • Prefer small, focused PRs that are easy to review.
  • If you are unsure where to start, open a draft PR early to get feedback.
  • Add description and link all related issues to the PR.

6 - FAQs

Frequently asked questions about the Solo CLI tool, covering deployment options, configuration choices, resource requirements, and common usage patterns. Find quick answers to typical Solo questions.

One-command deployment options and variants

How can I set up a Solo network in a single command?

You can run one of the following commands depending on your needs:

  1. Single Node Deployment (recommended for development):

    solo one-shot single deploy

    Prerequisite: Install Solo first with brew install hiero-ledger/tools/solo.

    For more information on Single Node Deployment, see Quickstart

  2. Multiple Node Deployment (for testing consensus scenarios):

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

    For more information on Multiple Node Deployment, see Quickstart

  3. Advanced Deployment (with custom configuration file):

    solo one-shot falcon deploy --values-file falcon-values.yaml
    • For more information on Advanced Deployment (with custom configuration file), see the Advanced Solo Setup

Can I run Solo on a remote server?

Yes. Solo can deploy to any Kubernetes cluster, not just a local Kind cluster. For remote-cluster and more advanced deployment flows, see Advanced Solo Setup.

Destroying a network and cleaning up resources

How can I tear down a Solo network in a single command?

You can run one of the following commands depending on how you deployed:

  1. Single Node Teardown:

    solo one-shot single destroy

    For more information on Single Node Teardown, see Quickstart

  2. Multiple Node Teardown:

    solo one-shot multi destroy

    For more information on Multiple Node Teardown, see Quickstart

  3. Advanced Deployment Teardown:

    solo one-shot falcon destroy

    For more information on Advanced Deployment Teardown (with custom configuration file), see the Advanced Solo Setup

Why should I destroy my network before redeploying?

Running solo one-shot single deploy while a prior deployment still exists causes conflicts and errors. Always run destroy first:

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

Accessing exposed services

How do I access services after deployment?

After running solo one-shot single deploy, the following services are available on localhost. The ports below are the defaults for Solo 0.63 and later:

ServiceEndpointDescription
Explorer UIhttp://localhost:38080Web UI for inspecting accounts and transactions.
Consensus node (gRPC)localhost:35211gRPC endpoint for submitting transactions.
Mirror node REST APIhttp://localhost:38081REST API for querying historical data.
JSON RPC relayhttp://localhost:37546Ethereum-compatible JSON RPC endpoint.

  • Open http://localhost:38080 in your browser to start exploring your local network.

  • To verify these services are reachable, you can run a quick health check:

    # Mirror node REST API
curl -s "http://localhost:38081/api/v1/transactions?limit=1"

# JSON RPC relay
curl -s -X POST http://localhost:37546 \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

  • If any service is unreachable, confirm that all pods are healthy first:

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

    All Solo-related pods should be in a Running or Completed state before the endpoints become available.

Note: These are Solo’s default port targets. If a port is already in use on your machine, Solo automatically selects the next available port. The actual ports used are printed at the end of deployment and saved to ~/.solo/<deployment-name>/forwards. See Port availability for details.

Solo 0.62 and earlier used different default ports:

ServiceEndpointDescription
Explorer UIhttp://localhost:8080Web UI for inspecting accounts and transactions.
Consensus node (gRPC)localhost:50211gRPC endpoint for submitting transactions.
Mirror node REST APIhttp://localhost:8081REST API for querying historical data (via mirror-ingress).
JSON RPC relayhttp://localhost:7546Ethereum-compatible JSON RPC endpoint.

Note: localhost:5551 is the direct Mirror Node REST service, accessible only via manual kubectl port-forward, and is being phased out. The ingress-based port (8081 for older Solo, 38081 for Solo 0.63+) is the recommended entry point.

How do I connect my application to the local network?

Use these endpoints (Solo 0.63 and later):

  • gRPC (Hedera SDK): localhost:35211, Node ID: 0.0.3
  • JSON RPC (Ethereum tools): http://localhost:37546
  • Mirror Node REST: http://localhost:38081/api/v1/

What should I do if solo one-shot single destroy fails or my Solo state is corrupted?

Warning: This is a last resort. Always try solo one-shot single destroy first.

  • If the standard destroy command fails, perform a full reset manually:

    # 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: Always use the grep '^solo' filter above — omitting it will delete every Kind cluster on your machine, including those unrelated to Solo.

    After a full reset, you can redeploy by following the Quickstart guide.

  • If you want to reset everything and start fresh immediately, run:

    # Delete only Solo-managed clusters and Solo config
kind get clusters | grep '^solo' | while read cluster; do
  kind delete cluster -n "$cluster"
done
rm -rf ~/.solo

# Deploy fresh
solo one-shot single deploy

Common usage patterns and gotchas

1. How can I avoid using genesis keys?

You can run solo ledger system init anytime after solo consensus node start.

2. Where can I find the default account keys?

  • By default, Solo leverages the Hiero Consensus Node well known ED25519 private genesis key:

    302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137

  • the genesis public key is:

    302a300506032b65700321000aa8e21064c61eab86e2a9c164565b4e7a9a4146106e0a6cd03a8c395a110e92

    • Unless changed it is the private key for the default operator account 0.0.2 of the consensus network.

    • It is defined in Hiero source code

3. What is the difference between ECDSA keys and ED25519 keys?

ED25519 is Hedera’s native key type, while ECDSA (secp256k1) is used for EVM/Ethereum-style tooling and compatibility.
For a detailed explanation of both key types and how they are used on Hedera, see core concept.

4. Where can I find the EVM compatible private key?

You will need to use ECDSA keys for EVM tooling compatibility. If you take the privateKeyRaw provided by Solo and prefix it with 0x you will have the private key used by Ethereum compatible tools.

5. Where are my keys stored?

Keys are stored in ~/.solo/cache/keys/. This directory contains:

  • TLS certificates (hedera-node*.crt, hedera-node*.key)
  • Signing keys (s-private-node*.pem, s-public-node*.pem)

6. How do I get the key for an account?

  • Use the following command to get account balance and private key of the account 0.0.1007:

    # get account info of 0.0.1007 and also show the private key
solo ledger account info --account-id 0.0.1007 --deployment solo-deployment  --private-key

  • The output would be similar to the following:

    {
 "accountId": "0.0.1007",
 "privateKey": "302e020100300506032b657004220420411a561013bceabb8cb83e3dc5558d052b9bd6a8977b5a7348bf9653034a29d7",
 "privateKeyRaw": "411a561013bceabb8cb83e3dc5558d052b9bd6a8977b5a7348bf9653034a29d7",
 "publicKey": "302a300506032b65700321001d8978e647aca1195c54a4d3d5dc469b95666de14e9b6edde8ed337917b96013",
 "balance": 100
}

7. How to handle error “failed to setup chart repositories”

  • If during the installation of solo-charts you see the error similar to the following:

    failed to setup chart repositories,
repository name (hedera-json-rpc-relay) already exists

  • You need to remove the old helm repo manually, first run command helm repo list to see the list of helm repos, and then run helm repo remove <repo-name> to remove the repo.

  • For example:

    helm repo list

NAME                  URL                                                       
haproxy-ingress       https://haproxy-ingress.github.io/charts                  
haproxytech           https://haproxytech.github.io/helm-charts                 
metrics-server        https://kubernetes-sigs.github.io/metrics-server/         
metallb               https://metallb.github.io/metallb                         
mirror                https://hashgraph.github.io/hedera-mirror-node/charts     
hedera-json-rpc-relay https://hashgraph.github.io/hedera-json-rpc-relay/charts

  • Next run the command to remove the repo:

    helm repo remove hedera-json-rpc-relay

8. Why do I see unhealthy pods after deployment?

The most common cause is insufficient memory or CPU allocated to Docker Desktop. Minimum requirements:

Deployment typeMinimum RAMMinimum CPU
Single-node12 GB6 cores
Multi-node (3+ nodes)16 GB8 cores

Adjust these in Docker Desktop → Settings → Resources and restart Docker before deploying.

9. How do I find my deployment name?

Most management commands (stop, start, diagnostics) require the deployment name. Retrieve it with:

solo one-shot show deployment

This prints your deployment details, including the deployment name — it defaults to one-shot for one-shot deployments, or the value you passed to --deployment. Use it as <deployment-name> in subsequent commands. See Capture your deployment name for more detail.

10. How do I create test accounts after deployment?

Create funded test accounts with:

solo ledger account create --deployment <deployment-name> --hbar-amount 100

11. How do I check which version of Solo I’m running?

solo --version

# For machine-readable output:
solo --version -o json

12. Why does resource usage grow during testing?

The mirror node accumulates transaction history while the network is running. If you notice increasing memory or disk usage during extended testing sessions, destroy and redeploy the network to reset it to a clean state.

13. How can I monitor my cluster more easily?

  • k9s provides a real-time terminal UI for inspecting pods, logs, and cluster state. Install it with:

    brew install k9s

  • Then run k9s to launch. It is especially helpful for watching pod startup progress during deployment.

14. How do I reset the ledger to a clean genesis state without redeploying?

Run solo ledger system reset --deployment <deployment-name> to reset the ledger to genesis - clearing saved state and ledger-related secrets - while keeping the same cluster and deployment. See Reset the ledger to genesis.

7 -

Solo Release Checklist

1. Verify Workflows

2. Validate Documentation Site

3. Compare Changes Since Last Release

4. Determine Next Version

  • Review commit messages
  • Follow commit message conventions from PR template
  • Alternatively:
    • Run release workflow with dry-run to determine version

5. Review Migration Impact

  • Inspect changes in /data folder:
    • Local config migrations
    • Remote config migrations
  • Confirm migration scenarios are covered
  • Assess impact on:
    • Helm chart upgrades
  • Decide version bump:
    • Patch / Minor / Major

6. Update Documentation (Skip if PATCH)

  • Create PR updating:
  • Include:
    • New Solo version
    • Helm chart version
    • CN / Hedera versions
    • Release date
    • End of support:
      • Odd versions → 1 month
      • Even versions → 3 months
  • Get approval and merge PR

7. Run Release Workflow

8. Update npm latest Tag (Manual)

⚠️ Requires npm access

  • npm dist-tag add @hashgraph/solo@ latest

9. Verify npm Package (@hashgraph)

10. Verify JFrog Artifactory (@hashgraph)

11. Verify npm Package (@hiero-ledger)

12. Verify JFrog Artifactory (@hiero-ledger)