# HPE Swarm Learning: Decentralized Training With an Ethereum Ledger and a License Server

> Swarm Learning is an HPE framework that keeps training data on each participant's host and shares only model weights, coordinated through a blockchain network and X.509 identities. It is a deployment-heavy system, not a pip install, and the license server requirement is the first thing to check.

**HewlettPackard/swarm-learning** — A simplified library for decentralized, privacy preserving machine learning

- Repository: https://github.com/HewlettPackard/swarm-learning
- Stars: 354 · Forks: 113
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/hewlettpackard-swarm-learning

## The problem Swarm Learning is built around

The README states the framework is for decentralized, privacy-preserving machine learning, and its premise is that training should happen at the edge, where data is most recent. The constraint it addresses is a data-sharing one: participants want a shared model but cannot move raw records to a central store. The README says only the insights learned are shared with collaborating peers, not the raw data, and adds the qualifier that only metadata is written to the blockchain. The model itself is not stored there. That distinction matters for anyone evaluating the privacy claim, because the ledger is a coordination record, not a model store. The intended user is an organization with data already distributed across sites (hospitals, branches, factory floors) and a Python training script it is willing to modify. It is not aimed at a single team training on one dataset in one cluster.

## Nodes are functional roles, not machines

The architecture section is explicit that nodes represent different Swarm Learning functionality and not physical server nodes, and each runs in a separate container. SL nodes run the core: they act as the interface between the user model application (the ML node) and the rest of the framework, and they distribute and merge model weights. SN nodes form the blockchain network, which the README says uses an open-source version of Ethereum; they track progress and coordinate the other components, and the blockchain can be persisted across an SN restart so past progress survives. One SN node is the Sentinel node, the first to start, responsible for initializing the blockchain. SWCI is the command interface for monitoring and management, and can connect to any SN node. SWOP is an agent that executes one task at a time, such as starting and stopping runs or building and upgrading ML containers. SLM-UI is a GUI for installing the framework, deploying a training run, and monitoring progress. The pairing rule is the operational detail that shapes deployment: each ML node has a corresponding SL node, and each pair must run on the same host.

## Swarm-enabling a model through SwarmCallback

The README says a Keras, PyTorch or HuggingFace Trainer program written in Python 3 can be converted by making a few simple changes to the training code and including the SwarmCallback API. The repository points to docs/User/How_to_Swarm_enable_an_ML_algorithm.md for the procedure and to the examples directory for working code. Two things are worth noting before you plan around that sentence. First, the README does not reproduce the API surface, so the actual callback signature and the expected merge behaviour have to be read from the linked document and the examples. Second, the conversion is not free: the callback sits in the training loop, which means the loop has to be structured so the callback can run at the right points. The transformed program can be built as a Docker container or run on the host, though HPE recommends the container route for easier and automatic deployment. Since SWOP builds and upgrades ML containers as one of its tasks, the container path is the one the surrounding tooling assumes.

## Certificates, ports and the license server gate

Three prerequisites decide whether a Swarm Learning deployment starts at all. Security and digital identity are handled by X.509 certificates, used for communication among components; you can generate your own or use certificates from standard security software such as SPIRE. The README states plainly that the framework does not initialize if certificates are not provided. Components communicate over a set of TCP/IP ports documented in docs/Install/Exposed_port_numbers.md, and the README adds that participating nodes must be able to access each other's ports, which is a firewall and network-topology question you have to answer before the first run. The third gate is licensing: a License Server installs and manages the license required to run the framework, and licenses are managed by the AutoPass License Server (APLS) container, with an APLS user guide linked from the repository. That is an operational dependency outside the Python code, and it is the item most likely to surprise a team that skimmed the description and expected an open-source-only stack.

## Where the design will fight you

The ML and SL node colocation rule is a real constraint. Every participating site has to run both containers on the same host, so the deployment unit is a host pair, not a process. SWOP executes only one task at a time, which the README states directly, so parallel orchestration through a single SWOP agent is not what the design offers. The certificate requirement is a hard failure mode rather than a warning: no certificates, no framework initialization. Network reachability is the second hard failure mode, since components must reach each other's ports. And the license server is a third: the framework needs a license to run, managed through the APLS container. If your environment cannot run that container, or cannot issue X.509 certificates, Swarm Learning is the wrong tool regardless of how well the training code fits. The blockchain is also not a general-purpose audit store for model artefacts, because only metadata is written to it.

