Practical Hedera workflows from the terminal
Hiero CLI is a command-line tool for developers working with the Hedera and Hiero ecosystems. Its purpose is not only to expose individual commands, but also make common Hedera workflows easier to run, repeat, test, and automate from the terminal.
The CLI can be installed globally with npm or Homebrew and used through the hcli command. It’s a tool for interacting with Hedera network, supporting actions such as creating accounts, sending transactions, managing fungible and non-fungible tokens, and working with mainnet, testnet, previewnet, and localnet environments.
The most useful way to think about Hiero CLI is this: Hiero CLI helps developers perform common Hedera operations quickly and consistently without writing one-off SDK scripts for every account, token, contract, network, or transaction workflow.
This document focuses only on the most important capabilities that are already described in the public repository, plugin documentation, or observable CLI examples.
1. Network and operator setup
One of the strongest practical use cases for Hiero CLI is working across different Hedera environments. Developers often need to switch between mainnet, testnet, previewnet and localnet depending on whether they are building a proof of concept, preparing a demo, testing locally, or running real network operations.
Developers can set a default network, configure an operator for a specific network, or use the global –network / -N flag to run a single command against a different network without changing the default configuration.
Example:
hcli network use --global testnet
hcli hbar transfer --amount 1 --to 0.0.789012 --network mainnetThis is useful for teams that mostly work on testnet or localnet, but occasionally need to run specific commands against another environment. It also reduces the risk of constantly editing configuration files or maintaining separate scripts for each network.
1.1 Secure key and credential handling
Because many CLI operations require signing transactions, secure handling of private keys is an important part of the developer workflow. Hiero CLI supports key references stored in its local credential system. These references use the kr_xxx format and can be used in commands instead of passing inline accountId:privateKey pairs every time.
This is useful because developers can configure credentials once and then reuse stored references across workflows. It also reduces the need to paste private keys directly into shell commands, scripts, or shared documentation.
Hiero CLI also exposes configuration for the default key manager, including local and local_encrypted options. For real workflows, teams should prefer stored credential references and avoid exposing private keys in terminal history, CI logs, or copied command examples.
2. Account, HBAR, and token workflows
Many Hedera workflows start with accounts and basic transfers. Hiero CLI provides commands for creating, importing, listing, viewing, deleting, and checking the balance of accounts. It also supports HBAR transfers.
Example:
hcli account create --balance 10 --name alice
hcli account balance --account alice
hcli hbar transfer --to 0.0.123456 --amount 1This is especially useful for preparing demos, integration tests, or proof-of-concept environments. Instead of writing a custom SDK script to create accounts, fund them, and check balances, a developer can run the required operations directly from the terminal.
Hiero CLI is also useful for token lifecycle workflows. The Token Plugin supports operations for fungible tokens and non-fungible tokens, including token creation, association, minting, and transfers.
Example fungible token flow:
hcli token create-ft \
--name demo-token \
--token-name "Demo Token" \
--symbol "DMT" \
--treasury alice \
--decimals 2 \
--initial-supply 1000 \
--supply-type FINITE \
--max-supply 10000
hcli token associate --token demo-token --account bob
hcli token transfer-ft \
--token demo-token \
--from alice \
--to bob \
--amount 100This kind of workflow is a strong fit for Hiero CLI because it represents a real developer need: creating a token, associating it with another account, transferring it, and verifying that the result is correct. These steps are common in testing, demos, tutorials, and early product development.
The CLI also returns readable command output, including values such as token IDs, transaction IDs, network information, and success status. This makes the tool useful not only for execution, but also for documentation and demo scenarios where the result needs to be clearly shown.
3. Smart contracts, batch transactions, and scheduled transactions
Hiero CLI also supports more advanced workflows, including smart contract deployment, batch transactions, and scheduled transactions.
For smart contracts, the simplest path is to use one of the built-in default contract templates. This allows a user to deploy a sample contract without preparing a Solidity file or setting up a separate contract project.
For example, a developer can deploy a built-in ERC-20 contract template like this:
hcli contract create --name my-token --default erc20Or deploy a built-in ERC-721 contract template like this:
hcli contract create --name my-nft --default erc721After deployment, Hiero CLI can also interact with standard ERC-20 and ERC-721 contract functions exposed by those specifications. For ERC-20 contracts, this includes common calls such as name, symbol, decimals, totalSupply, balanceOf, allowance, transfer, transferFrom, and approve. For ERC-721 contracts, this includes functions such as name, symbol, balanceOf, ownerOf, tokenURI, getApproved, isApprovedForAll, approve, setApprovalForAll, transferFrom, and safeTransferFrom.
This makes the contract workflow easier to demonstrate, especially for first-time users. After the CLI is configured and the operator account has enough funds, the user can deploy a sample contract with a short command. For more advanced use cases, Hiero CLI can also deploy and verify a custom Solidity file, but the built-in templates are the better starting point for a short introductory workflow.
Hiero CLI also works with batch transactions for documented commands. A batch can group supported operations and execute them together as an atomic transaction.
Example:
hcli batch create --name token-demo-batch --key alice
hcli token associate --token token-a --account bob --batch token-demo-batch
hcli batch execute --name token-demo-batchScheduled transactions are supported as well. They are useful when a supported transaction should be created first and then signed, verified, or completed later.
The key point is that these features should be described accurately: not every command can be batched or scheduled, but Hiero CLI enables these workflows for specific documented commands.
4. Plugin-based architecture
Hiero CLI is built around a plugin architecture. The public repository describes default plugins for areas such as accounts, tokens, networks, HBAR, credentials, topics, configuration, contracts, ERC-20, ERC-721, swaps, batches, and schedules.
This matters because Hiero CLI is not only a fixed set of commands. It is also designed as an extensible framework for organizing Hedera-related command-line functionality.
The plugin architecture helps keep functionality consistent across the CLI. Instead of every new feature becoming a separate script with its own conventions, plugins can use shared services for network configuration, state management, output formatting, logging, account operations, token operations, transaction execution, and other core capabilities.
For developers and maintainers, this is one of the most important long-term strengths of Hiero CLI. It gives the ecosystem a structured way to add new command-line capabilities (new plugins) while keeping the developer experience consistent.
Another important advantage is that developers are not limited to the default plugin set. Hiero CLI can be extended with community plugins created as separate projects. A team can build a custom plugin with its own commands, business logic, and state, and then register it in the CLI through the plugin-management plugin.
For example, a custom plugin can be added from a local project path:
hcli plugin-management add --path /path/to/my-custom-pluginThis makes Hiero CLI useful not only as a ready-made developer tool, but also as a foundation for ecosystem-specific automation and custom workflows.
5. AI-agent ready workflows and skills
Hiero CLI is also prepared for AI-assisted developer workflows. The repository includes structured skill files that describe how agents should use the CLI, including command syntax, global flags, plugin references, common workflows, and recovery steps for common errors.
This matters because an AI agent can use those skill definitions to understand how to run hcli commands more safely and consistently instead of guessing command names or options. The same idea also applies to extensibility: the repository includes a dedicated skill for scaffolding community plugins, which helps agents guide developers through creating a standalone plugin project.
In practice, this makes Hiero CLI easier to use in agent-assisted environments, where the agent can help configure networks, create accounts, deploy contracts, run token workflows, or scaffold new plugins based on documented CLI behavior.
6. How Hiero CLI compares to other blockchain CLIs
Many blockchain ecosystems have their own command-line tools. Solana has its own CLI for wallet, configuration, transfer, and cluster workflows. Ethereum developers often use tools such as Hardhat or Foundry for smart contract development, testing, deployment, and EVM interaction.
Hiero CLI should not be described as a generic replacement for those tools. Its value is more specific. It packages Hedera and Hiero workflows into a single terminal-based tool.
That is where Hiero CLI is strongest: not as a universal blockchain CLI, but as a practical developer tool for working with Hedera workflows consistently from the terminal.
