ledger-live: the monorepo behind the Ledger Wallet desktop, mobile and CLI apps

One repository, three apps and 150 plus packages

The ledger-live repository is a mono-repository for the Ledger Wallet apps and related packages, and it was previously known as Ledger Live. It houses the companion apps for Ledger hardware wallet signers, letting users manage crypto, install apps on the device, update firmware, and verify and sign transactions. The apps are three. Ledger Wallet Desktop, or LWD, is built with Electron. Ledger Wallet Mobile, or LWM, is the Android and iOS app built with React Native. The Wallet CLI is described as an agent-optimized CLI toolset, which is a notable phrase given that the repository now carries .agents/, CLAUDE.md, .codex/ and .cursor/ directories at the root, all of which are agent configuration surfaces. Production apps are downloaded from download.live.ledger.com rather than built by consumers, so this repository is primarily a source of truth and a publishing pipeline. Alongside the apps, the repository is home to 150 or more library packages, consumed both internally by the apps and externally by third-party developers integrating with Ledger hardware, with public packages published to npm by the ldg-github-ci account.

The toolchain is mise, pnpm, Nx and Changesets, and Node 24 is the floor

The repository pins its local tool versions with mise, manages npm packages with pnpm workspaces, orchestrates tasks with Nx, and handles changelogs and publishing with Changesets. Installing everything is two commands:

mise install
pnpm i

The engine field in the root package.json requires Node 24 or newer, which is a high floor and the first thing to check on an older machine. The root package itself is private, versioned 0.0.0, and carries the licence field MIT AND Apache-2.0, which is the SPDX form for a repository where different sub-projects carry different licences. The README also notes that you should check each project's LICENSE file, most of them being under MIT. The scripts in the root package.json show how much of the work Nx does. Building the libraries runs nx run-many with the build target over @ledgerhq packages, excluding the dummy apps and the CLI packages, with a parallelism of 20. There are separate targets for the CLI, the wallet CLI, coin packages, actions and the dummy test apps, and a clean target that runs git clean with the ignored-files flag and then rewrites the Nx cache config.

The directory layout encodes where new code is supposed to go

The overall structure table in the README is the most useful document in the repository for a newcomer, because it is a statement about architecture rather than about files. The apps/ directory holds the desktop, mobile and CLI apps. The domain/ directory holds domain packages, split into entity/ and api/. The features/ directory holds features shared across apps, and shared/ holds cross-cutting packages used in domain, features and apps. Then there is libs/, described as legacy shared libraries, maintained but not grown, with a note pointing to libs/README.md. That distinction between the growing directories and the frozen one is a useful signal about where a contribution belongs. The remaining directories have clearly bounded roles: devtools/ for internal developer tooling and shell helpers, docs/ for repo-wide canonical documentation, .agents/ for shared agent-facing docs, e2e/ for end-to-end tests using Detox and Speculos, tests/ for dummy apps used in testing, tools/ for CI actions, GitHub bots and Nx plugins, scripts/ for repo-level utility scripts, and patches/ for patchedDependencies that are auto-applied during pnpm install. The README links the monorepo architecture document as the place that says where new code goes.

Sibling repositories hold a large share of the packages you import

One of the practical realities of this monorepo is that a meaningful share of the @ledgerhq packages you use are not built here. The README lists the sibling repositories and the key packages each one publishes. device-sdk-ts holds the device management kit, the context module, the device signer and device transport kits, and the Speculos device controller. ts-libs holds the auth package, devices, the hardware transport and its mocker, live-network, live-promise and psbtv2. The wallet-api repository holds the wallet API client, its React binding, the core, the server and a simulator. coin-modules holds coin-stellar and coin-xrp. The lumen repository holds the user interface packages for React and React Native, shared utilities and visualisation packages, and crypto-icons holds the icon set. There are also ledger-zcash-utils, and alpaca-coin-module which holds the coin module framework. This matters when you are tracking a bug or a version bump, because the package you depend on may be released from a different repository with its own cadence, and this repository's version numbers will not tell you when it changed.

Nightly builds are published with an @nightly dist-tag

The release process is worth understanding because it is the difference between the stable package you depend on and the one a maintainer is testing. Desktop binaries and Android APKs are attached to the build workflows, visible in GitHub Actions. Authorised users can also reach TestFlight, Firebase App Distribution and a separate ledger-live-build repository. Nightly packages are published under the @nightly dist-tag, with the README giving the example npm i @ledgerhq/hw-app-eth@nightly. The Wiki has a Release Process page covering nightlies in more detail. The versioning itself is per package rather than per repository, which is what you see in the release list: live-mobile at 4.24.0 and @ledgerhq/live-desktop at 4.24.0 on the same day, followed by live-mobile at 4.23.1 a few days earlier. So the desktop and mobile apps move together in version, the mobile app releases on its own schedule in between, and the rest of the 150 or more packages follow their own timelines.

The lint targets enforce structure, boundaries and translation keys

Beyond formatting, the root scripts show a set of structural checks that are specific to a monorepo of this size. There is a lint:boundaries target that runs enforce-boundaries, and a lint:structure target that runs the lint:structure task across workspaces, plus lint:tool-config for tool configuration and lint:i18n-keys for enforcing i18n keys. Enforcing boundaries means the dependency rules between domain, features, shared and apps are checked automatically, which is how a large monorepo stops turning into a ball of cross imports. The i18n key check is the same idea for translation files, and it matters in a product that ships in many languages, because a missing or stale key is a runtime bug that no type checker catches. The repository also has a gitleaks.toml and a gitleaksignore, so secret scanning is part of the pipeline, a CODEOWNERS file for review routing, commitlint.config.js and commitlint.types.js for commit message conventions, a renovate.json5 for dependency updates, knip configuration for unused code detection, and sonar-project.properties with a matching tsconfig for the Sonar analysis. The result is a repository that treats repository hygiene as enforced policy rather than as reviewer discipline.

Contributing is split into author guidance and reviewer guidance

The README points contributors at two separate documents and assigns each to a different audience. CONTRIBUTING.md is for pull request authors and covers branch conventions, the pull request lifecycle, and the quality gates to clear before requesting review. REVIEWING.md is for code-owner reviewers and covers how to scope a review, what to look for, and how to give feedback. That split is a small but telling piece of project design. Most projects have a single contributing guide that mixes both audiences, and it ends up read by neither. Documentation discovery is also layered, with three levels listed. Repo-wide documentation is AGENTS.md and then docs/. Task-specific agent documentation sits in .agents/skills/. And the local README in the workspace or package you are working in is the third layer. For a repository this size, the local README is likely to be the one that answers your actual question, and the repo-wide documents are for understanding the rules that apply everywhere. External developers are also pointed at the Ledger Developer Portal, which carries guides for getting started and for adding support for a new blockchain.

Editorial conclusion

ledger-live suits developers integrating with Ledger hardware who need the published @ledgerhq packages, engineers working inside the Ledger Wallet codebase, and anyone who wants to read a large TypeScript monorepo with explicit architectural rules. It is the wrong choice if you want the wallet application itself, since that is distributed as a signed binary rather than built from this repository by outsiders, and it is the wrong choice for a small project, since the tooling assumes a monorepo of this size. Verify first that your Node version satisfies the engine requirement of 24 or newer, which is a high floor, which of the sibling repositories your package actually comes from, and that the workspace you plan to touch has a README describing its own commands.

Frequently asked questions

Official sources

1. Issues
2. LedgerHQ/ledger-live on GitHub
3. License: MIT
4. README
5. Releases