## How this differs from federated learning frameworks

The comparison that matters is with federated learning stacks such as Flower or NVIDIA FLARE. Those typically assume a central aggregation server that receives client updates and returns a global model, with the server as the coordination point. Swarm Learning removes that central role and puts coordination on a blockchain network of SN nodes, with a Sentinel node initializing the ledger and SWCI able to query it through get or list. The trade-off is direct: you gain a decentralized coordination record that survives an SN restart, and you take on running an Ethereum-based network, issuing certificates, opening a documented port set, and operating a license server. A federated learning deployment usually needs one reachable aggregation endpoint and a client library. A Swarm Learning deployment needs a container per node role per host, plus the APLS container. If your participants all trust a single coordinator and can reach it, the simpler aggregation model is the better fit; the blockchain layer buys you coordination without that central server, and you pay for it in operational surface.

## Versions and what to check before upgrading

The repository lists v2.3.0 (Swarm Community release 2.3.0) from December 2025, v2.2.0 from February 2024, and v2.1.0 from October 2023. The gap between 2.2.0 and 2.3.0 is roughly twenty-two months, while 2.1.0 to 2.2.0 was about four months, so the release cadence has slowed rather than accelerated. The README does not include an upgrade or migration guide, and it does not state whether SL, SN, SWCI, SWOP and SLM-UI nodes must all run the same version. That is the first thing to confirm with the maintainers before a rolling upgrade, because a mixed-version swarm is exactly the scenario the documentation does not address. The project is Apache-2.0 licensed, which permits commercial use and modification under that licence's terms, but the licence covers the source, not the runtime: the README separately requires a license managed by the APLS container to run the framework. Treat the Apache-2.0 grant and the runtime licensing as two distinct questions, and read the APLS user guide for the second one.

## Conclusion

Adopt Swarm Learning if your training data cannot leave its host and you can run Docker containers plus an AutoPass License Server instance and issue X.509 certificates to every participating node. Do not adopt it for a single-site training job, or if you cannot open TCP ports between all participants, because the README states the framework does not initialize without certificates and that nodes must reach each other's ports. Before committing, verify three things against your own environment: the port list in docs/Install/Exposed_port_numbers.md, how the APLS container will be licensed for your node count, and whether your model code can be expressed through the SwarmCallback API in a Keras, PyTorch or HuggingFace Trainer program.

## FAQ

### What is Swarm Learning in the HewlettPackard/swarm-learning project?

A decentralized, privacy-preserving machine learning framework that trains models at the edge, close to where the data lives, and shares only what each node learned rather than the raw data. Coordination runs through an Ethereum-based blockchain that stores metadata only, never the model itself, and every component runs in its own container.

### What does a user have to change in their model to run it under Swarm Learning?

A Keras, PyTorch or HuggingFace Trainer based Python program needs a few small changes to its training code, one of which is including the SwarmCallback API. All ML nodes in one run must use the same platform, so mixing Keras and PyTorch across nodes is not supported.

### What has to be in place before Swarm Learning will start?

X.509 certificates for the components, since the framework does not initialize without them, and the TCP/IP ports that participating nodes must reach on each other, listed in docs/Install/Exposed_port_numbers.md. A licence is also required and is managed by the AutoPass License Server container.

### Is HewlettPackard/swarm-learning something you install with pip?

There is no Python packaging manifest at the root. The top level holds docs/, examples/, lib/, scripts/ and .github/, and the architecture states that each node runs in a separate container, so a deployment is assembled from container images rather than installed from a package index.

## Sources

- [HewlettPackard/swarm-learning on GitHub](https://github.com/HewlettPackard/swarm-learning)
- [Issues](https://github.com/HewlettPackard/swarm-learning/issues)
- [License: Apache-2.0](https://github.com/HewlettPackard/swarm-learning/blob/master/LICENSE)
- [README](https://github.com/HewlettPackard/swarm-learning/blob/master/README.md)
- [Releases](https://github.com/HewlettPackard/swarm-learning/releases)

---

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