Add Solo as Recommended Local Development Environment
Summary
Local Node is being deprecated (support ends September 2026 — blog post. The local-node-deprecation.mdx snippet is already imported on several pages, but neither the EVM Developers, Native SDKs, Learn, nor Operators sections give developers a clear, actionable path to Solo as the replacement.
Goal: Surface Solo as the recommended local development environment across all relevant sections. Do not replicate Solo's own documentation — link out to https://solo.hiero.org/docs/. Keep additions brief and link-forward.
Affected pages
1. learn/networks/localnet/index.mdx — expand the Solo section
Replace the "More info coming soon..." placeholder with a concise description of what Solo is and what it runs (consensus node, mirror node, JSON-RPC relay, block explorer), why a developer would use it (Kubernetes-native, production-fidelity, CI-friendly), and a prominent link to the Solo docs. Note that Solo is the migration target for Local Node users. The page's existing numbered path (Local Node → Solo → Previewnet → Testnet) should be updated to reflect that Local Node is now deprecated and Solo is the first recommended step.
2. native/local-dev/setup-local-node.mdx
Add a callout or info block at the top (below the existing deprecation banner) pointing developers to Solo. Something like:
Looking for the recommended replacement? See Get started with Solo — a Kubernetes-native local network that replaces Local Node and is compatible with the Hiero SDKs.
Do not remove the existing Local Node instructions; they remain valid until September 2026. The page should just make the migration path obvious.
3. native/fundamentals/local-network.mdx
Add a Solo alternative path alongside the existing Local Node instructions. The page currently only describes connecting to a Local Node (127.0.0.1:50211). Add a section or callout noting that the same SDK configuration works against a Solo network, with a pointer to the Solo docs page Using Solo with Hiero SDKs.
4. EVM quickstart — evm/quickstart/get-test-hbar.mdx (and deploy guides)
Add a tip or callout noting that developers can use Solo as a local alternative to testnet for development and CI workflows, with links to:
5. Native SDK quickstarts (native/quickstart/javascript.mdx, go.mdx, java.mdx)
Same pattern as above — add a brief note that Solo can be used as a local network for development, with a link to Using Solo with Hiero SDKs.
6. learn/getting-started/choose-your-path.mdx
This is the first decision point for every developer entering the docs. Both the EVM and Native SDK paths send users to the testnet faucet as step 2, with no local development alternative offered. A developer who wants to build and iterate locally — without testnet rate limits, resets, or faucet dependencies — has no off-ramp here.
Add a brief note or callout after each path's steps indicating that Solo can be used as a local network alternative to testnet. Keep it lightweight — one sentence and a link to the Solo quickstart is enough. The goal is awareness at the entry point, not a full explanation.
7. learn/networks/testnet/index.mdx
The testnet page documents resets (which wipe contract state and account balances), throttles (including BUSY responses under load), and the structured communication process around resets. A developer reading this page who is still in active development is exactly the person who should be using Solo instead — local networks don't reset, don't throttle, and don't require faucet refills.
Add a short note at the top of the page, or under the "Test Network Resets" section, recommending Solo for active development workflows. Frame it as: use Solo while building and iterating; move to testnet when you're ready to validate against a shared, production-equivalent environment. Link to https://solo.hiero.org/docs/.
8. Operators section — Solo as a local test environment for infrastructure components
The Operators section currently covers deploying mirror nodes, JSON-RPC relays, and consensus nodes against mainnet, testnet, or previewnet. There is no guidance for operators who want to test their configuration locally before pointing at a shared network. Solo is the natural fit here: it runs a full stack — consensus node, mirror node, JSON-RPC relay, and block explorer — in a single Kubernetes deployment, giving operators a controlled, isolated environment to validate their setup.
operators/index.mdx
Add a callout or introductory note on the landing page noting that Solo can be used to test operator components locally. Link to the Solo docs and frame it as the recommended path for development and pre-production validation before connecting to testnet or mainnet.
operators/mirror-node/run-your-own/index.mdx
Operators self-hosting a mirror node need a network to test against. Add a note recommending Solo as a local test target — the mirror node can be pointed at a Solo network to validate importer configuration, REST API behaviour, and stream processing before connecting to a live network. Link to Accessing Solo Services in the Solo docs.
operators/json-rpc/index.mdx and/or operators/json-rpc/setup.mdx
The JSON-RPC relay setup page walks operators through running the relay locally or in a container. Solo ships with a relay as part of its full-stack deployment. Add a note that operators can use Solo to test relay configuration — custom chain IDs, rate limits, mirror node URL wiring — against a local network before deploying to production. Link to Using Solo with EVM Tools.
Out of scope
- Replicating Solo documentation in the Hedera docs
- Removing Local Node content before September 2026
- Writing Solo setup tutorials (Solo docs cover this)
Add Solo as Recommended Local Development Environment
Summary
Local Node is being deprecated (support ends September 2026 — blog post. The
local-node-deprecation.mdxsnippet is already imported on several pages, but neither the EVM Developers, Native SDKs, Learn, nor Operators sections give developers a clear, actionable path to Solo as the replacement.Goal: Surface Solo as the recommended local development environment across all relevant sections. Do not replicate Solo's own documentation — link out to https://solo.hiero.org/docs/. Keep additions brief and link-forward.
Affected pages
1.
learn/networks/localnet/index.mdx— expand the Solo sectionReplace the "More info coming soon..." placeholder with a concise description of what Solo is and what it runs (consensus node, mirror node, JSON-RPC relay, block explorer), why a developer would use it (Kubernetes-native, production-fidelity, CI-friendly), and a prominent link to the Solo docs. Note that Solo is the migration target for Local Node users. The page's existing numbered path (Local Node → Solo → Previewnet → Testnet) should be updated to reflect that Local Node is now deprecated and Solo is the first recommended step.
2.
native/local-dev/setup-local-node.mdxAdd a callout or info block at the top (below the existing deprecation banner) pointing developers to Solo. Something like:
Do not remove the existing Local Node instructions; they remain valid until September 2026. The page should just make the migration path obvious.
3.
native/fundamentals/local-network.mdxAdd a Solo alternative path alongside the existing Local Node instructions. The page currently only describes connecting to a Local Node (
127.0.0.1:50211). Add a section or callout noting that the same SDK configuration works against a Solo network, with a pointer to the Solo docs page Using Solo with Hiero SDKs.4. EVM quickstart —
evm/quickstart/get-test-hbar.mdx(and deploy guides)Add a tip or callout noting that developers can use Solo as a local alternative to testnet for development and CI workflows, with links to:
5. Native SDK quickstarts (
native/quickstart/javascript.mdx,go.mdx,java.mdx)Same pattern as above — add a brief note that Solo can be used as a local network for development, with a link to Using Solo with Hiero SDKs.
6.
learn/getting-started/choose-your-path.mdxThis is the first decision point for every developer entering the docs. Both the EVM and Native SDK paths send users to the testnet faucet as step 2, with no local development alternative offered. A developer who wants to build and iterate locally — without testnet rate limits, resets, or faucet dependencies — has no off-ramp here.
Add a brief note or callout after each path's steps indicating that Solo can be used as a local network alternative to testnet. Keep it lightweight — one sentence and a link to the Solo quickstart is enough. The goal is awareness at the entry point, not a full explanation.
7.
learn/networks/testnet/index.mdxThe testnet page documents resets (which wipe contract state and account balances), throttles (including
BUSYresponses under load), and the structured communication process around resets. A developer reading this page who is still in active development is exactly the person who should be using Solo instead — local networks don't reset, don't throttle, and don't require faucet refills.Add a short note at the top of the page, or under the "Test Network Resets" section, recommending Solo for active development workflows. Frame it as: use Solo while building and iterating; move to testnet when you're ready to validate against a shared, production-equivalent environment. Link to https://solo.hiero.org/docs/.
8. Operators section — Solo as a local test environment for infrastructure components
The Operators section currently covers deploying mirror nodes, JSON-RPC relays, and consensus nodes against mainnet, testnet, or previewnet. There is no guidance for operators who want to test their configuration locally before pointing at a shared network. Solo is the natural fit here: it runs a full stack — consensus node, mirror node, JSON-RPC relay, and block explorer — in a single Kubernetes deployment, giving operators a controlled, isolated environment to validate their setup.
operators/index.mdxAdd a callout or introductory note on the landing page noting that Solo can be used to test operator components locally. Link to the Solo docs and frame it as the recommended path for development and pre-production validation before connecting to testnet or mainnet.
operators/mirror-node/run-your-own/index.mdxOperators self-hosting a mirror node need a network to test against. Add a note recommending Solo as a local test target — the mirror node can be pointed at a Solo network to validate importer configuration, REST API behaviour, and stream processing before connecting to a live network. Link to Accessing Solo Services in the Solo docs.
operators/json-rpc/index.mdxand/oroperators/json-rpc/setup.mdxThe JSON-RPC relay setup page walks operators through running the relay locally or in a container. Solo ships with a relay as part of its full-stack deployment. Add a note that operators can use Solo to test relay configuration — custom chain IDs, rate limits, mirror node URL wiring — against a local network before deploying to production. Link to Using Solo with EVM Tools.
Out of scope