# indy-node runs the validators behind a Sovrin-style identity ledger

> indy-node is the server side of Hyperledger Indy, a distributed ledger for decentralized identity built on the RBFT protocol, with plenum supplying the core pool logic. The code is mature and well documented, but the released version line stopped in 2024 and the platform work moved to a new Ubuntu based branch, which is where the adoption risk sits.

**hyperledger-indy/indy-node** — The server portion of a distributed ledger purpose-built for decentralized identity.

- Repository: https://github.com/hyperledger-indy/indy-node
- Website: https://wiki.hyperledger.org/display/indy
- Stars: 703 · Forks: 647
- Language: Python
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/hyperledger-indy-indy-node

## Validators and observers for a self-sovereign identity ledger

indy-node is the server portion of a distributed ledger built for decentralized identity. The codebase covers everything needed to run nodes, which the project describes as validators and or observers, providing a self-sovereign identity ecosystem on top of a distributed ledger. The economics of that word ecosystem are worth unpacking. This is not a general purpose blockchain with an identity module bolted on. The transactions the ledger understands are identity transactions, and the project notes that indy-node extends plenum's base pool functionality with specific transaction support, naming CLAIM_DEF, SCHEMA and POOL_UPGRADE as examples. A node in this design is a validator that participates in consensus over these transactions, or an observer that follows the ledger without participating. That split is the standard way to separate trust from access, and it is why the repository ships both a pool implementation and scripts for preparing a test network.

## RBFT consensus sits on top of the plenum pool

Indy has its own distributed ledger based on RBFT, the protocol the project treats as its consensus layer, and the implementation is not written from scratch here. The repository structure section names indy-plenum as the base implementation of the distributed ledger, describing it as the heart of the distributed ledger technology inside Hyperledger Indy. The practical consequence is stated plainly for contributors: if you want to work with Indy Node you will need the Plenum code as well in most cases, and you will work with two projects at the same time. The project's own guidance is that most people will need to make changes in Plenum in order to contribute to Indy. Two further dependencies matter for understanding the system. ursa is Hyperledger's shared crypto library, and it carries the BLS multi-signature crypto needed for state proofs support in Indy. indy-sdk is the official SDK for Indy, containing the client and anoncreds implementation, and the project is explicit that you do not need it to contribute to indy-node but should use it for your own applications dealing with the Indy ecosystem.

## Sovrin packages are prepackaged genesis for a validator pool

The relationship with the Sovrin Foundation is worth understanding before you deploy, because it is easy to assume a dependency that does not exist. The code is independent from but commonly associated with the Sovrin Foundation, which is described as a public utility for identity built on top of this codebase. People who install the sovrin packages, for example with sudo apt install sovrin, get prepackaged genesis transactions that integrate with an Indy validator pool using Sovrin's governance and trust framework. The key sentence is the one that follows: it is possible to use Indy Node with a different network, using whatever conventions a community chooses. So Sovrin is a packaging and governance convenience, not a hard coupling. The genesis transactions are the anchor of a network's membership, and using a community's own set instead of Sovrin's means you own that decision, along with the consequences of the conventions you pick.

## The main branch moved to Ubuntu 20.04 in April 2023

The announcement at the top of the README is the most important operational fact in the repository, and it is easy to read past. On April 12 2023 the project branches changed. The main branch now contains the Ubuntu 20.04 work stream, and the previous main branch, which contained the Ubuntu 16.04 work stream, was moved to the ubuntu-16.04 branch. The mechanics are listed in a few lines: the old main was renamed to ubuntu-16.04 with its associated pull requests retargeted, and ubuntu-20.04-upgrade was set as the default branch before being renamed to main. The project asked users to switch to the new code and thanked them for patience while the workflows and documentation were stabilised. What this tells an adopter is that the platform target moved and that the older stream was kept for continuity rather than developed forward. If your deployment is pinned to a distribution release matching the older stream, you are on a branch that exists to be left, and the README does not describe a plan to bring the two streams back together.

## Packaging requires Python 3.8 or newer

The setup.py in the repository root carries the version check itself, and the failure message is explicit about what to do.

```python
v = sys.version_info
if sys.version_info < (3, 8):
    msg = "FAIL: Requires Python 3.8 or later, " \
          "but setup.py was run using {}.{}.{}"
```

The script exits with status 1 and prints a note that installation failed and setup.py should be run using python3. The rest of the packaging is conventional setuptools. Packages are found with find_packages, excluding the docs directories, and the data directory is added as a package, which matters because the runtime data files are part of the distribution. The package_data declaration includes txt, md, rst, json, conf, html, css, ico and png files as well as LICENSE, LEGAL and .indy files, and include_package_data is on. The test dependencies tell you what the test suite expects, with attrs, pytest, pytest-xdist, pytest-forked, pytest-asyncio and a pinned python3-indy at 1.16.0.post236. There is also a MANIFEST.in and a generate_manifest.sh in the tree, and bump_version.sh for cutting a release.

## Scripts, devcontainer and a repository built for two projects at once

Beyond the package, the repository is arranged around the idea that you work on indy-node and indy-plenum together. The scripts directory holds the tools that run against an installed node, in particular the scripts to start nodes, generate keys and prepare a test network, which is the entry point for anyone who wants to stand up a local ledger. The.devcontainer folder contains scripts for configuring a development environment, and the repository also carries a.gitpod.Dockerfile and a.gitpod.yml, with the README offering a Gitpod badge for opening the project in a browser based environment. That is a real convenience for a code base with heavy native dependencies. The rest of the tree shows the shape of a mature project: acceptance tests in their own directory, a pool_automation directory, a design directory, a docs directory, a sample directory, environment tooling, a runner.py entry point, a node_reg.conf, and a post-setup.py. The sample directory holds the.indy fixtures that application developers actually work with, including acme-job-application.indy, faber-request.indy and the matching connection request files.

## A 1.13 release line that stopped in 2024

The release history is the part that should shape your decision. The most recent tagged releases are v1.13.2 from 2024-02-09, with v1.13.2-rc6 and v1.13.2-rc5 before it in 2023, and the repository is not archived, with the last push on 2026-05-11. So the code is still being touched, but the version line has not moved since early 2024, and the most recent activity is on a branch that the project itself describes as a work stream still being stabilised. There is a CHANGELOG.md in the root for the detail, and MAINTAINERS.md, CODEOWNERS, SECURITY.md and the Hyperledger Jira project named INDY, where bugs, stories and the backlog are tracked. The licence is Apache 2.0 with a LICENSE file in the root, which is permissive for a server component and lets you embed it without copyleft obligations, subject to the usual review of your own use. The honest summary is that this is a mature, well structured code base whose upstream platform work is unsettled, which suits a team maintaining an existing Indy deployment better than a team choosing a foundation this year.

## Conclusion

Adopt indy-node when you are running or extending a Sovrin style identity network and your team can live with a code base whose last tagged release is v1.13.2 from 2024-02-09 and whose last push was on 2026-05-11. Skip it if you are starting a new identity system today, because the platform work moved to the Ubuntu 20.04 stream on the main branch and the older stream is parked on the ubuntu-16.04 branch, which tells you where the project thinks the future is. Before you plan an upgrade, read the announcement that explains the branch rename, confirm which branch your distribution packages come from, and decide early whether your changes belong in indy-plenum, which the project describes as the heart of the ledger technology.

## FAQ

### What is indy-node used for?

It is the server side of Hyperledger Indy, a distributed ledger for decentralized identity. It provides the functionality to run validator and observer nodes on an Indy pool built on the RBFT protocol.

### Do I need indy-plenum to work with indy-node?

In most cases yes. The project describes indy-plenum as the heart of the distributed ledger technology inside Hyperledger Indy, and says contributors will usually need to work with both projects at the same time.

### Is indy-node tied to the Sovrin network?

No. The code is independent from but commonly associated with the Sovrin Foundation. The sovrin packages ship prepackaged genesis transactions for a Sovrin validator pool, but Indy Node can be used with a different network using whatever conventions a community chooses.

### What changed in the indy-node branches in April 2023?

The main branch became the Ubuntu 20.04 work stream, and the previous main branch with the Ubuntu 16.04 work stream was moved to the ubuntu-16.04 branch. The ubuntu-20.04-upgrade branch was set as default and then renamed to main.

### Which Python version does indy-node require?

Python 3.8 or later. The setup.py in the repository root checks the interpreter version, prints a failure message and exits when it is older than that.

## Sources

- [hyperledger-indy/indy-node on GitHub](https://github.com/hyperledger-indy/indy-node)
- [License: Apache-2.0](https://github.com/hyperledger-indy/indy-node/blob/main/LICENSE)
- [Project website](https://wiki.hyperledger.org/display/indy)
- [README](https://github.com/hyperledger-indy/indy-node/blob/main/README.md)
- [Releases](https://github.com/hyperledger-indy/indy-node/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hyperledger-indy-indy-node