# Install firefly with Homebrew, Nix

Create and manage the Hyperledger FireFly stack for blockchain interaction. Version 1.4.0 via Homebrew; verified 2026-07-26. Also installable with nix: nix profile install nixpkgs#firefly.

## Install

```sh
sudo av install brew:firefly
```

Additional install commands:

### macOS

- Homebrew (100%):

```sh
brew install firefly
```

  Evidence: local Homebrew formula metadata

### Linux

- Nix (92%):

```sh
nix profile install nixpkgs#firefly
```

  Evidence: nixpkgs package indexes: pkgs/by-name/fi/firefly/package.nix from https://api.github.com/repos/NixOS/nixpkgs/git/trees/master?recursive=1

## Package facts

- **Package key:** brew:firefly
- **Package manager:** Homebrew
- **Version:** 1.4.0
- **Source summary:** Create and manage the Hyperledger FireFly stack for blockchain interaction
- **Homepage:** <https://hyperledger-firefly.github.io/firefly/latest/>
- **Repository:** <https://github.com/hyperledger-firefly/cli>
- **Last updated:** 2026-07-26T11:37:56+02:00
- **Generated:** 2026-08-03T19:37:03+00:00

## Executables

- firefly (alias)

## Install behavior

- Bottle: not available

## Freshness

- Page generated: 2026-08-03
- Package-manager version: 1.4.0
## Project history and usage

Hyperledger FireFly CLI is the local stack-management tool for Hyperledger FireFly, an open-source Web3 application stack. The CLI creates and manages local FireFly stacks so developers can build blockchain applications without manually assembling Docker, blockchain connectors, FireFly Core, Explorer, Sandbox, and supporting services.

### Project history

The firefly-cli repository was created in May 2021. Its README frames the tool as a way to create local FireFly stacks for offline blockchain app development, letting developers iterate before setting up production infrastructure.

FireFly itself is described by the official core repository as an open-source Supernode: a complete stack for enterprises to build and scale secure Web3 applications. The CLI is one piece of that ecosystem, alongside FireFly Core, Explorer, Sandbox, SDKs, blockchain connectors, token connectors, samples, and Helm charts.

### Adoption history

The CLI's adoption is intentionally developer-local. Official docs tell users to install Docker, Docker Compose, and openssl, then install the CLI via release binaries, Homebrew, or Go. That makes it a bootstrapper for trying FireFly rather than a production runtime by itself.

In the FireFly documentation, the CLI appears as one of the main tools next to FireFly Sandbox and FireFly Explorer. That position matters: the CLI is the shortest path from package installation to a running local network of FireFly Supernodes.

### How it is used

Users create a stack with `ff init <stack_name>`, start it with `ff start <stack_name>`, inspect logs with `ff logs`, stop it with `ff stop`, reset data with `ff reset`, remove it with `ff remove`, inspect it with `ff info`, and list stacks with `ff ls`.

The CLI is used when developers need an offline or local FireFly environment for blockchain app work. It hides much of the underlying service wiring while still leaving stack configuration and Docker Compose artifacts available for advanced customization.

### Why package nerds care

FireFly CLI is package-interesting because it is a Go-distributed executable that bootstraps a multi-service blockchain development environment. Installing a small CLI gives users a reproducible local stack rather than just another client binary.

It also captures a broader packaging pattern in cloud and Web3 tools: the package manager installs the orchestrator, and the orchestrator materializes Docker-based services, generated configuration, local credentials, UI tools, and protocol connectors.

### Timeline

- 2021: firefly-cli repository is created on GitHub.
- 2021: Early GitHub releases publish precompiled CLI artifacts.
- 2020s: Official FireFly docs position the CLI beside Sandbox and Explorer as a core developer tool.
- 2026: Repository metadata shows continued firefly-cli maintenance activity.

### Related projects

- Hyperledger FireFly Core is the main runtime and orchestration engine that the CLI helps run locally.
- FireFly Explorer and FireFly Sandbox are the companion developer tools surfaced in official docs.
- FireFly transaction manager, signer, EVM, Fabric, Tezos, Cardano, token, data-exchange, SDK, samples, and Helm chart repositories are neighboring pieces of the FireFly ecosystem.
- Docker and Docker Compose are required local dependencies for running CLI-managed stacks.

### Sources

- <https://github.com/hyperledger/firefly-cli>
- <https://raw.githubusercontent.com/hyperledger/firefly-cli/main/README.md>
- <https://hyperledger-firefly.github.io/firefly/latest/gettingstarted/firefly_cli/>
- <https://hyperledger-firefly.github.io/firefly/latest/overview/key_components/tools/>
- <https://github.com/hyperledger/firefly>
- <https://raw.githubusercontent.com/hyperledger/firefly/main/README.md>
- <https://api.github.com/repos/hyperledger/firefly-cli>


## Security Notes

narrow executable package without higher-risk signals.

- **Geiger risk:** green / low
- narrow executable package without higher-risk signals


## Configuration and credential file locations

These source-backed paths show where this package keeps local settings or durable credentials. Automic Vault can use them as review targets for secret scanning, migration, and command approval.


## Configuration files

- Unix: ~/.firefly/stacks/<stack_name>/runtime/config/firefly_core_0.yml, ~/.firefly/stacks/<stack_name>/docker-compose.override.yml

## Credential files

- Unix: test_users
## Other Package-Manager Records

- Nix - firefly: normalized package name match | nixpkgs package indexes: pkgs/by-name/fi/firefly/package.nix from https://api.github.com/repos/NixOS/nixpkgs/git/trees/master?recursive=1


## Combined YAML source

View the package source record on GitHub. [combined/firefly.yml](https://github.com/mxcl/pkgdb/blob/main/combined/firefly.yml)


## Sources

- pkg.so package database
- Geiger risk classifier
- curated configuration and credential file locations
- curated package history
- pkgdb category and tag curation
- external package-manager database matches
- cross-ecosystem install command graph