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

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.

Editorial 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.

Official sources

1. HewlettPackard/swarm-learning on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases