Examples

• 1: Address Book Example
• 2: Custom Network Config Example
• 3: Network with an External PostgreSQL Database Example
• 4: Network with Block Node Example
• 5: Network With Domain Names Example
• 6: Node Create Transaction Example
• 7: Solo Inside a Cluster Example
• 8: Node Delete Transaction Example
• 9: Node Update Transaction Example

1 - Address Book Example

Yahcli Address Book Example

This is an example of how to use Yahcli to pull the ledger and mirror node address book. And to update the ledger address book. It updates File 101 (the ledger address book file) and File 102 (the ledger node details file).

NOTE: Mirror Node refers to File 102 as its address book.

Usage

To get the address book from the ledger, this requires a port forward to be setup on port 50211 to consensus node with node ID = 0.

[!NOTE] Due to file size, the Yahcli.jar file is stored with Git LFS (Large File Storage). You will need to install Git LFS prior to cloning this repository to automatically download the Yahcli.jar file. For instructions on how to install see: https://docs.github.com/en/repositories/working-with-files/managing-large-files/installing-git-large-file-storage

After cloning the repository, navigate to this directory and run the following command to pull the Yahcli.jar file:

git lfs install
git lfs pull

# try and detect if the port forward is already setup
netstat -na | grep 50211
ps -ef | grep 50211 | grep -v grep

# setup a port forward if you need to
kubectl port-forward -n "${SOLO_NAMESPACE}" pod/network-node1-0 50211:50211

Navigate to the examples/address-book directory in the Solo repository:

cd <solo-root>/examples/address-book

If you don’t already have a running Solo network, you can start one by running the following command:

task

To get the address book from the ledger, run the following command:

task get:ledger:addressbook

It will output the address book in JSON format to:

• examples/address-book/localhost/sysfiles/addressBook.json
• examples/address-book/localhost/sysfiles/nodeDetails.json

You can update the address book files with your favorite text editor.

Once the files are ready, you can upload them to the ledger by running the following command:

cd <solo-root>/examples/address-book
task update:ledger:addressbook

To get the address book from the mirror node, run the following command:

cd <solo-root>/examples/address-book
task get:mirror:addressbook

NOTE: Mirror Node may not pick up the changes automatically, it might require running some transactions through, example:

cd <solo-root>
npm run solo -- ledger account create
npm run solo -- ledger account create
npm run solo -- ledger account create
npm run solo -- ledger account create
npm run solo -- ledger account create
npm run solo -- ledger account update -n solo-e2e --account-id 0.0.1004 --hbar-amount 78910 

Stop the Solo network when you are done:

task destroy

2 - Custom Network Config Example

Custom Network Config Example

This example demonstrates how to create and manage a custom Hiero Hashgraph Solo deployment and configure it with custom settings.

What It Does

• Defines a custom network topology (number of nodes, namespaces, deployments, etc.)
• Provides a Taskfile for automating cluster creation, deployment, key management, and network operations
• Supports local development and testing of Hedera network features
• Can be extended to include mirror nodes, explorers, and relays

How to Use

1. Install dependencies:
   • Make sure you have Task, Node.js, npm, kubectl, and kind installed.
2. Customize your network:
   • Edit Taskfile.yml to set the desired network size, namespaces, and other parameters.
3. Run the default workflow:
   • From this directory, run:

     task
     

   • This will:
     • Install the Solo CLI
     • Create a Kind cluster
     • Set the kubectl context
     • Initialize Solo
     • Connect and set up the cluster reference
     • Create and configure the deployment
     • Add the cluster to the deployment
     • Generate node keys
     • Deploy the network with custom configuration files
     • Set up and start nodes
     • Deploy mirror node, relay, and explorer
4. Destroy the network:
   • Run:

     task destroy
     

   • This will:
     • Stop all nodes
     • Destroy mirror node, relay, and explorer
     • Destroy the Solo network
     • Delete the Kind cluster

Files

• Taskfile.yml — All automation tasks and configuration
• init-containers-values.yaml, settings.txt, log4j2.xml, application.properties — Example config files for customizing your deployment

Notes

• This example is self-contained and does not require files from outside this directory.
• All steps in the workflow are named for clear logging and troubleshooting.
• You can extend the Taskfile to add more custom resources or steps as needed.
• For more advanced usage, see the main Solo documentation.

3 - Network with an External PostgreSQL Database Example

External Database Test Example

This example demonstrates how to deploy a Hiero Hashgraph Solo network with an external PostgreSQL database using Kubernetes, Helm, and Taskfile automation.

What It Does

• Creates a Kind Kubernetes cluster for local testing
• Installs the Solo CLI and initializes a Solo network
• Deploys a PostgreSQL database using Helm
• Seeds the database and configures Solo to use it as an external database for the mirror node
• Deploys mirror node, explorer, relay, and runs a smoke test
• All steps are named for clear logging and troubleshooting

Usage

1. Install dependencies:

   • Task
   • Node.js
   • npm
   • kubectl
   • kind
   • Helm

2. Customize your deployment:

   • Edit Taskfile.yml to set database credentials, network size, and other parameters as needed.

3. Start the network:

   task
   

   This will:

   • Create the Kind cluster
   • Install and initialize Solo
   • Deploy and configure PostgreSQL
   • Seed the database
   • Deploy all Solo components (mirror node, explorer, relay)
   • Run a smoke test

4. Destroy the network:

   task destroy
   

   This will delete the Kind cluster and all resources.

Files

• Taskfile.yml — Automation tasks and configuration
• scripts/init.sh — Script to initialize the database
• Other config files as needed for your deployment

Notes

• All commands in the Taskfile are named for clarity in logs and troubleshooting.
• This example is self-contained and does not require files from outside this directory except for the Solo CLI npm package.
• You can extend the Taskfile to add more custom resources or steps as needed.

4 - Network with Block Node Example

Network with Block Node Example

This example demonstrates how to deploy a Hiero Hashgraph Solo network with a block node using Kubernetes and Taskfile.

What it does

• Creates a local Kubernetes cluster using Kind
• Deploys a Solo network with a single consensus node, mirror node, relay, explorer, and block node
• Provides tasks to install (start) and destroy the network

Usage

1. Install dependencies

   • Make sure you have Kind, kubectl, Node.js, and Task installed.

2. Deploy the network

   task
   

   This will:

   • Install the Solo CLI
   • Create a Kind cluster
   • Initialize Solo
   • Connect and set up the cluster reference
   • Create and configure the deployment
   • Add a block node
   • Generate node keys
   • Deploy the network, node, mirror node, relay, and explorer

3. Destroy the network

   task destroy
   

   This will:

   • Stop the node
   • Destroy the mirror node, relay, and explorer
   • Destroy the Solo network
   • Delete the Kind cluster

Tasks

• install: Installs and starts the Solo network with a block node, mirror node, relay, and explorer.
• destroy: Stops and removes all network components and deletes the Kind cluster.

Customization

You can adjust the number of nodes and other settings by editing the vars: section in the Taskfile.yml.

This example is self-contained and does not require any files from outside this directory.

5 - Network With Domain Names Example

Network with Domain Names Example

This example demonstrates how to deploy a Hiero Hashgraph Solo network with custom domain names for nodes, mirror node, relay, and explorer using Kubernetes and Taskfile.

What it does

• Creates a local Kubernetes cluster using Kind
• Deploys a Solo network with a single consensus node, mirror node, relay, explorer, and custom domain names for all services
• Provides tasks to install (start) and destroy the network

Usage

1. Install dependencies

   • Make sure you have Kind, kubectl, Node.js, and Task installed.

2. Deploy the network

   task
   

   This will:

   • Install the Solo CLI
   • Create a Kind cluster
   • Initialize Solo
   • Connect and set up the cluster reference
   • Create and configure the deployment
   • Generate node keys
   • Deploy the network, node, mirror node, relay, and explorer with custom domain names
   • Set up port forwarding for key services
   • Run a sample SDK connection script

3. Destroy the network

   task destroy
   

   This will:

   • Stop the node
   • Destroy the mirror node, relay, and explorer
   • Destroy the Solo network
   • Delete the Kind cluster

Tasks

• install: Installs and starts the Solo network with custom domain names for all components, sets up port forwarding, and runs a sample SDK connection.
• destroy: Stops and removes all network components and deletes the Kind cluster.

Customization

You can adjust the domain names and other settings by editing the vars: section in the Taskfile.yaml.

6 - Node Create Transaction Example

Node Create Transaction Example

This example demonstrates how to use the node add-prepare/prepare-upgrade/freeze-upgrade/add-execute commands against a network in order to manually write a NodeCreateTransaction.

What It Does

• Stands up a network with two existing nodes
• Runs solo node add-prepare to get artifacts needed for the SDK NodeCreateTransaction
• Runs a JavaScript program using the Hiero SDK JS code to run a NodeCreateTransaction
• Runs solo consensus dev-freeze prepare-upgrade and solo consensus dev-freeze freeze-upgrade to put the network into a freeze state
• Runs solo consensus dev-node-add execute to add network resources for a third consensus node, configures it, then restarts the network to come out of the freeze and leverage the new node
• Contains the destroy commands to bring down the network if desired

How to Use

1. Install dependencies:
   • Make sure you have Task, Node.js, npm, kubectl, and kind installed.
   • Run npm install while in this directory so that the solo-node-create-transaction.js script will work correctly when ran
2. Choose your Solo command:
   • Edit Taskfile.yml and comment out/uncomment depending on if you want to run Solo checked out of the repository or running Solo with an NPM install
     • SOLO_COMMAND: "npm run solo --": use this if running with solo source repository
     • SOLO_COMMAND: "solo": use this if running with installed version of Solo
3. Provide your custom application.properties if desired:
   • The following code is provided as an example and can be modified:

         # Copy and update application.properties
         cp resources/templates/application.properties {{ .APPLICATION_PROPERTIES }}
         echo "contracts.evm.ethTransaction.zeroHapiFees.enabled=false" >> {{ .APPLICATION_PROPERTIES }}
     

   • resources/templates/application.properties is the location of the Solo customized application.properties if you are sitting in the root of the Solo repository directory
   • You can download a copy here: https://github.com/hiero-ledger/solo/blob/main/resources/templates/application.properties
   • If you want you can download a copy, add your configurations, (be careful changing existing configurations as it could break Solo’s network), and then update the variable at the top to point to the new location: APPLICATION_PROPERTIES: "{{ .TEMPORARY_DIR }}/application.properties"
4. CN_VERSION:
   • The following is only used for certain decision logic. It is best to have it as close to possible as the local build you are using of consensus node: CN_VERSION: "v0.64.2"
   • The script is configured to leverage a local build of the Consensus Node, for example the main branch. You will need to clone the Hiero Consensus Node yourself and then from its root directory run ./gradlew assemble, this assumes you have all its prerequisites configured, see: https://github.com/hiero-ledger/hiero-consensus-node/blob/main/docs/README.md
5. Updating Directory Locations
   • The script was designed to run from this directory and so if you copy down the example without the repository or change other locations you might need to make changes
   • The dir: ../.. setting says to run the script two directories above, CN_LOCAL_BUILD_PATH can be updated to be relative to that, or can be changed to have the full path to the consensus node directory
   • The CN_LOCAL_BUILD_PATH actually points to the <hiero-consensus-node>/hedera-node/data, this is because this is the location of the artifacts that Solo needs to upload to the network node
6. Run the default workflow:
   • From this directory, run:

     task
     

   • This will:
     • Install the Solo CLI
     • Create a Kind cluster
     • Set the kubectl context
     • Initialize Solo
     • Connect and set up the cluster reference
     • Create and configure the deployment
     • Add the cluster to the deployment
     • Generate node keys
     • Deploy the network with custom configuration files
     • Set up and start nodes
     • Deploy mirror node, relay, and explorer
     • Perform the consensus node add as described in the ‘What It Does’ section above
7. Destroy the network:
   • Run:

     task destroy
     

   • This will:
     • Stop all nodes
     • Destroy mirror node, relay, and explorer
     • Destroy the Solo network
     • Delete the Kind cluster

Files

• Taskfile.yml — All automation tasks and configuration
• package.json - Contains the libraries for the solo-node-create-transaction.js to function
• package-lock.json - A snapshot of what was last used when npm install was ran, run npm ci to install these versions specifically
• solo-node-create-transaction.js - The script to run the Hiero SDK JS calls

Notes

• This example is self-contained and does not require files from outside this directory.
• All steps in the workflow are named for clear logging and troubleshooting.
• You can extend the Taskfile to add more custom resources or steps as needed.
• For more advanced usage, see the main Solo documentation.

7 - Solo Inside a Cluster Example

Running Solo Inside Cluster Example

This example demonstrates how to run the Solo network inside a privileged Ubuntu pod in a Kubernetes cluster for end-to-end testing. It automates the setup of all required dependencies and configures the environment for Solo to run inside the cluster.

What it does

• Renders Kubernetes manifests for a ServiceAccount and a privileged Ubuntu pod using templates.
• Applies these manifests to your cluster using kubectl.
• Waits for the pod to be ready, then copies and executes a setup script inside the pod.
• The setup script installs all required tools (kubectl, Docker, Helm, Node.js, etc.), installs the Solo CLI locally, and runs Solo commands to initialize and deploy a test network.

Usage

1. Install dependencies

   • Make sure you have kubectl and Task installed.
   • You need access to a running Kubernetes cluster (e.g., Kind, Minikube, GKE).

2. Run the test

   task
   

   This will:

   • Render and apply the ServiceAccount and Pod manifests
   • Copy and execute the setup script inside the pod
   • The pod will install all dependencies and use Solo to create a Hiero deployment

3. Clean up

   • Run the cleanup task to delete the pod and ServiceAccount:

     task cleanup
     

Customization

• You can modify the templates in the templates/ directory to change the pod configuration or ServiceAccount permissions.
• Edit the setup script to adjust which Solo commands are run or which dependencies are installed.

Tasks

• start: Sets up and runs the Solo network inside a privileged pod for end-to-end testing.
• cleanup: Deletes the privileged pod and ServiceAccount used for the test.

8 - Node Delete Transaction Example

Node Delete Transaction Example

This example demonstrates how to use the node add-prepare/prepare-upgrade/freeze-upgrade/add-execute commands against a network in order to manually write a NodeDeleteTransaction.

What It Does

• Stands up a network with two existing nodes
• Runs solo consensus dev-node-delete prepare to get artifacts needed for the SDK NodeDeleteTransaction
• Runs a JavaScript program using the Hiero SDK JS code to run a NodeDeleteTransaction
• Runs solo consensus dev-freeze prepare-upgrade and solo consensus dev-freeze freeze-upgrade to put the network into a freeze state
• Runs solo node delete-execute to configure the network to stop using the deleted node, then restarts the network to come out of the freeze and run with the new configurations
• Contains the destroy commands to bring down the network if desired

How to Use

1. Install dependencies:
   • Make sure you have Task, Node.js, npm, kubectl, and kind installed.
   • Run npm install while in this directory so that the solo-node-delete-transaction.js script will work correctly when ran
2. Choose your Solo command:
   • Edit Taskfile.yml and comment out/uncomment depending on if you want to run Solo checked out of the repository or running Solo with an NPM install
     • SOLO_COMMAND: "npm run solo --": use this if running with solo source repository
     • SOLO_COMMAND: "solo": use this if running with installed version of Solo
3. Provide your custom application.properties if desired:
   • The following code is provided as an example and can be modified:

         # Copy and update application.properties
         cp resources/templates/application.properties {{ .APPLICATION_PROPERTIES }}
         echo "contracts.evm.ethTransaction.zeroHapiFees.enabled=false" >> {{ .APPLICATION_PROPERTIES }}
     

   • resources/templates/application.properties is the location of the Solo customized application.properties if you are sitting in the root of the Solo repository directory
   • You can download a copy here: https://github.com/hiero-ledger/solo/blob/main/resources/templates/application.properties
   • If you want you can download a copy, add your configurations, (be careful changing existing configurations as it could break Solo’s network), and then update the variable at the top to point to the new location: APPLICATION_PROPERTIES: "{{ .TEMPORARY_DIR }}/application.properties"
4. CN_VERSION:
   • The following is only used for certain decision logic. It is best to have it as close to possible as the local build you are using of consensus node: CN_VERSION: "v0.64.2"
   • The script is configured to leverage a local build of the Consensus Node, for example the main branch. You will need to clone the Hiero Consensus Node yourself and then from its root directory run ./gradlew assemble, this assumes you have all its prerequisites configured, see: https://github.com/hiero-ledger/hiero-consensus-node/blob/main/docs/README.md
5. Updating Directory Locations
   • The script was designed to run from this directory and so if you copy down the example without the repository or change other locations you might need to make changes
   • The dir: ../.. setting says to run the script two directories above, CN_LOCAL_BUILD_PATH can be updated to be relative to that, or can be changed to have the full path to the consensus node directory
   • The CN_LOCAL_BUILD_PATH actually points to the <hiero-consensus-node>/hedera-node/data, this is because this is the location of the artifacts that Solo needs to upload to the network node
6. Run the default workflow:
   • From this directory, run:

     task
     

   • This will:
     • Install the Solo CLI
     • Create a Kind cluster
     • Set the kubectl context
     • Initialize Solo
     • Connect and set up the cluster reference
     • Create and configure the deployment
     • Add the cluster to the deployment
     • Generate node keys
     • Deploy the network with custom configuration files
     • Set up and start nodes
     • Deploy mirror node, relay, and explorer
     • Perform the node delete as described in the ‘What It Does’ section above
7. Destroy the network:
   • Run:

     task destroy
     

   • This will:
     • Stop all nodes
     • Destroy mirror node, relay, and explorer
     • Destroy the Solo network
     • Delete the Kind cluster

Files

• Taskfile.yml — All automation tasks and configuration
• package.json - Contains the libraries for the solo-node-delete-transaction.js to function
• package-lock.json - A snapshot of what was last used when npm install was ran, run npm ci to install these versions specifically
• solo-node-delete-transaction.js - The script to run the Hiero SDK JS calls

