Transitioning Hedera CLI to Hiero CLI: Embracing Open Source and Extensibility

The Hedera command-line interface (CLI) is undergoing a significant evolution. We are excited to announce that the Hedera CLI is transitioning to the Hiero CLI, reflecting its new home under Linux Foundation Decentralized Trust’s (LFDT) Hiero project. This change aligns the tool with Hedera’s broader move to open governance and sets the stage for a more community-driven future.

In this post, we’ll explore why the CLI is moving to Hiero, what this means for developers, and how a new plugin-based architecture will empower the community in the future.

Aligning with Open Source: Hedera CLI Becomes Hiero CLI

In late 2024, Hedera open sourced its entire codebase, leading to the creation of Hiero—an open, vendor-neutral distributed ledger platform hosted under LFDT. Hiero inherits Hedera’s technology but operates with neutral, community-driven governance, emphasizing transparency and collaboration. 

The CLI’s transition to Hiero CLI is a natural step in this journey, eliminating confusion and unifying the tool with the rest of the open source ecosystem. By moving into the Hiero project, the CLI gains the benefits of LFDT’s neutral governance model, which fosters broader ecosystem growth and community contribution.

From Pet Project to Community Tool: A Brief History

The Hedera CLI began humbly as an internal pet project by the Developer Advocacy team to streamline common tasks. Developers were writing scripts for operations like creating accounts, managing tokens, and setting up topics, but these scripts required repetitive manual steps and copying of credentials between commands. The CLI was created to reduce these pain points by providing an interactive, stateful command-line tool. 

Early versions allowed chaining multiple actions and storing outputs (like new account IDs or keys) for reuse in subsequent commands, eliminating the need for manual copy-paste. Over time, features like internal state management, script blocks for multi-step workflows, and a broader command set were added. These enhancements turned the CLI into a powerful ally for different developer personas:

• Automation Seekers: Developers who automate repetitive tasks (account setup, token issuance, etc.) to save time and avoid errors.
  
  
• Project Teams: Teams integrating Hedera into CI/CD pipelines for end-to-end testing on testnet, mainnet, previewnet, or local networks.
  
  
• Explorers & Newcomers: Developers new to Hedera who want to experiment with network features quickly before writing full application code.

By addressing these needs, the CLI has become an intuitive gateway to Hedera’s capabilities. It simplifies complex operations and lowers the barrier to entry for anyone working on Hedera-based projects.

A Modular and Extensible Future: Plugin Architecture in Hiero CLI

Alongside the name change, the biggest evolution in the Hiero CLI is its revised architecture, which is being worked on right now. We are introducing an extensible plugin architecture that will allow the CLI to grow with the community’s needs while keeping the core stable and secure. Rather than a monolithic tool that only the core team can extend, the Hiero CLI will function as a platform on which anyone can build add-ons.

What is the plugin architecture? 

At a high level, we are establishing a stable Core inside the CLI and defining clear contracts for extensions. The Core provides a well-defined API for all Hedera/Hiero network operations (account management, token transfers, smart contract calls, etc.) and manages common concerns like configuration, state, and security. On top of this core, plugins can be developed and plugged in to introduce new commands or capabilities to the CLI. Each plugin will be a Node.js package that declares a manifest of its commands and any resources it needs, and the CLI will discover and integrate these at runtime.

Some key aspects of this design include:

• Stable Core API: The core CLI exposes a set of typed APIs (think of it as a thin wrapper around the official Hedera SDK) that plugins can use to interact with the network. This ensures that all network calls from plugins go through a consistent, well-tested interface.
  
  
• Extensibility via Plugins: Plugins can add new subcommands or features without requiring any changes to the CLI’s core codebase. For instance, a community contributor could write a plugin to support a new feature and distribute it as an NPM package. Users can install the plugin, and the CLI will automatically discover its commands and make them available. This eliminates the need to fork the CLI for custom features.
  
  
• Stateless by Design: Plugins are encouraged to be stateless by default. This means a plugin’s commands should not assume persistent local data beyond what the core provides. If a plugin does need to maintain state (for example, caching some results or saving a small database of custom entries), it must declare this in its manifest. The core will then provide namespaced storage for the plugin and handle persistence in a controlled manner. By centrally managing the plugin state, the CLI can prevent conflicts or corruption and ensure deterministic behavior across different environments.
  
  
• Secure and Deterministic Execution: The Hiero CLI will enforce a capability model and compatibility checks when loading plugins. In simpler terms, the core will check that a plugin is compatible with the CLI’s version (and the core API version) before enabling it, and it will only grant the plugin the minimal “capabilities” it needs. For example, a plugin might declare that it needs to use the network (submit transactions) and access a specific state namespace; another might only need read-only access to network info. The core acts as a gatekeeper, injecting only the allowed services into the plugin’s command handlers. This design not only enhances security (plugins operate under least privilege) but also ensures consistent behavior (all network calls, state writes, etc.) go through the same funnel).

From a developer’s perspective, using or writing a plugin will be straightforward. You’ll install a plugin like any other package, and it will register new commands in the CLI. The CLI will list these plugins and allow enabling/disabling them if needed. Our goal is to make extending the CLI as easy as writing a small Node.js module that hooks into this system, so the community can share and reuse enhancements. 

Empowering the Community: Build Your Own CLI Extensions

Moving to a plugin architecture is more than a technical upgrade. It’s a shift in philosophy towards greater community empowerment. By providing an extensible core, we want to enable developers to craft tools around the CLI for their specific needs. This means the Hiero CLI can serve as a foundation for an ecosystem of community-driven extensions:

• Custom Commands: Do you have a specialized use case or repetitive task unique to your project? You can create a plugin that introduces a new command.
  
  
• Domain-Specific Tooling: Community projects can package up plugins that target specific domains or services. Imagine plugins for things like NFT marketplace management, decentralized identity workflows, or DevOps integrations. Each plugin can live in its own repository and be maintained by subject-matter experts, while the core CLI provides a reliable base from which to run them.
  
  
• Custom CLI Distributions: The Hiero CLI’s modular design even allows for the possibility of custom CLI distributions. Because plugins can be composed, a team could assemble a set of plugins (including possibly some of the built-in commands as plugins) and release their own CLI binary that’s essentially Hiero CLI Core plus a tailored plugin set. 

In short, anyone can build on top of Hiero CLI to suit their needs without fragmenting the ecosystem. To follow along with the CLI journey, make sure to star the repository or click the “watch” button.