The documentation section 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.
This is the multi-page printable view of this section. Click here to print.
Documentation
The documentation section 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: Getting Started
- 2: Solo User Guide
- 3: Solo CLI User Manual
- 4: Solo CLI Commands
- 5: FAQ
- 6: Using Solo with Mirror Node
- 7: Using Solo with Hiero JavaScript SDK
- 8: Hiero Consensus Node Platform Developer
- 9: Hiero Consensus Node Execution Developer
- 10: Attach JVM Debugger and Retrieve Logs
- 11: Using Environment Variables
1 - Getting Started
Getting started with Solo
[!WARNING]
Any version of Solo prior to
v0.35.3will fail on Apple M3/M4 chipsets due to a known issue with Java 21 and these chipsets.
Solo
An opinionated CLI tool to deploy and manage standalone test networks.
Requirements
| Solo Version | Node.js | Kind | Solo Chart | Hedera | Kubernetes | Kubectl | Helm | k9s | Docker Resources |
|---|---|---|---|---|---|---|---|---|---|
| 0.29.0 | >= 20.14.0 (lts/hydrogen) | >= v1.29.1 | v0.30.0 | v0.53.0 – <= v0.57.0 | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.30.0 | >= 20.14.0 (lts/hydrogen) | >= v1.29.1 | v0.30.0 | v0.54.0 – <= v0.57.0 | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.31.4 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.31.4 | v0.54.0 – <= v0.57.0 | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.32.0 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.38.2 | v0.58.1 - <= v0.59.0 | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.33.0 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.38.2 | v0.58.1 - <= v0.59.0 | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.34.0 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.42.10 | v0.58.1+ | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.35.0 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.44.0 | v0.58.1+ | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.36.0 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.52.0 | v0.58.1+ | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.36.1 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.53.0 | v0.58.1+ | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.37.0 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.53.0 | v0.58.1+ | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.37.1 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.53.0 | v0.58.1+ | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
| 0.38.0 | >= 20.18.0 (lts/iron) | >= v1.29.1 | v0.54.3 | v0.58.1+ | >= v1.27.3 | >= v1.27.3 | v3.14.2 | >= v0.27.4 | Memory >= 8GB, CPU >= 4 |
Hardware Requirements
To run a three-node network, you will need to set up Docker Desktop with at least 8GB of memory and 4 CPUs.
Setup
# install specific nodejs version
# nvm install <version>
# install nodejs version 20.18.0
nvm install v20.18.0
# lists available node versions already installed
nvm ls
# switch to selected node version
# nvm use <version>
nvm use v20.18.0
Install Solo
- Run
npm install -g @hashgraph/solo
Documentation
Contributing
Contributions are welcome. Please see the contributing guide to see how you can get involved.
Code of Conduct
This project is governed by the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code of conduct.
License
2 - Solo User Guide
Learn how to set up your first Hedera test network using Solo. This step-by-step guide covers installation, deployment, and your first transaction.
📝 For less than 16 GB of memory to dedicate to Docker please skip the block node add and destroy steps.
📝 There should be a table of contents on the right side of your screen if your browser width is large enough
Introduction
Welcome to the world of Hedera development! If you’re looking to build and test applications on the Hedera network but don’t want to spend HBAR on testnet or mainnet transactions, you’ve come to the right place. Solo is your gateway to running your own local Hedera test network, giving you complete control over your development environment.
Solo is an opinionated command-line interface (CLI) tool designed to deploy and manage standalone Hedera test networks. Think of it as your personal Hedera sandbox where you can experiment, test features, and develop applications without any external dependencies or costs. Whether you’re building smart contracts, testing consensus mechanisms, or developing DApps, Solo provides the infrastructure you need.
By the end of this tutorial, you’ll have your own Hedera test network running locally, complete with consensus nodes, mirror nodes, and all the infrastructure needed to submit transactions and test your applications. Let’s dive in!
Prerequisites
Before we begin, let’s ensure your system meets the requirements and has all the necessary software installed. Don’t worry if this seems like a lot – we’ll walk through each step together.
System Requirements(for a bare minimum install running 1 node)
First, check that your computer meets these minimum specifications:
- Memory: At least 8GB of RAM (16GB recommended for smoother performance)
- CPU: Minimum 4 cores (8 cores recommended)
- Storage: At least 20GB of free disk space
- Operating System: macOS, Linux, or Windows with WSL2
Required Software
You’ll need to install a few tools before we can set up Solo. Here’s what you need and how to get it:
1. Node.js (≥20.18.0)
Solo is built on Node.js, so you’ll need version 20.18.0 or higher. We recommend using Node Version Manager (nvm) for easy version management:Details <click to expand/collapse>
# Install nvm (macOS/Linux)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
# Install nvm (Windows - use nvm-windows)# Download from: https://github.com/coreybutler/nvm-windows# Install Node.js
nvm install 20.18.0
nvm use 20.18.0
# Verify installation
node --version
2. Docker Desktop
Docker is essential for running the containerized Hedera network components: After installation, ensure Docker is running:Details <click to expand/collapse>
docker --version
docker ps
Preparing Your Environment
Now that we have all prerequisites in place, let’s install Solo and set up our environment.
One thing to consider, old installs can really hamper your ability to get a new install up and running. If you have an old install of Solo, or if you are having issues with the install, please run the following commands to clean up your environment before proceeding.
1. Installing Solo
Open your terminal and install Solo globally using npm: You should see output showing the latest version which should match our NPM package version: https://www.npmjs.com/package/@hashgraph/soloDetails <click to expand/collapse>
npm install -g @hashgraph/solo
# Verify the installation
solo --version
*Cleaning up an old install
The team is presently working on a number of fixes and automation that will relegate the need for this, but currently as deployed Solo can be finnicky with artifacts from prior installs. A quick command to prep your station for a new install is a good idea.Details <click to expand/collapse>
for cluster in $(kind get clusters);do;kind delete cluster -n $cluster;done
rm -Rf ~/.solo
2. Setting up your environmental variables
You need to declare some environmental variables. Keep note that unless you intentionally include these in your zsh config when you close your terminal you may lose them. *throughout the remainder of this walkthrough for simplicity sake I will assume in commands these are the values in your .envDetails <click to expand/collapse>
export SOLO_CLUSTER_NAME=solo
export SOLO_NAMESPACE=solo
export SOLO_CLUSTER_SETUP_NAMESPACE=solo-cluster
export SOLO_DEPLOYMENT=solo-deployment
3. Create a cluster
Example output:Details <click to expand/collapse>
kind create cluster -n "${SOLO_CLUSTER_NAME}"
Creating cluster "solo-e2e" ...
✓ Ensuring node image (kindest/node:v1.32.2) 🖼
✓ Preparing nodes 📦
✓ Writing configuration 📜
✓ Starting control-plane 🕹️
✓ Installing CNI 🔌
✓ Installing StorageClass 💾
Set kubectl context to "kind-solo-e2e"
You can now use your cluster with:
kubectl cluster-info --context kind-solo-e2e
Have a nice day! 👋
*Connecting to a remote cluster
Details <click to expand/collapse>
kubectl config get-contexts
kubectl config use-context <context-name>
Quick Start Deployment
For a simple setup with a single node with a mirror node, explorer, and JSON RPC relay, you can follow these quick steps. This is ideal for testing and development purposes.
solo quick-start single deploy
Step-by-Step Solo Network Deployment
If you have a more complex setup in mind, such as multiple nodes or specific configurations, follow these detailed steps to deploy your Solo network.
1. Initialize solo:
Reset the Example output:Details <click to expand/collapse>
.solo directory before initializing Solo. This step is crucial to ensure a clean setup without any leftover artifacts from previous installations. See: *Cleaning up an old installsolo init
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : init
**********************************************************************************
✔ Setup home directory and cache
✔ Check dependency: helm [OS: linux, Release: 5.15.0-131-generic, Arch: x64]
✔ Check dependency: kind [OS: linux, Release: 5.15.0-131-generic, Arch: x64]
✔ Check dependencies
✔ Create local configuration
✔ Setup chart manager
***************************************************************************************
Note: solo stores various artifacts (config, logs, keys etc.) in its home directory: /home/runner/.solo
If a full reset is needed, delete the directory or relevant sub-directories before running 'solo init'.
***************************************************************************************
✔ Copy templates in '/home/runner/.solo/cache'
2. Connect the cluster and create a deployment
This command will create a deployment in the specified clusters, and generate the LocalConfig and RemoteConfig used by k8s. The deployment will: 📝 notice that the Example output:Details <click to expand/collapse>
--cluster-ref value is kind-solo, when you created the Kind cluster it created a cluster reference in the Kubernetes config with the name kind-solo. If you used a different name, replace kind-solo with your cluster name, but prefixing with kind-. If you are working with a remote cluster, you can use the name of your cluster reference which can be gathered with the command: kubectl config get-contexts.
📝 Note: Solo stores various artifacts (config, logs, keys etc.) in its home directory: ~/.solo. If you need a full reset, delete this directory before running solo init ag# connect to the cluster you created in a previous command
solo cluster-ref connect --cluster-ref kind-${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
#create the deployment
solo deployment create -n "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : cluster-ref connect --cluster-ref kind-solo --context kind-solo
**********************************************************************************
✔ Initialize
✔ kind-solo
✔ Test connection to cluster: kind-solo
✔ Associate a context with a cluster reference: kind-solo
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : deployment create --namespace solo --deployment solo-deployment --realm 0 --shard 0
Kubernetes Namespace : solo
**********************************************************************************
✔ Initialize
✔ Adding deployment: solo-deployment with namespace: solo to local config
3. Add a cluster to the deployment you created
*This command is the first command that will specify how many nodes you want to add to your deployment. For the sake of resource Example output:Details <click to expand/collapse>
# Add a cluster to the deployment you created
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref kind-${SOLO_CLUSTER_NAME} --num-consensus-nodes 1
# If the command line command is unresponsive there's also a handy cluster add configurator you can run `solo deployment add-cluster` without any arguments to get a guided setup.
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : deployment add-cluster --deployment solo-deployment --cluster-ref kind-solo --num-consensus-nodes 1
**********************************************************************************
✔ Initialize
✔ Verify args
✔ check ledger phase
✔ Test cluster connection: kind-solo, context: kind-solo
✔ Verify prerequisites
✔ add cluster-ref: kind-solo for deployment: solo-deployment in local config
✔ create remote config for deployment: solo-deployment in cluster: kind-solo
4. Generate keys
You need to generate keys for your nodes, or in this case single node. Example output: PEM key files are generated in Details <click to expand/collapse>
solo node keys --gossip-keys --tls-keys --deployment "${SOLO_DEPLOYMENT}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : node keys --gossip-keys --tls-keys --deployment solo-deployment
**********************************************************************************
✔ Initialize
✔ Backup old files
✔ Gossip key for node: node1
✔ Generate gossip keys
✔ Backup old files
✔ TLS key for node: node1
✔ Generate gRPC TLS Keys
✔ Finalize
~/.solo/cache/keys directory.hedera-node1.crt hedera-node3.crt s-private-node1.pem s-public-node1.pem unused-gossip-pem
hedera-node1.key hedera-node3.key s-private-node2.pem s-public-node2.pem unused-tls
hedera-node2.crt hedera-node4.crt s-private-node3.pem s-public-node3.pem
hedera-node2.key hedera-node4.key s-private-node4.pem s-public-node4.pem
5. Setup cluster with shared components
Example output:Details <click to expand/collapse>
solo cluster-ref setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : cluster-ref setup --cluster-setup-namespace solo-cluster
**********************************************************************************
✔ Initialize
✔ Prepare chart values
- Installed solo-cluster-setup chart, version: 0.54.4
✔ Install 'solo-cluster-setup' chart
Deploying Helm chart with network components
Now comes the exciting part – deploying your Hedera test network!
*Deploy a block node (experimental)
⚠️ Block Node is experimental in Solo. It requires a minimum of 16 GB of memory allocated to Docker. If you have less than 16 GB of memory, skip this step. As mentioned in the warning, Block Node uses a lot of memory. In addition, it requires a version of Consensus Node to be at least v0.62.3. You will need to augment the Example output:Details <click to expand/collapse>
solo network deploy & solo node setup command with the --release-tag v0.62.6 option to ensure that the Consensus Node is at the correct version. *note: v0.62.6 is the latest patch for v0.62solo block node add --deployment "${SOLO_DEPLOYMENT}" --cluster-ref kind-"${SOLO_CLUSTER_NAME}" --release-tag v0.62.6
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : block node add --deployment solo-deployment --cluster-ref kind-solo --release-tag v0.62.6
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Prepare release name
✔ Prepare chart values
- Installed block-node-0 chart, version: 0.11.0
✔ Deploy block node
✔ Check block node pod is running
✔ Check software
✔ Check block node pod is ready
✔ Check block node readiness - [1/100] success
✔ Add block node component in remote config
1. Deploy the network
Deploying the network runs risks of timeouts as images are downloaded, and pods are starting. If you experience a failure double check the resources you’ve allocated in docker engine and give it another try. Example output:Details <click to expand/collapse>
solo network deploy --deployment "${SOLO_DEPLOYMENT}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : network deploy --deployment solo-deployment --release-tag v0.62.6
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Check if cluster setup chart is installed
✔ Copy Gossip keys to staging
✔ Copy gRPC TLS keys to staging
✔ Prepare staging directory
✔ Copy Gossip keys
✔ Node: node1, cluster: kind-solo
✔ Copy TLS keys
✔ Copy node keys to secrets
- Installed solo-deployment chart, version: 0.54.4
✔ Install chart 'solo-deployment'
✔ Check Node: node1, Cluster: kind-solo
✔ Check node pods are running
✔ Check HAProxy for: node1, cluster: kind-solo
✔ Check Envoy Proxy for: node1, cluster: kind-solo
✔ Check proxy pods are running
✔ Check MinIO
✔ Check auxiliary pods are ready
✔ Add node and proxies to remote config
✔ Copy block-nodes.json
2. Set up a node with Hedera platform software
This step downloads the hedera platform code and sets up your node/nodes. Example output:Details <click to expand/collapse>
# node setup
export CONSENSUS_NODE_VERSION=v0.63.9 # or whatever version you are trying to deploy starting with a `v`
solo node setup --deployment "${SOLO_DEPLOYMENT}" --release-tag "${CONSENSUS_NODE_VERSION}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : node setup --deployment solo-deployment --release-tag v0.62.6
**********************************************************************************
✔ Load configuration
✔ Initialize
✔ Validating state for node node1 - valid state: requested
✔ Validate nodes states
✔ Check network pod: node1
✔ Identify network pods
✔ Update node: node1 [ platformVersion = v0.62.6, context = kind-solo ]
✔ Fetch platform software into network nodes
✔ Copy configuration files
✔ Set file permissions
✔ Node: node1
✔ Setup network nodes
✔ Change node state to configured in remote config
3. Start the nodes up!
Now that everything is set up you need to start them. Example output:Details <click to expand/collapse>
# start your node/nodes
solo node start --deployment "${SOLO_DEPLOYMENT}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : node start --deployment solo-deployment
**********************************************************************************
✔ Load configuration
✔ Initialize
✔ Validating state for node node1 - valid state: configured
✔ Validate nodes states
✔ Check network pod: node1
✔ Identify existing network nodes
✔ Start node: node1
✔ Starting nodes
✔ Enable port forwarding
✔ Check network pod: node1 - status ACTIVE, attempt: 18/300
✔ Check all nodes are ACTIVE
✔ Check proxy for node: node1
✔ Check node proxies are ACTIVE
✔ Change node state to started in remote config
✔ Adding stake for node: node1
✔ Add node stakes
4. Deploy a mirror node
This is the most memory intensive step from a resource perspective. If you have issues at this step try checking your local resource utilization and make sure there’s memory available for docker (close all unessential applications). Likewise, you can consider lowering your swap in docker settings to ease the swap demand, and try again. Example output:Details <click to expand/collapse>
# Deploy with explicit configuration
solo mirror-node deploy --deployment "${SOLO_DEPLOYMENT}" --cluster-ref kind-${SOLO_CLUSTER_NAME} --enable-ingress
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : mirror-node deploy --deployment solo-deployment --cluster-ref kind-solo --enable-ingress --quiet-mode
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Prepare address book
- Installed haproxy-ingress chart, version: 0.14.5
✔ Install mirror ingress controller
- Installed mirror chart, version: v0.131.0
✔ Deploy mirror-node
✔ Enable mirror-node
✔ Check Postgres DB
✔ Check GRPC
✔ Check REST API
✔ Check Monitor
✔ Check Importer
✔ Check pods are ready
✔ Insert data in public.file_data
✔ Seed DB data
✔ Add mirror node to remote config
✔ Enable port forwarding
5. Deploy the explorer
Watch the deployment progress: Example output:Details <click to expand/collapse>
# deploy explorer
solo explorer deploy --deployment "${SOLO_DEPLOYMENT}" --cluster-ref kind-${SOLO_CLUSTER_NAME}
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : explorer deploy --deployment solo-deployment --cluster-ref kind-solo --quiet-mode
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Load remote config
- Installed hiero-explorer chart, version: 25.0.0
✔ Install explorer
✔ Check explorer pod is ready
✔ Add explorer to remote config
✔ Enable port forwarding
6. Deploy a JSON RPC relay
The JSON RPC relay allows you to interact with your Hedera network using standard JSON RPC calls. This is useful for integrating with existing tools and libraries. Example output:Details <click to expand/collapse>
#deploy a solo JSON RPC relay
solo relay deploy -i node1 --deployment "${SOLO_DEPLOYMENT}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : relay deploy --node-aliases node1 --deployment solo-deployment
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Check chart is installed
✔ Prepare chart values
- Installed relay-node1 chart, version: v0.67.0
✔ Deploy JSON RPC Relay
✔ Check relay is running
✔ Check relay is ready
✔ Add relay component in remote config
✔ Enable port forwarding
*Check Pod Status
Here is a command if you want to check the status of your Solo Kubernetes pods:Details <click to expand/collapse>
# Check pod status
kubectl get pods -n solo
Working with Your Network
Network Endpoints
At this time Solo doesn’t automatically set up port forwarding for you, so you’ll need to do that manually. The port forwarding is now automatic for many endpoints. However, you can set up your own using Details <click to expand/collapse>
kubectl port-forward command:# Consensus Service for node1 (node ID = 0): localhost:50211
# should be automatic: kubectl port-forward svc/haproxy-node1-svc -n "${SOLO_NAMESPACE}" 50211:50211 > /dev/null 2>&1 &
# Explorer UI: http://localhost:8080
# should be automatic: kubectl port-forward svc/hiero-explorer -n "${SOLO_NAMESPACE}" 8080:8080 > /dev/null 2>&1 &
# Mirror Node gRPC, REST, REST Java, Web3 will be automatic on `localhost:8081` if you passed `--enable-ingress` to the `solo mirror-node deploy` command
# Mirror Node gRPC: localhost:5600
kubectl port-forward svc/mirror-grpc -n "${SOLO_NAMESPACE}" 5600:5600 > /dev/null 2>&1 &
# Mirror Node REST API: http://localhost:5551
kubectl port-forward svc/mirror-rest -n "${SOLO_NAMESPACE}" 5551:80 > /dev/null 2>&1 &
# Mirror Node REST Java API http://localhost:8084
kubectl port-forward service/mirror-restjava -n "${SOLO_NAMESPACE}" 8084:80 > /dev/null 2>&1 &
# JSON RPC Relay: localhost:7546
# should be automatic: kubectl port-forward svc/relay-node1-hedera-json-rpc-relay -n "${SOLO_NAMESPACE}" 7546:7546 > /dev/null 2>&1 &
Managing Your Network
Stopping and Starting Nodes
You can control individual nodes or the entire network:Details <click to expand/collapse>
# Stop all nodes
solo node stop --deployment solo-deployment
# Stop a specific node
solo node stop --node-id node-0 --deployment solo-deployment
# Restart nodes
solo node restart --deployment solo-deployment
# Start nodes again
solo node start --deployment solo-deployment
Viewing Logs
Access Solo and Consensus Node logs for troubleshooting:Details <click to expand/collapse>
# Download logs from all nodes
# Logs are saved to ~/.solo/logs/<namespace>/<pod-name>/# You can also use kubectl directly:
solo node logs --node-aliases node1 --deployment solo-deployment
Updating the Network
To update nodes to a new Hedera version, you need to upgrade by one minor version higher at a time:Details <click to expand/collapse>
solo node upgrade --deployment solo-deployment --upgrade-version v0.62.6
Updating a single node
To update a single node to a new Hedera version, you need to update by one minor version higher at a time: It is possible to update a single node to a new Hedera version through a process with separated steps. This is only useful in very specific cases, such as when testing the updating process.Details <click to expand/collapse>
solo node update --deployment solo-deployment --node-alias node1 --release-tag v0.62.6
solo node update-prepare --deployment solo-deployment --node-alias node1 --release-tag v0.62.6 --output-dir context
solo node update-submit-transactions --deployment solo-deployment --input-dir context
solo node update-execute --deployment solo-deployment --input-dir context
Adding a new node to the network
Adding a new node to an existing Solo network: It is possible to add a new node through a process with separated steps. This is only useful in very specific cases, such as when testing the node adding process.Details <click to expand/collapse>
TODO solo node add
solo node add-prepare --gossip-keys true --tls-keys true --deployment solo-deployment --pvcs true --admin-key ***** --node-alias node1 --output-dir context
solo node add-submit-transactions --deployment solo-deployment --input-dir context
solo node add-execute --deployment solo-deployment --input-dir context
Deleting a node from the network
This command is used to delete a node from an existing Solo network: It is possible to delete a node through a process with separated steps. This is only useful in very specific cases, such as when testing the delete process.Details <click to expand/collapse>
TODO solo node delete
solo node delete-prepare --deployment solo-deployment --node-alias node1 --output-dir context
solo node delete-submit-transactions --deployment solo-deployment --input-dir context
solo node delete-execute --deployment solo-deployment --input-dir context
Troubleshooting: Common Issues and Solutions
1. Pods Not Starting
If pods remain in Details <click to expand/collapse>
Pending or CrashLoopBackOff state:# Check pod events
kubectl describe pod -n solo network-node-0
# Common fixes:# - Increase Docker resources (memory/CPU)# - Check disk space# - Restart Docker and kind cluster
2. Connection Refused Errors
If you can’t connect to network endpoints:Details <click to expand/collapse>
# Check service endpoints
kubectl get svc -n solo
# Manually forward ports if needed
kubectl port-forward -n solo svc/network-node-0 50211:50211
3. Node Synchronization Issues
If nodes aren’t forming consensus:Details <click to expand/collapse>
# Check node status
solo node states --deployment solo-deployment --node-aliases node1
# Look for gossip connectivity issues
kubectl logs -n solo network-node-0 | grep -i gossip
# Restart problematic nodes
solo node refresh --node-aliases node1 --deployment solo-deployment
Getting Help
When you need assistance:Details <click to expand/collapse>
solo node logs --deployment solo-deployment --node-aliases node1 and examine ~/.solo/logs/
Cleanup
When you’re done with your test network: To quickly clean up your Solo network and remove all resources (all Kind clusters!), you can use the following commands, be aware you will lose all your logs and data from prior runs: Example output: Example output: Example output: Block Node destroy should run prior to network destroy, since network destroy removes the remote config. To destroy the block node (if you deployed it), you can use the following command: Example output: Example output:Details <click to expand/collapse>
*Fast clean up
Details <click to expand/collapse>
for cluster in $(kind get clusters);do;kind delete cluster -n $cluster;done
rm -Rf ~/.solo
1. Destroy relay node
Details <click to expand/collapse>
solo relay destroy -i node1 --deployment "${SOLO_DEPLOYMENT}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : relay destroy --node-aliases node1 --deployment solo-deployment
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Destroy JSON RPC Relay
✔ Remove relay component from remote config
2. Destroy mirror node
Details <click to expand/collapse>
solo mirror-node destroy --deployment "${SOLO_DEPLOYMENT}" --force
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : mirror-node destroy --deployment solo-deployment --quiet-mode
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Destroy mirror-node
✔ Delete PVCs
✔ Uninstall mirror ingress controller
✔ Remove mirror node from remote config
3. Destroy explorer node
Details <click to expand/collapse>
solo explorer destroy --deployment "${SOLO_DEPLOYMENT}" --force
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : explorer destroy --deployment solo-deployment --quiet-mode
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Load remote config
✔ Destroy explorer
✔ Uninstall explorer ingress controller
✔ Remove explorer from remote config
*Destroy block node (Experimental)
Details <click to expand/collapse>
solo block node destroy --deployment "${SOLO_DEPLOYMENT}"
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : block node destroy --deployment solo-deployment
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Look-up block node
✔ Destroy block node
✔ Disable block node component in remote config
4. Destroy network
Details <click to expand/collapse>
solo network destroy --deployment "${SOLO_DEPLOYMENT}" --force
******************************* Solo *********************************************
Version : 0.40.1
Kubernetes Context : kind-solo
Kubernetes Cluster : kind-solo
Current Command : network destroy --deployment solo-deployment --quiet-mode
**********************************************************************************
✔ Acquire lock - lock acquired successfully, attempt: 1/10
✔ Initialize
✔ Remove deployment from local configuration
✔ Deleting the RemoteConfig configmap in namespace solo
Next Steps
Congratulations! You now have a working Hedera test network. Here are some suggestions for what to explore next: Remember, this is your personal Hedera playground. Experiment freely, break things, learn, and have fun building on Hedera! Happy coding with Solo! 🚀Details <click to expand/collapse>
http://localhost:5551
3 - Solo CLI User Manual
Solo CLI is a command line interface for the Hiero Consensus Node network. It allows users to interact with the network, manage accounts, and perform various operations.
Solo Command Line User Manual
Solo has a series of commands to use, and some commands have subcommands. User can get help information by running with the following methods:
solo --help will return the help information for the solo command to show which commands
are available.
solo command --help will return the help information for the specific command to show which options
solo account --help
Manage Hedera accounts in solo network
Commands:
account init Initialize system accounts with new keys
account create Creates a new account with a new key and stores the key in th
e Kubernetes secrets, if you supply no key one will be genera
ted for you, otherwise you may supply either a ECDSA or ED255
19 private key
account update Updates an existing account with the provided info, if you wa
nt to update the private key, you can supply either ECDSA or
ED25519 but not both
account get Gets the account info including the current amount of HBAR
Options:
--dev Enable developer mode [boolean]
--force-port-forward Force port forward to access the network services
[boolean]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
solo command subcommand --help will return the help information for the specific subcommand to show which options
solo account create --help
Creates a new account with a new key and stores the key in the Kubernetes secret
s, if you supply no key one will be generated for you, otherwise you may supply
either a ECDSA or ED25519 private key
Options:
--dev Enable developer mode [boolean]
--force-port-forward Force port forward to access the network services
[boolean]
--hbar-amount Amount of HBAR to add [number]
--create-amount Amount of new account to create [number]
--ecdsa-private-key ECDSA private key for the Hedera account [string]
-d, --deployment The name the user will reference locally to link to
a deployment [string]
--ed25519-private-key ED25519 private key for the Hedera account [string]
--generate-ecdsa-key Generate ECDSA private key for the Hedera account
[boolean]
--set-alias Sets the alias for the Hedera account when it is cr
eated, requires --ecdsa-private-key [boolean]
-c, --cluster-ref The cluster reference that will be used for referen
cing the Kubernetes cluster and stored in the local
and remote configuration for the deployment. For
commands that take multiple clusters they can be se
parated by commas. [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
For more information see: Solo CLI Commands
4 - Solo CLI Commands
This document provides a comprehensive reference for the Solo CLI commands, including their options and usage.
Solo Command Reference
Table of Contents
Root Help Output
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts --help
Select a command
Usage:
solo <command> [options]
Commands:
init Initialize local environment
account Manage Hedera accounts in solo network
cluster-ref Manage solo testing cluster
network Manage solo network deployment
node Manage Hedera platform node in solo network
relay Manage JSON RPC relays in solo network
mirror-node Manage Hedera Mirror Node in solo network
explorer Manage Explorer in solo network
deployment Manage solo network deployment
block Manage block related components in solo network
quick-start Manage quick start for solo 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]
init
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts init --help
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]
account
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts account --help
Select an account command
account
Manage Hedera accounts in solo network
Commands:
account init Initialize system accounts with new keys
account create Creates a new account with a new key and stores the key in the Kubernetes secrets, if you supply no key one will be generated for you, otherwise you may supply either a ECDSA or ED25519 private key
account update Updates an existing account with the provided info, if you want to update the private key, you can supply either ECDSA or ED25519 but not both
account get Gets the account info including the current amount of HBAR
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]
account init
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts account init --help
account init
Initialize system accounts with new keys
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]
account create
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts account create --help
account create
Creates a new account with a new key and stores the key in the Kubernetes secrets, if you supply no key one will be generated for you, otherwise you may supply either a ECDSA or ED25519 private key
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.
--create-amount Amount of new account to [number] [default: 1]
create
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--dev Enable developer mode [boolean] [default: false]
--ecdsa-private-key ECDSA private key for the [string]
Hedera account
--ed25519-private-key ED25519 private key for the [string]
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]
--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]
account update
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts account update --help
account update
Updates an existing account with the provided info, if you want to update the private key, you can supply either ECDSA or ED25519 but not both
Options:
--account-id The Hedera account id, e.g.: [string]
0.0.1001
-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]
--ecdsa-private-key ECDSA private key for the [string]
Hedera account
--ed25519-private-key ED25519 private key for the [string]
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]
account get
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts account get --help
account get
Gets the account info including the current amount of HBAR
Options:
--account-id The Hedera account id, e.g.: [string]
0.0.1001
-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
--private-key Show private key information [boolean] [default: false]
-v, --version Show version number [boolean]
cluster-ref
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts cluster-ref --help
Select a context command
cluster-ref
Manage solo testing cluster
Commands:
cluster-ref connect associates a cluster reference to a k8s context
cluster-ref disconnect dissociates a cluster reference from a k8s context
cluster-ref list List all available clusters
cluster-ref info Get cluster info
cluster-ref setup Setup cluster with shared components
cluster-ref 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 connect
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts cluster-ref connect --help
cluster-ref connect
associates a cluster reference to a k8s context
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-c, --cluster-ref The cluster reference that 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. [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--context The Kubernetes context name to be used [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
cluster-ref disconnect
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts cluster-ref disconnect --help
cluster-ref disconnect
dissociates a cluster reference from a k8s context
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-c, --cluster-ref The cluster reference that 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. [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
cluster-ref list
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts cluster-ref list --help
cluster-ref list
List all available clusters
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
cluster-ref info
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts cluster-ref info --help
cluster-ref info
Get cluster info
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-c, --cluster-ref The cluster reference that 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. [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
cluster-ref setup
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts cluster-ref setup --help
cluster-ref setup
Setup cluster with shared components
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-c, --cluster-ref The cluster reference that 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. [string]
-s, --cluster-setup-namespace Cluster Setup Namespace [string] [default: "solo-setup"]
--minio Deploy minio operator [boolean] [default: true]
--prometheus-stack Deploy prometheus stack [boolean] [default: false]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
cluster-ref reset
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts cluster-ref reset --help
cluster-ref reset
Uninstall shared components from cluster
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-c, --cluster-ref The cluster reference that 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. [string]
-s, --cluster-setup-namespace Cluster Setup Namespace [string] [default: "solo-setup"]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
network
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts network --help
Select a chart command
network
Manage solo network deployment
Commands:
network deploy Deploy solo network. Requires the chart `solo-cluster-setup` to have been installed in the cluster. If it hasn't the following command can be ran: `solo cluster-ref setup`
network destroy Destroy solo network. If both --delete-pvcs and --delete-secrets are set to true, the namespace will be deleted.
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]
network deploy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts network deploy --help
network deploy
Deploy solo network. Requires the chart `solo-cluster-setup` to have been installed in the cluster. If it hasn't the following command can be ran: `solo cluster-ref setup`
Options:
--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
--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
--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
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--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 seperated
--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 seperated)
--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 seperated)
--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)
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--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)
--profile Resource profile (local | tiny [string] [default: "local"]
| small | medium | large)
--profile-file Resource profile definition [string] [default: "profiles/custom-spec.yaml"]
(e.g. custom-spec.yaml)
--prometheus-svc-monitor Enable prometheus service [boolean] [default: false]
monitor for the network nodes
--pvcs Enable persistent volume [boolean] [default: false]
claims to store data outside
the pod, required for node add
-q, --quiet-mode Quiet mode, do not prompt for [boolean] [default: false]
confirmation
-t, --release-tag Release tag to be used (e.g. [string] [default: "v0.61.7"]
v0.61.7)
--settings-txt settings.txt file for node [string] [default: "templates/settings.txt"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--storage-type storage type for saving stream [default: "minio_only"]
files, available options are
minio_only, aws_only,
gcs_only, aws_and_gcs
-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]
network destroy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts network destroy --help
network destroy
Destroy solo network. If both --delete-pvcs and --delete-secrets are set to true, the namespace will be deleted.
Options:
--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.
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--dev Enable developer mode [boolean] [default: false]
--enable-timeout enable time out for running a [boolean] [default: false]
command
-f, --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]
node
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node --help
Select a node command
node
Manage Hedera platform node in solo network
Commands:
node setup Setup node with a specific version of Hedera platform
node start Start a node
node stop Stop a node
node freeze Freeze all nodes of the network
node restart Restart all nodes of the network
node keys Generate node keys
node refresh Reset and restart a node
node logs Download application logs from the network nodes and stores them in <SOLO_LOGS_DIR>/<namespace>/<podName>/ directory
node states Download hedera states from the network nodes and stores them in <SOLO_LOGS_DIR>/<namespace>/<podName>/ directory
node add Adds a node with a specific version of Hedera platform
node add-prepare Prepares the addition of a node with a specific version of Hedera platform
node add-submit-transactions Submits NodeCreateTransaction and Upgrade transactions to the network nodes
node add-execute Executes the addition of a previously prepared node
node update Update a node with a specific version of Hedera platform
node update-prepare Prepare the deployment to update a node with a specific version of Hedera platform
node update-submit-transactions Submit transactions for updating a node with a specific version of Hedera platform
node update-execute Executes the updating of a node with a specific version of Hedera platform
node delete Delete a node with a specific version of Hedera platform
node delete-prepare Prepares the deletion of a node with a specific version of Hedera platform
node delete-submit-transactions Submits transactions to the network nodes for deleting a node
node delete-execute Executes the deletion of a previously prepared node
node prepare-upgrade Prepare the network for a Freeze Upgrade operation
node freeze-upgrade Performs a Freeze Upgrade operation with on the network after it has been prepared with prepare-upgrade
node upgrade upgrades all nodes on the network
node upgrade-prepare Prepare the deployment to upgrade network
node upgrade-submit-transactions Submit transactions for upgrading network
node upgrade-execute Executes the upgrading the network
node download-generated-files Downloads the generated files from an existing 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]
node setup
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node setup --help
node setup
Setup node with a specific version of Hedera platform
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
--app Testing app name [string] [default: "HederaNode.jar"]
--app-config json config file of testing app [string]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
--admin-public-keys Comma separated list of DER encoded ED25519 public keys and must match the order of the node aliases [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node start
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node start --help
node start
Start a node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
--app Testing app name [string] [default: "HederaNode.jar"]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--state-file A zipped state file to be used for the network [string]
--stake-amounts The amount to be staked in the same order you list the node aliases with multiple node staked values comma seperated [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node stop
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node stop --help
node stop
Stop a node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node freeze
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node freeze --help
node freeze
Freeze all nodes of the network
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node restart
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node restart --help
node restart
Restart all nodes of the network
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node keys
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node keys --help
node keys
Generate node keys
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--gossip-keys Generate gossip keys for nodes [boolean] [default: false]
--tls-keys Generate gRPC TLS keys for nodes [boolean] [default: false]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
-n, --namespace Namespace [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node refresh
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node refresh --help
node refresh
Reset and restart a node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
--local-build-path path of hedera local repo [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node logs
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node logs --help
node logs
Download application logs from the network nodes and stores them in <SOLO_LOGS_DIR>/<namespace>/<podName>/ directory
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node states
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node states --help
node states
Download hedera states from the network nodes and stores them in <SOLO_LOGS_DIR>/<namespace>/<podName>/ directory
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node add
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node add --help
node add
Adds 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--pvcs Enable persistent volume claims to store data outside the pod, required for node add [boolean] [default: false]
--grpc-tls-cert TLS Certificate path for the gRPC (e.g. "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated) [string]
--grpc-web-tls-cert TLS Certificate path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated) [string]
--grpc-tls-key TLS Certificate key path for the gRPC (e.g. "node1=/Users/username/node1-grpc.key" with multiple nodes comma seperated) [string]
--grpc-web-tls-key TLC Certificate key path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma seperated) [string]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--gossip-keys Generate gossip keys for nodes [boolean] [default: false]
--tls-keys Generate gRPC TLS keys for nodes [boolean] [default: false]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-c, --cluster-ref The cluster reference that 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. [string]
--admin-key Admin key [string] [default: "***"]
--haproxy-ips IP mapping where key = value is node alias and static ip for haproxy, (e.g.: --haproxy-ips node1=127.0.0.1,node2=127.0.0.1) [string]
--envoy-ips IP mapping where key = value is node alias and static ip for envoy proxy, (e.g.: --envoy-ips node1=127.0.0.1,node2=127.0.0.1) [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node add-prepare
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node add-prepare --help
node add-prepare
Prepares the addition 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--output-dir Path to the directory where the command context will be saved to [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--pvcs Enable persistent volume claims to store data outside the pod, required for node add [boolean] [default: false]
--grpc-tls-cert TLS Certificate path for the gRPC (e.g. "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated) [string]
--grpc-web-tls-cert TLS Certificate path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated) [string]
--grpc-tls-key TLS Certificate key path for the gRPC (e.g. "node1=/Users/username/node1-grpc.key" with multiple nodes comma seperated) [string]
--grpc-web-tls-key TLC Certificate key path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma seperated) [string]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--gossip-keys Generate gossip keys for nodes [boolean] [default: false]
--tls-keys Generate gRPC TLS keys for nodes [boolean] [default: false]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-c, --cluster-ref The cluster reference that 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. [string]
--admin-key Admin key [string] [default: "***"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node add-submit-transactions
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node add-submit-transactions --help
node add-submit-transactions
Submits NodeCreateTransaction and Upgrade transactions to the network nodes
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--pvcs Enable persistent volume claims to store data outside the pod, required for node add [boolean] [default: false]
--grpc-tls-cert TLS Certificate path for the gRPC (e.g. "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated) [string]
--grpc-web-tls-cert TLS Certificate path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated) [string]
--grpc-tls-key TLS Certificate key path for the gRPC (e.g. "node1=/Users/username/node1-grpc.key" with multiple nodes comma seperated) [string]
--grpc-web-tls-key TLC Certificate key path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma seperated) [string]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--gossip-keys Generate gossip keys for nodes [boolean] [default: false]
--tls-keys Generate gRPC TLS keys for nodes [boolean] [default: false]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-c, --cluster-ref The cluster reference that 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. [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node add-execute
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node add-execute --help
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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--pvcs Enable persistent volume claims to store data outside the pod, required for node add [boolean] [default: false]
--grpc-tls-cert TLS Certificate path for the gRPC (e.g. "node1=/Users/username/node1-grpc.cert" with multiple nodes comma separated) [string]
--grpc-web-tls-cert TLS Certificate path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.cert" with multiple nodes comma separated) [string]
--grpc-tls-key TLS Certificate key path for the gRPC (e.g. "node1=/Users/username/node1-grpc.key" with multiple nodes comma seperated) [string]
--grpc-web-tls-key TLC Certificate key path for gRPC Web (e.g. "node1=/Users/username/node1-grpc-web.key" with multiple nodes comma seperated) [string]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--gossip-keys Generate gossip keys for nodes [boolean] [default: false]
--tls-keys Generate gRPC TLS keys for nodes [boolean] [default: false]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-c, --cluster-ref The cluster reference that 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. [string]
--haproxy-ips IP mapping where key = value is node alias and static ip for haproxy, (e.g.: --haproxy-ips node1=127.0.0.1,node2=127.0.0.1) [string]
--envoy-ips IP mapping where key = value is node alias and static ip for envoy proxy, (e.g.: --envoy-ips node1=127.0.0.1,node2=127.0.0.1) [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node update
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node update --help
node update
Update 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--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"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
--new-admin-key new admin key for the Hedera account [string]
--new-account-number new account number for node update transaction [string]
--tls-public-key path and file name of the public TLS key to be used [string]
--gossip-private-key path and file name of the private key for signing gossip in PEM key format to be used [string]
--gossip-public-key path and file name of the public key for signing gossip in PEM key format to be used [string]
--tls-private-key path and file name of the private TLS key to be used [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node update-prepare
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node update-prepare --help
node update-prepare
Prepare the deployment to update 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--output-dir Path to the directory where the command context will be saved to [string] [required]
--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"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
--new-admin-key new admin key for the Hedera account [string]
--new-account-number new account number for node update transaction [string]
--tls-public-key path and file name of the public TLS key to be used [string]
--gossip-private-key path and file name of the private key for signing gossip in PEM key format to be used [string]
--gossip-public-key path and file name of the public key for signing gossip in PEM key format to be used [string]
--tls-private-key path and file name of the private TLS key to be used [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node update-submit-transactions
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node update-submit-transactions --help
node update-submit-transactions
Submit transactions for updating 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node update-execute
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node update-execute --help
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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--gossip-endpoints Comma separated gossip endpoints of the node(e.g. first one is internal, second one is external) [string]
--grpc-endpoints Comma separated gRPC endpoints of the node (at most 8) [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node delete
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node delete --help
node delete
Delete 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--node-alias Node alias (e.g. node99) [string] [required]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node delete-prepare
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node delete-prepare --help
node delete-prepare
Prepares the deletion 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--node-alias Node alias (e.g. node99) [string] [required]
--output-dir Path to the directory where the command context will be saved to [string] [required]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node delete-submit-transactions
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node delete-submit-transactions --help
node delete-submit-transactions
Submits transactions to the network nodes for deleting a node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--node-alias Node alias (e.g. node99) [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node delete-execute
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node delete-execute --help
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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--node-alias Node alias (e.g. node99) [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--app Testing app name [string] [default: "HederaNode.jar"]
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
--endpoint-type Endpoint type (IP or FQDN) [string] [default: "FQDN"]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
--domain-names Custom domain names for consensus nodes mapping for the(e.g. node0=domain.name where key is node alias and value is domain name)with multiple nodes comma seperated [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node prepare-upgrade
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node prepare-upgrade --help
node prepare-upgrade
Prepare the network for a Freeze Upgrade operation
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node freeze-upgrade
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node freeze-upgrade --help
node 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 the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node upgrade
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node upgrade --help
node upgrade
upgrades all nodes on the network
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--upgrade-version Version to be used for the upgrade [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--upgrade-zip-file A zipped file used for network upgrade [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node upgrade-prepare
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node upgrade-prepare --help
node upgrade-prepare
Prepare the deployment to upgrade network
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--output-dir Path to the directory where the command context will be saved to [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--upgrade-zip-file A zipped file used for network upgrade [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node upgrade-submit-transactions
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node upgrade-submit-transactions --help
node upgrade-submit-transactions
Submit transactions for upgrading network
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--upgrade-zip-file A zipped file used for network upgrade [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node upgrade-execute
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node upgrade-execute --help
node upgrade-execute
Executes the upgrading the network
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
--input-dir Path to the directory where the command context will be loaded from [string] [required]
--app Testing app name [string] [default: "HederaNode.jar"]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
--debug-node-alias Enable default jvm debug port (5005) for the given node id [string]
-i, --node-aliases Comma separated node aliases (empty means all nodes) [string]
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--local-build-path path of hedera local repo [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
--upgrade-zip-file A zipped file used for network upgrade [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
node download-generated-files
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts node download-generated-files --help
node download-generated-files
Downloads the generated files from an existing node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-d, --deployment The name the user will reference locally to link to a deployment [string] [required]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
--cache-dir Local cache directory [string] [default: "/home/runner/.solo/cache"]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
relay
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts relay --help
Select a relay command
relay
Manage JSON RPC relays in solo network
Commands:
relay deploy Deploy a JSON RPC relay
relay destroy Destroy JSON RPC relay
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 deploy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts relay deploy --help
relay deploy
Deploy a JSON RPC relay
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.
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--dev Enable developer mode [boolean] [default: false]
--domain-name Custom domain name [string]
--force-port-forward Force port forward to access [boolean] [default: true]
the network services
-l, --ledger-id Ledger ID (a.k.a. Chain ID) [string] [default: "298"]
-i, --node-aliases Comma separated node aliases [string]
(empty means all nodes)
--operator-id Operator ID [string]
--operator-key Operator Key [string]
--profile Resource profile (local | tiny [string] [default: "local"]
| small | medium | large)
--profile-file Resource profile definition [string] [default: "profiles/custom-spec.yaml"]
(e.g. custom-spec.yaml)
-q, --quiet-mode Quiet mode, do not prompt for [boolean] [default: false]
confirmation
--relay-release Relay release tag to be used [string] [default: "v0.67.0"]
(e.g. v0.48.0)
--replica-count Replica count [number] [default: 1]
-f, --values-file Comma separated chart values [string]
file
-v, --version Show version number [boolean]
relay destroy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts relay destroy --help
relay destroy
Destroy JSON RPC relay
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.
-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)
-q, --quiet-mode Quiet mode, do not prompt for [boolean] [default: false]
confirmation
-v, --version Show version number [boolean]
mirror-node
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts mirror-node --help
Select a mirror-node command
mirror-node
Manage Hedera Mirror Node in solo network
Commands:
mirror-node deploy Deploy mirror-node and its components
mirror-node destroy Destroy mirror-node components and database
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 deploy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts mirror-node deploy --help
mirror-node deploy
Deploy mirror-node and its components
Options:
--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.
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--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-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-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-version Mirror node chart version [string] [default: "v0.131.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
--profile Resource profile (local | tiny [string] [default: "local"]
| small | medium | large)
--profile-file Resource profile definition [string] [default: "profiles/custom-spec.yaml"]
(e.g. custom-spec.yaml)
-q, --quiet-mode Quiet mode, do not prompt for [boolean] [default: false]
confirmation
--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
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts mirror-node destroy --help
mirror-node destroy
Destroy mirror-node components and database
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.
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--dev Enable developer mode [boolean] [default: false]
-f, --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
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts explorer --help
Select a explorer command
explorer
Manage Explorer in solo network
Commands:
explorer deploy Deploy explorer
explorer destroy Destroy explorer
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 deploy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts explorer deploy --help
explorer deploy
Deploy explorer
Options:
--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"]
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--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-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: "25.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
-n, --namespace Namespace [string]
--profile Resource profile (local | tiny [string] [default: "local"]
| small | medium | large)
--profile-file Resource profile definition [string] [default: "profiles/custom-spec.yaml"]
(e.g. custom-spec.yaml)
-q, --quiet-mode Quiet mode, do not prompt for [boolean] [default: false]
confirmation
--solo-chart-version Solo testing chart version [string] [default: "0.54.4"]
--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 destroy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts explorer destroy --help
explorer destroy
Destroy explorer
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.
-d, --deployment The name the user will [string]
reference locally to link to a
deployment
--dev Enable developer mode [boolean] [default: false]
-f, --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]
deployment
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts deployment --help
Select a chart command
deployment
Manage solo network deployment
Commands:
deployment create Creates a solo deployment
deployment delete Deletes a solo deployment
deployment list List solo deployments inside a cluster
deployment add-cluster Adds cluster to solo 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]
deployment create
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts deployment create --help
deployment create
Creates a solo deployment
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
-n, --namespace Namespace [string]
-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 delete
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts deployment delete --help
deployment delete
Deletes a solo deployment
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]
deployment list
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts deployment list --help
deployment list
List solo deployments inside a 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 add-cluster
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts deployment add-cluster --help
deployment add-cluster
Adds cluster to solo deployments
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]
--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]
block
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts block --help
block
Manage block related components in solo network
Commands:
block node Manage block nodes in solo network
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
block node
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts block node --help
block node
Manage block nodes in solo network
Commands:
block node add Add block node
block node destroy destroy block node
block node upgrade upgrade block node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
block node add
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts block node add --help
block node add
Add block node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
--chart-version Block nodes chart version [string] [default: "0.11.0"]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-c, --cluster-ref The cluster reference that 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. [string]
-d, --deployment The name the user will reference locally to link to a deployment [string]
--domain-name Custom domain name [string]
--enable-ingress enable ingress on the component/pod [boolean] [default: false]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-f, --values-file Comma separated chart values file [string]
-t, --release-tag Release tag to be used (e.g. v0.61.7) [string] [default: "v0.61.7"]
--image-tag The Docker image tag to override what is in the Helm Chart [string]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
block node destroy
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts block node destroy --help
block node destroy
destroy block node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-c, --cluster-ref The cluster reference that 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. [string]
-d, --deployment The name the user will reference locally to link to a deployment [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
block node upgrade
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts block node upgrade --help
block node upgrade
upgrade block node
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
--upgrade-version Version to be used for the upgrade [string] [required]
--chart-dir Local chart directory path (e.g. ~/solo-charts/charts [string]
-c, --cluster-ref The cluster reference that 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. [string]
-d, --deployment The name the user will reference locally to link to a deployment [string]
-f, --force Force actions even if those can be skipped [boolean] [default: false]
-q, --quiet-mode Quiet mode, do not prompt for confirmation [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
quick-start
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts quick-start --help
quick-start
Manage quick start for solo network
Commands:
quick-start single A single consensus node quick start configuration
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
quick-start single
> @hashgraph/solo@0.40.1 solo-test
> tsx --no-deprecation --no-warnings solo.ts quick-start single --help
quick-start single
A single consensus node quick start configuration
Commands:
quick-start single deploy Deploys all required components for the selected quick start configuration
quick-start single destroy Removes the deployed resources for the selected quick start configuration
Options:
--dev Enable developer mode [boolean] [default: false]
--force-port-forward Force port forward to access the network services [boolean] [default: true]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]
5 - FAQ
Frequently asked questions about the Solo CLI tool.
How can I avoid using genesis keys ?
You can run solo account init anytime after solo node start
Where can I find the default account keys ?
It is the well known default genesis key Link
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 account get --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
}
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
6 - Using Solo with Mirror Node
This document describes how to use Solo with Mirror Node.
Using Solo with mirror node
User can deploy a Solo network with Mirror Node by running the following command:
export SOLO_CLUSTER_NAME=solo-cluster
export SOLO_NAMESPACE=solo-e2e
export SOLO_CLUSTER_SETUP_NAMESPACE=solo-cluster-setup
export SOLO_DEPLOYMENT=solo-deployment
rm -Rf ~/.solo
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"
solo init
solo cluster-ref setup --cluster-setup-namespace "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
solo deployment create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 2
solo node keys --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2
solo node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2
solo mirror-node deploy --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME}
solo explorer deploy --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME}
# check to see if it is already enabled, port forwarding for explorer and consensus node grpc should be handled by solo automatically
# kubectl port-forward svc/haproxy-node1-svc -n "${SOLO_NAMESPACE}" 50211:50211 > /dev/null 2>&1 &
# kubectl port-forward svc/hiero-explorer -n "${SOLO_NAMESPACE}" 8080:8080 > /dev/null 2>&1 &
Then you can access the Explorer at http://localhost:8080
Or you can use Task tool to deploy Solo network with Mirror Node with a single command link
Next, you can try to create a few accounts with Solo and see the transactions in the Explorer.
solo account create -n solo-e2e --hbar-amount 100
solo account create -n solo-e2e --hbar-amount 100
Or you can use Hedera JavaScript SDK examples to create topic, submit message and subscribe to the topic.
If you need to access mirror node service directly, use the following command to enable port forwarding, or just use localhost:8081 as it should have all the mirror node services exposed to this port:
kubectl port-forward svc/mirror-grpc -n "${SOLO_NAMESPACE}" 5600:5600 &
grpcurl -plaintext "${GRPC_IP:-127.0.0.1}:5600" list
kubectl port-forward svc/mirror-rest -n "${SOLO_NAMESPACE}" svc/mirror-rest 5551:80 &
curl -s "http://${REST_IP:-127.0.0.1}:5551/api/v1/transactions?limit=1"
kubectl port-forward service/mirror-restjava -n "${SOLO_NAMESPACE}" 8084:80 &
curl -s "http://${REST_IP:-127.0.0.1}:8084/api/v1/accounts/0.0.2/allowances/nfts"
7 - Using Solo with Hiero JavaScript SDK
This page describes how to use Solo with Hiero JavaScript SDK. It includes instructions for setting up a local Solo network, creating test accounts, and running example scripts.
Using Solo with the Hiero JavaScript SDK
First, please follow solo repository README to install solo and Docker Desktop. You also need to install the Taskfile tool following the instructions here.
Then we start with launching a local Solo network with the following commands:
# launch a local Solo network with mirror node and hedera explorer
cd examples
task default-with-mirror
Then create a new test account with the following command:
npm run solo-test -- account create --deployment solo-deployment --hbar-amount 100
The output would be similar to the following:
*** new account created ***
-------------------------------------------------------------------------------
{
"accountId": "0.0.1007",
"publicKey": "302a300506032b65700321001d8978e647aca1195c54a4d3d5dc469b95666de14e9b6edde8ed337917b96013",
"balance": 100
}
Then use the following command to get private key of the account 0.0.1007:
npm run solo-test -- account get --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
}
Next step please clone the Hiero Javascript SDK repository https://github.com/hiero-ledger/hiero-sdk-js.
At the root of the project hiero-sdk-js, create a file .env and add the following content:
# Hiero Operator Account ID
export OPERATOR_ID="0.0.1007"
# Hiero Operator Private Key
export OPERATOR_KEY="302a300506032b65700321001d8978e647aca1195c54a4d3d5dc469b95666de14e9b6edde8ed337917b96013"
# Hiero Network
export HEDERA_NETWORK="local-node"
Make sure to assign the value of accountId to OPERATOR_ID and the value of privateKey to OPERATOR_KEY.
Then try the following command to run the test
node examples/create-account.js
The output should be similar to the following:
private key = 302e020100300506032b6570042204208a3c1093c4df779c4aa980d20731899e0b509c7a55733beac41857a9dd3f1193
public key = 302a300506032b6570032100c55adafae7e85608ea893d0e2c77e2dae3df90ba8ee7af2f16a023ba2258c143
account id = 0.0.1009
Or try the topic creation example:
node examples/create-topic.js
The output should be similar to the following:
topic id = 0.0.1008
topic sequence number = 1
You can use Hiero Explorer to check transactions and topics created in the Solo network: http://localhost:8080/localnet/dashboard
Finally, after done with using solo, using the following command to tear down the Solo network:
task clean
Retrieving Logs
You can find log for running solo command under the directory ~/.solo/logs/
The file solo.log contains the logs for the solo command. The file hashgraph-sdk.log contains the logs from Solo client when sending transactions to network nodes.
8 - Hiero Consensus Node Platform Developer
This page provides information for developers who want to build and run Hiero Consensus Node testing application locally.
Use Solo with a Local Built Hiero Consensus Node Testing Application
First, please clone Hiero Consensus Node repo https://github.com/hiero-ledger/hiero-consensus-node/ and build the code
with ./gradlew assemble. If you need to run multiple nodes with different versions or releases, please duplicate the repo or build directories in
multiple directories, checkout to the respective version and build the code.
Then you can start the custom-built platform testing application with the following command:
SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-e2e
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 init
solo cluster-ref setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
solo deployment create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo node keys --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
# option 1) if all nodes are running the same version of Hiero app
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data/
# option 2) if each node is running different version of Hiero app, please provide different paths to the local repositories
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path node1=../hiero-consensus-node/hedera-node/data/,node1=<path2>,node3=<path3>
solo node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
It is possible that different nodes are running different versions of Hiero app, as long as in the above setup command, each node0, or node1 is given different paths to the local repositories.
If need to provide customized configuration files for Hedera application, please use the following flags with network deploy command:
--settings-txt- to provide custom settings.txt file--api-permission-properties- to provide custom api-permission.properties file--bootstrap-properties- to provide custom bootstrap.properties file--application-properties- to provide custom application.properties file
For example:
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --settings-txt <path-to-settings-txt>
9 - Hiero Consensus Node Execution Developer
Use port-forwarding to access Hiero Consensus Node network services.
Hiero Consensus Node Execution Developer
Once the nodes are up, you may now expose various services (using k9s (shift-f) or kubectl port-forward) and access. Below are most used services that you may expose.
- where the ’node name’ for Node ID = 0, is
node1(node${ nodeId + 1 }) - Node services:
network-<node name>-svc - HAProxy:
haproxy-<node name>-svc# enable port forwarding for haproxy # node1 grpc port accessed by localhost:50211 kubectl port-forward svc/haproxy-node1-svc -n "${SOLO_NAMESPACE}" 51211:50211 & # node2 grpc port accessed by localhost:51211 kubectl port-forward svc/haproxy-node2-svc -n "${SOLO_NAMESPACE}" 52211:50211 & # node3 grpc port accessed by localhost:52211 kubectl port-forward svc/haproxy-node3-svc -n "${SOLO_NAMESPACE}" 53211:50211 & - Envoy Proxy:
envoy-proxy-<node name>-svc# enable port forwarding for envoy proxy kubectl port-forward svc/envoy-proxy-node1-svc -n "${SOLO_NAMESPACE}" 8181:8080 & kubectl port-forward svc/envoy-proxy-node2-svc -n "${SOLO_NAMESPACE}" 8281:8080 & kubectl port-forward svc/envoy-proxy-node3-svc -n "${SOLO_NAMESPACE}" 8381:8080 & - Hiero explorer:
solo-deployment-hiero-explorer# enable port forwarding for hiero explorer, can be access at http://localhost:8080/ # check to see if it is already enabled, port forwarding for explorer should be handled by solo automatically # kubectl port-forward svc/hiero-explorer -n "${SOLO_NAMESPACE}" 8080:8080 & - JSON RPC Relays
You can deploy JSON RPC Relays for one or more nodes as below:
# deploy relay node first
solo relay deploy -i node1 --deployment "${SOLO_DEPLOYMENT}"
# enable relay for node1
# check to see if it is already enabled, port forwarding for relay should be handled by solo automatically
# kubectl port-forward svc/relay-node1-hedera-json-rpc-relay -n "${SOLO_NAMESPACE}" 7546:7546 &
10 - Attach JVM Debugger and Retrieve Logs
This document describes how to attach a JVM debugger to a running Hiero Consensus Node and retrieve logs for debugging purposes. It also provides instructions on how to save and reuse network state files.
How to Debug a Hiero Consensus Node
1. Using k9s to access running consensus node logs
Running the command k9s -A in terminal, and select one of the network nodes:
Next, select the root-container and press the key s to enter the shell of the container.
Once inside the shell, you can change to directory cd /opt/hgcapp/services-hedera/HapiApp2.0/
to view all hedera related logs and properties files.
[root@network-node1-0 hgcapp]# cd /opt/hgcapp/services-hedera/HapiApp2.0/
[root@network-node1-0 HapiApp2.0]# pwd
/opt/hgcapp/services-hedera/HapiApp2.0
[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
Alternatively, you can use the following command to download hgcaa.log and swirlds.log for further analysis.
# download logs as zip file from node1 and save in default ~/.solo/logs/solo-e2e/<timestamp/
solo node logs -i node1 -n solo-e2e
2. Using IntelliJ remote debug with Solo
NOTE: the hiero-consensus-node path referenced ‘../hiero-consensus-node/hedera-node/data’ may need to be updated based on what directory you are currently in. This also assumes that you have done an assemble/build and the directory contents are up-to-date.
Set up an Intellij run/debug configuration for remote JVM debug as shown in the below screenshot:
If you are working on a Hiero Consensus Node testing application, you should use the following configuration in Intellij:
Set up a breakpoint if necessary.
From Solo repo directory, run the following command from a terminal to launch a three node network, assume we are trying to attach debug to node2.
Make sure the path following local-build-path points to the correct directory.
Example 1: attach jvm debugger to a Hiero Consensus Node
SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-e2e
SOLO_CLUSTER_SETUP_NAMESPACE=solo-setup
SOLO_DEPLOYMENT=solo-deployment
rm -Rf ~/.solo # to avoid name collision issues if you ran previously with the same deployment name
kind delete cluster -n "${SOLO_CLUSTER_NAME}"
kind create cluster -n "${SOLO_CLUSTER_NAME}"
solo init
solo cluster-ref setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
solo deployment create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo node keys --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --debug-node-alias node2
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --debug-node-alias node2
Once you see the following message, you can launch the JVM debugger from Intellij
❯ Check all nodes are ACTIVE
Check node: node1,
Check node: node2, Please attach JVM debugger now.
Check node: node3,
The Hiero Consensus Node application should stop at the breakpoint you set:
Example 2: attach a JVM debugger with the node add operation
SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-e2e
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 init
solo cluster-ref setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
solo deployment create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo node keys --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --pvcs true
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo node add --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys --debug-node-alias node4 --local-build-path ../hiero-consensus-node/hedera-node/data --pvcs true
Example 3: attach a JVM debugger with the node update operation
SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-e2e
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 init
solo cluster-ref setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
solo deployment create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo node keys --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo 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.59.5
Example 4: attach a JVM debugger with the node delete operation
SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-e2e
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 init
solo cluster-ref setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
solo deployment create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo node keys --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo node delete --deployment "${SOLO_DEPLOYMENT}" --node-alias node2 --debug-node-alias node3 --local-build-path ../hiero-consensus-node/hedera-node/data
3. Save and reuse network state files
With the following command you can save the network state to a file.
# must stop hedera node operation first
solo node stop --deployment "${SOLO_DEPLOYMENT}"
# download state file to default location at ~/.solo/logs/<namespace>
solo node states -i node1,node2,node3 --deployment "${SOLO_DEPLOYMENT}"
By default, the state files are saved under ~/.solo directory
└── logs
├── solo-e2e
│ ├── network-node1-0-state.zip
│ └── network-node2-0-state.zip
└── solo.log
Later, user can use the following command to upload the state files to the network and restart Hiero Consensus Nodes.
SOLO_CLUSTER_NAME=solo-cluster
SOLO_NAMESPACE=solo-e2e
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 init
solo cluster-ref setup -s "${SOLO_CLUSTER_SETUP_NAMESPACE}"
solo cluster-ref connect --cluster-ref ${SOLO_CLUSTER_NAME} --context kind-${SOLO_CLUSTER_NAME}
solo deployment create --namespace "${SOLO_NAMESPACE}" --deployment "${SOLO_DEPLOYMENT}"
solo deployment add-cluster --deployment "${SOLO_DEPLOYMENT}" --cluster-ref ${SOLO_CLUSTER_NAME} --num-consensus-nodes 3
solo node keys --deployment "${SOLO_DEPLOYMENT}" --gossip-keys --tls-keys -i node1,node2,node3
solo network deploy --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo node setup --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3 --local-build-path ../hiero-consensus-node/hedera-node/data
solo node start --deployment "${SOLO_DEPLOYMENT}" -i node1,node2,node3
solo node stop --deployment "${SOLO_DEPLOYMENT}"
solo node states -i node1,node2,node3 --deployment "${SOLO_DEPLOYMENT}"
# start network with pre-existing state files
solo node start --deployment "${SOLO_DEPLOYMENT}" --state-file network-node1-0-state.zip
11 - Using Environment Variables
Environment variables are used to customize the behavior of Solo. This document provides a list of environment variables that can be configured to change the default behavior.
Environment Variables Used in Solo
User can configure the following environment variables to customize the behavior of Solo.
Table of environment variables
| Environment Variable | Description | Default Value |
|---|---|---|
SOLO_HOME | Path to the Solo cache and log files | ~/.solo |
SOLO_CHAIN_ID | Chain id of solo network | 298 |
DEFAULT_START_ID_NUMBER | First node account ID of solo test network | 0.0.3 |
SOLO_NODE_INTERNAL_GOSSIP_PORT | Internal gossip port number used by hedera network | 50111 |
SOLO_NODE_EXTERNAL_GOSSIP_PORT | External port number used by hedera network | 50111 |
SOLO_NODE_DEFAULT_STAKE_AMOUNT | Default stake amount for node | 500 |
SOLO_OPERATOR_ID | Operator account ID for solo network | 0.0.2 |
SOLO_OPERATOR_KEY | Operator private key for solo network | 302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137 |
SOLO_OPERATOR_PUBLIC_KEY | Operator public key for solo network | 302a300506032b65700321000aa8e21064c61eab86e2a9c164565b4e7a9a4146106e0a6cd03a8c395a110e92 |
FREEZE_ADMIN_ACCOUNT | Freeze admin account ID for solo network | 0.0.58 |
GENESIS_KEY | Genesis private key for solo network | 302e020100300506032b65700422042091132178e72057a1d7528025956fe39b0b847f200ab59b2fdd367017f3087137 |
LOCAL_NODE_START_PORT | Local node start port for solo network | 30212 |
NODE_CLIENT_MIN_BACKOFF | The minimum amount of time to wait between retries. | 1000 |
NODE_CLIENT_MAX_BACKOFF | The maximum amount of time to wait between retries. | 1000 |
NODE_CLIENT_REQUEST_TIMEOUT | The period of time a transaction or query request will retry from a “busy” network response | 600000 |
NODE_COPY_CONCURRENT | The number of concurrent threads to use when copying files to the node. | 4 |
PODS_RUNNING_MAX_ATTEMPTS | The maximum number of attempts to check if pods are running. | 900 |
PODS_RUNNING_DELAY | The interval between attempts to check if pods are running, in the unit of milliseconds. | 1000 |
NETWORK_NODE_ACTIVE_MAX_ATTEMPTS | The maximum number of attempts to check if network nodes are active. | 300 |
NETWORK_NODE_ACTIVE_DELAY | The interval between attempts to check if network nodes are active, in the unit of milliseconds. | 1000 |
NETWORK_NODE_ACTIVE_TIMEOUT | The period of time to wait for network nodes to become active, in the unit of milliseconds. | 1000 |
NETWORK_PROXY_MAX_ATTEMPTS | The maximum number of attempts to check if network proxy is running. | 300 |
NETWORK_PROXY_DELAY | The interval between attempts to check if network proxy is running, in the unit of milliseconds. | 2000 |
PODS_READY_MAX_ATTEMPTS | The maximum number of attempts to check if pods are ready. | 300 |
PODS_READY_DELAY | The interval between attempts to check if pods are ready, in the unit of milliseconds. | 2000 |
RELAY_PODS_RUNNING_MAX_ATTEMPTS | The maximum number of attempts to check if relay pods are running. | 900 |
RELAY_PODS_RUNNING_DELAY | The interval between attempts to check if relay pods are running, in the unit of milliseconds. | 1000 |
RELAY_PODS_READY_MAX_ATTEMPTS | The maximum number of attempts to check if relay pods are ready. | 100 |
RELAY_PODS_READY_DELAY | The interval between attempts to check if relay pods are ready, in the unit of milliseconds. | 1000 |
NETWORK_DESTROY_WAIT_TIMEOUT | The period of time to wait for network to be destroyed, in the unit of milliseconds. | 120 |
SOLO_LEASE_ACQUIRE_ATTEMPTS | The number of attempts to acquire a lock before failing. | 10 |
SOLO_LEASE_DURATION | The default duration in seconds for which a lock is held before expiration. | 20 |
ACCOUNT_UPDATE_BATCH_SIZE | The number of accounts to update in a single batch operation. | 10 |
NODE_CLIENT_PING_INTERVAL | The interval in milliseconds between node health pings. | 30000 |
NODE_CLIENT_PING_MAX_RETRIES | The maximum number of retries for node health pings. | 5 |
NODE_CLIENT_PING_RETRY_INTERVAL | The interval in milliseconds between node health ping retries. | 10000 |
GRPC_PORT | The gRPC port used for local node communication. | 50211 |
LOCAL_BUILD_COPY_RETRY | The number of times to retry local build copy operations. | 3 |
LOAD_BALANCER_CHECK_DELAY_SECS | The delay in seconds between load balancer status checks. | 5 |
LOAD_BALANCER_CHECK_MAX_ATTEMPTS | The maximum number of attempts to check load balancer status. | 60 |
JSON_RPC_RELAY_CHART_URL | The URL for the JSON-RPC relay Helm chart repository. | https://hiero-ledger.github.io/hiero-json-rpc-relay/charts |
MIRROR_NODE_CHART_URL | The URL for the Hedera mirror node Helm chart repository. | https://hashgraph.github.io/hedera-mirror-node/charts |
NODE_CLIENT_MAX_ATTEMPTS | The maximum number of attempts for node client operations. | 600 |
EXPLORER_CHART_URL | The URL for the Hedera Explorer Helm chart repository. | oci://ghcr.io/hiero-ledger/hiero-mirror-node-explorer/hiero-explorer-chart |
INGRESS_CONTROLLER_CHART_URL | The URL for the ingress controller Helm chart repository. | https://haproxy-ingress.github.io/charts |