Using Environment Variables

Overview

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

Setting environment variables

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

• Bash / Zsh
• PowerShell

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

# For the current session
export CONSENSUS_NODE_VERSION=v0.73.0

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

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

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

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

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

General

Network and Node Identity

Operator and Key Configuration

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

Node Client Behaviour

Pod and Network Readiness

Block Node

Relay Node

Mirror Node

Load Balancer

Lease Management

Component Versions

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

Edge Component Versions

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

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

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

Helm Chart URLs

Network Load Generator

One-Shot Deployment

Pinning Component Versions

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

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

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

Note:

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

Image Cache

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

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