The edge command allows developers to use custom versions of components that override the default versions provided in the release.
Ex: CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1 solo one-shot single deploy --edge --dev
Suggested Docs (not tested/verified yet):
title: "One-Shot Deploy with Custom Component Versions"
weight: 55
description: >
Use the --edge flag and environment variables to deploy a Solo network with custom component versions without modifying source code or rebuilding.
type: docs
One-Shot Deploy with Custom Component Versions
Solo's one-shot deploy commands support an --edge flag that switches every component from its
stable default version to a separate set of "edge" versions. Each edge version is read from an
environment variable at startup, so you can pin any component to an arbitrary version without
editing version.ts or rebuilding Solo.
How It Works
Environment variable
└─► version.ts (HEDERA_PLATFORM_EDGE_VERSION, MIRROR_NODE_EDGE_VERSION, …)
└─► --edge flag triggers resolveOneShotComponentVersions(true)
└─► configManager.setFlag() pins each component version
└─► downstream deploy tasks use those versions
When --edge is not passed, Solo uses the stable defaults compiled into version.ts.
When --edge is passed, Solo reads the edge version constants — which themselves fall back to
the stable defaults if no environment variable is set.
Environment Variables
| Component |
Environment Variable |
Falls Back To |
| Consensus Node |
CONSENSUS_NODE_EDGE_VERSION |
HEDERA_PLATFORM_VERSION |
| Mirror Node |
MIRROR_NODE_EDGE_VERSION |
MIRROR_NODE_VERSION |
| JSON-RPC Relay |
RELAY_EDGE_VERSION |
HEDERA_JSON_RPC_RELAY_VERSION |
| Explorer |
EXPLORER_EDGE_VERSION |
EXPLORER_VERSION |
| Block Node |
BLOCK_NODE_EDGE_VERSION |
BLOCK_NODE_VERSION |
| Solo Chart |
SOLO_CHART_EDGE_VERSION |
SOLO_CHART_VERSION |
You only need to set the variables for the components you want to override — all others fall back
to their compiled-in edge defaults (which themselves fall back to the stable defaults).
Command Reference
Single-node deploy
CONSENSUS_NODE_EDGE_VERSION=<version> \
MIRROR_NODE_EDGE_VERSION=<version> \
solo one-shot single deploy --edge [--dev] [additional flags]
Multi-node deploy
CONSENSUS_NODE_EDGE_VERSION=<version> \
MIRROR_NODE_EDGE_VERSION=<version> \
solo one-shot multi deploy --edge [--dev] [additional flags]
Falcon deploy
CONSENSUS_NODE_EDGE_VERSION=<version> \
MIRROR_NODE_EDGE_VERSION=<version> \
solo one-shot falcon deploy --edge [--dev] [additional flags]
Examples
Deploy with a custom Consensus Node release candidate
CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1 \
solo one-shot single deploy --edge --dev
What happens:
CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1 overrides HEDERA_PLATFORM_EDGE_VERSION at runtime
--edge tells Solo to use the edge version set instead of stable defaults
- All other components (Mirror Node, Relay, Explorer) use their compiled-in edge defaults
--dev skips certificate and key validation for local development
Deploy with custom Consensus Node and Mirror Node versions
CONSENSUS_NODE_EDGE_VERSION=v0.73.0 \
MIRROR_NODE_EDGE_VERSION=v0.153.1 \
solo one-shot single deploy --edge --dev
Override all components
CONSENSUS_NODE_EDGE_VERSION=v0.73.0 \
MIRROR_NODE_EDGE_VERSION=v0.153.1 \
RELAY_EDGE_VERSION=0.77.0 \
EXPLORER_EDGE_VERSION=27.0.0 \
BLOCK_NODE_EDGE_VERSION=v0.32.0 \
SOLO_CHART_EDGE_VERSION=0.64.0 \
solo one-shot single deploy --edge --dev
Export variables for a session
If you are running multiple commands or iterating during development, export the variables
for the duration of your shell session:
export CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1
export MIRROR_NODE_EDGE_VERSION=v0.153.1
# Now every one-shot deploy in this session uses those versions
solo one-shot single deploy --edge --dev
# Destroy and redeploy without re-typing the variables
solo one-shot single destroy
solo one-shot single deploy --edge --dev
Verifying the Versions in Use
After deploy starts, check the Solo log to confirm the versions were picked up:
tail -f $HOME/.solo/logs/solo.log | jq '.msg,.version // empty'
You can also inspect the running Helm releases:
# List all releases and their chart versions
helm list -A
# Inspect the values used for a specific release
helm get values <release-name> -n <namespace>
To confirm the consensus node image tag specifically:
kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
Version Format Reference
| Component |
Format |
Example |
| Consensus Node |
vMAJOR.MINOR.PATCH[-qualifier] |
v0.74.0-rc.1, v0.73.0 |
| Mirror Node |
vMAJOR.MINOR.PATCH |
v0.153.1 |
| JSON-RPC Relay |
MAJOR.MINOR.PATCH |
0.77.0 |
| Explorer |
MAJOR.MINOR.PATCH |
27.0.0 |
| Block Node |
vMAJOR.MINOR.PATCH[-qualifier] |
v0.32.0 |
| Solo Chart |
MAJOR.MINOR.PATCH |
0.64.0 |
Note: Consensus Node, Mirror Node, and Block Node versions are prefixed with v.
Relay, Explorer, and Solo Chart versions are not prefixed.
Without --edge (Stable Defaults)
Omitting --edge always uses the versions compiled into version.ts regardless of any
CONSENSUS_NODE_EDGE_VERSION or similar environment variables being set. The non-edge env vars
(CONSENSUS_NODE_VERSION, MIRROR_NODE_VERSION, etc.) do affect the stable defaults but are set
at build time — they do not override anything at runtime when using a pre-built Solo binary such as
the Homebrew release.
# Uses compiled-in stable defaults — env vars have no effect at runtime
solo one-shot single deploy --dev
Troubleshooting
The version I set is not being used.
Ensure you are passing --edge. Without it, resolveOneShotComponentVersions(false) returns
stable defaults and the edge environment variables are ignored entirely.
Solo is ignoring my environment variable.
Verify the variable is exported in the same shell process that runs Solo:
echo $CONSENSUS_NODE_EDGE_VERSION # should print your value
If you set it inline (e.g. FOO=bar solo ...), confirm the variable name matches exactly —
they are case-sensitive.
The deploy fails with an image pull error.
The version tag you specified may not exist in the container registry. Double-check the tag
against the official release list for that component before deploying.
The edge command allows developers to use custom versions of components that override the default versions provided in the release.
Ex: CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1 solo one-shot single deploy --edge --dev
Suggested Docs (not tested/verified yet):
title: "One-Shot Deploy with Custom Component Versions"
weight: 55
description: >
Use the --edge flag and environment variables to deploy a Solo network with custom component versions without modifying source code or rebuilding.
type: docs
One-Shot Deploy with Custom Component Versions
Solo's one-shot deploy commands support an
--edgeflag that switches every component from itsstable default version to a separate set of "edge" versions. Each edge version is read from an
environment variable at startup, so you can pin any component to an arbitrary version without
editing
version.tsor rebuilding Solo.How It Works
When
--edgeis not passed, Solo uses the stable defaults compiled intoversion.ts.When
--edgeis passed, Solo reads the edge version constants — which themselves fall back tothe stable defaults if no environment variable is set.
Environment Variables
CONSENSUS_NODE_EDGE_VERSIONHEDERA_PLATFORM_VERSIONMIRROR_NODE_EDGE_VERSIONMIRROR_NODE_VERSIONRELAY_EDGE_VERSIONHEDERA_JSON_RPC_RELAY_VERSIONEXPLORER_EDGE_VERSIONEXPLORER_VERSIONBLOCK_NODE_EDGE_VERSIONBLOCK_NODE_VERSIONSOLO_CHART_EDGE_VERSIONSOLO_CHART_VERSIONYou only need to set the variables for the components you want to override — all others fall back
to their compiled-in edge defaults (which themselves fall back to the stable defaults).
Command Reference
Single-node deploy
Multi-node deploy
Falcon deploy
Examples
Deploy with a custom Consensus Node release candidate
What happens:
CONSENSUS_NODE_EDGE_VERSION=v0.74.0-rc.1overridesHEDERA_PLATFORM_EDGE_VERSIONat runtime--edgetells Solo to use the edge version set instead of stable defaults--devskips certificate and key validation for local developmentDeploy with custom Consensus Node and Mirror Node versions
Override all components
Export variables for a session
If you are running multiple commands or iterating during development, export the variables
for the duration of your shell session:
Verifying the Versions in Use
After deploy starts, check the Solo log to confirm the versions were picked up:
You can also inspect the running Helm releases:
To confirm the consensus node image tag specifically:
Version Format Reference
vMAJOR.MINOR.PATCH[-qualifier]v0.74.0-rc.1,v0.73.0vMAJOR.MINOR.PATCHv0.153.1MAJOR.MINOR.PATCH0.77.0MAJOR.MINOR.PATCH27.0.0vMAJOR.MINOR.PATCH[-qualifier]v0.32.0MAJOR.MINOR.PATCH0.64.0Note: Consensus Node, Mirror Node, and Block Node versions are prefixed with
v.Relay, Explorer, and Solo Chart versions are not prefixed.
Without
--edge(Stable Defaults)Omitting
--edgealways uses the versions compiled intoversion.tsregardless of anyCONSENSUS_NODE_EDGE_VERSIONor similar environment variables being set. The non-edge env vars(
CONSENSUS_NODE_VERSION,MIRROR_NODE_VERSION, etc.) do affect the stable defaults but are setat build time — they do not override anything at runtime when using a pre-built Solo binary such as
the Homebrew release.
# Uses compiled-in stable defaults — env vars have no effect at runtime solo one-shot single deploy --devTroubleshooting
The version I set is not being used.
Ensure you are passing
--edge. Without it,resolveOneShotComponentVersions(false)returnsstable defaults and the edge environment variables are ignored entirely.
Solo is ignoring my environment variable.
Verify the variable is exported in the same shell process that runs Solo:
If you set it inline (e.g.
FOO=bar solo ...), confirm the variable name matches exactly —they are case-sensitive.
The deploy fails with an image pull error.
The version tag you specified may not exist in the container registry. Double-check the tag
against the official release list for that component before deploying.