Notes

• This example is self-contained and does not require files from outside this directory.
• All steps in the workflow are named for clear logging and troubleshooting.
• You can extend the Taskfile to add more custom resources or steps as needed.
• For more advanced usage, see the main Solo documentation.

9 - Node Update Transaction Example

Node Update Transaction Example

This example demonstrates how to use the node add-prepare/prepare-upgrade/freeze-upgrade/add-execute commands against a network in order to manually write a NodeUpdateTransaction.

What It Does

• Stands up a network with two existing nodes
• Runs solo consensus dev-node-update prepare to get artifacts needed for the SDK NodeUpdateTransaction
• Runs a JavaScript program using the Hiero SDK JS code to run a NodeUpdateTransaction
• Runs solo consensus dev-freeze prepare-upgrade and solo consensus dev-freeze freeze-upgrade to put the network into a freeze state
• Runs solo consensus dev-node-update execute to update network resources for the changes to the updated node, then restarts the network to come out of the freeze and leverage the changes
• Contains the destroy commands to bring down the network if desired

How to Use

1. Install dependencies:
   • Make sure you have Task, Node.js, npm, kubectl, and kind installed.
   • Run npm install while in this directory so that the solo-node-update-transaction.js script will work correctly when ran
2. Choose your Solo command:
   • Edit Taskfile.yml and comment out/uncomment depending on if you want to run Solo checked out of the repository or running Solo with an NPM install
     • SOLO_COMMAND: "npm run solo --": use this if running with solo source repository
     • SOLO_COMMAND: "solo": use this if running with installed version of Solo
3. Provide your custom application.properties if desired:
   • The following code is provided as an example and can be modified:

         # Copy and update application.properties
         cp resources/templates/application.properties {{ .APPLICATION_PROPERTIES }}
         echo "contracts.evm.ethTransaction.zeroHapiFees.enabled=false" >> {{ .APPLICATION_PROPERTIES }}
     

   • resources/templates/application.properties is the location of the Solo customized application.properties if you are sitting in the root of the Solo repository directory
   • You can download a copy here: https://github.com/hiero-ledger/solo/blob/main/resources/templates/application.properties
   • If you want you can download a copy, add your configurations, (be careful changing existing configurations as it could break Solo’s network), and then update the variable at the top to point to the new location: APPLICATION_PROPERTIES: "{{ .TEMPORARY_DIR }}/application.properties"
4. CN_VERSION:
   • The following is only used for certain decision logic. It is best to have it as close to possible as the local build you are using of consensus node: CN_VERSION: "v0.64.2"
   • The script is configured to leverage a local build of the Consensus Node, for example the main branch. You will need to clone the Hiero Consensus Node yourself and then from its root directory run ./gradlew assemble, this assumes you have all its prerequisites configured, see: https://github.com/hiero-ledger/hiero-consensus-node/blob/main/docs/README.md
5. Updating Directory Locations
   • The script was designed to run from this directory and so if you copy down the example without the repository or change other locations you might need to make changes
   • The dir: ../.. setting says to run the script two directories above, CN_LOCAL_BUILD_PATH can be updated to be relative to that, or can be changed to have the full path to the consensus node directory
   • The CN_LOCAL_BUILD_PATH actually points to the <hiero-consensus-node>/hedera-node/data, this is because this is the location of the artifacts that Solo needs to upload to the network node
6. Run the default workflow:
   • From this directory, run:

     task
     

   • This will:
     • Install the Solo CLI
     • Create a Kind cluster
     • Set the kubectl context
     • Initialize Solo
     • Connect and set up the cluster reference
     • Create and configure the deployment
     • Add the cluster to the deployment
     • Generate node keys
     • Deploy the network with custom configuration files
     • Set up and start nodes
     • Deploy mirror node, relay, and explorer
     • Perform the consensus node update as described in the ‘What It Does’ section above
7. Destroy the network:
   • Run:

     task destroy
     

   • This will:
     • Stop all nodes
     • Destroy mirror node, relay, and explorer
     • Destroy the Solo network
     • Delete the Kind cluster

Files

• Taskfile.yml — All automation tasks and configuration
• package.json - Contains the libraries for the solo-node-update-transaction.js to function
• package-lock.json - A snapshot of what was last used when npm install was ran, run npm ci to install these versions specifically
• solo-node-update-transaction.js - The script to run the Hiero SDK JS calls

Notes

• This example is self-contained and does not require files from outside this directory.
• All steps in the workflow are named for clear logging and troubleshooting.
• You can extend the Taskfile to add more custom resources or steps as needed.
• For more advanced usage, see the main Solo documentation.