Skip to content

Add docs for --edge flag introduced in 0.72.0 Solo release #986

@SimiHunjan

Description

@SimiHunjan

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions