NVFlare is NVIDIA's SDK for running models where the data stays put

An SDK for moving a workflow, not a library for one algorithm

NVIDIA FLARE expands to NVIDIA Federated Learning Application Runtime Environment, and the documentation describes it as a domain agnostic, open source, extensible Python SDK that allows researchers and data scientists to adapt existing machine learning and deep learning workflows to a federated paradigm. The second half of the description is about the other audience, the framework enables platform developers to build a secure, privacy preserving offering for distributed multi party collaboration. So the same repository has to serve a researcher running a simulation on a laptop and a platform team shipping a service across a dozen hospitals, and the architecture is chosen for that. The stated approach is a componentised architecture, which is what allows federated learning workloads to move from research and simulation to real world production deployment without a rewrite. It is worth naming clearly what it is not, it is not a training library, and it is not a privacy technique, it is the runtime that holds the coordination together while your existing model code does the work.

Algorithms, workflows and the two kinds of federation

The application feature list is the catalogue of what you can run. On the model side, FLARE supports both deep learning and traditional machine learning algorithms, with PyTorch, TensorFlow, scikit-learn and XGBoost named as examples, and it ships built-in federated learning algorithms including FedAvg, FedProx, FedOpt, Scaffold and Ditto. On the topology side, it supports both horizontal and vertical federated learning, which is the distinction between parties holding the same features for different samples and parties holding different features for the same samples, and the vertical case is the one that usually needs the more interesting machinery. The workflow list covers several server and client controlled training patterns, scatter and gather and cyclic among them, plus validation workflows such as global model evaluation and cross-site validation, which is the federated equivalent of a test set spread across sites. And it is not only about training, since the same runtime supports data analytics through federated statistics and the machine learning lifecycle management around it.

Privacy is the reason platform teams look at it

The privacy features are listed as a single bullet and each of the three techniques is a different thing. Differential privacy bounds what a single contribution reveals, at the cost of noise in the aggregate. Homomorphic encryption lets computation happen over encrypted values, at a substantial computational cost. Private set intersection finds the overlap between two parties' records without either learning the other. Which one a project needs depends entirely on what it is trying to prevent, and the documentation does not pretend they are interchangeable. There is a second privacy layer in the deployment features, security enforcement through federated authorisation and privacy policy, which is the platform side of the same question, since a federated deployment is a set of services accepting instructions from each other and that needs a policy about who may do what. The result is a system where the privacy story has both a cryptographic half and an administrative half, and the latter is the half most federated demonstrations leave out.

The path from a local script to a multi-site deployment

The section titled from simulation to real world is really a description of the migration path. The FLARE Client API is the mechanism, a way to move an existing machine learning or deep learning workflow into a federated one with minimal code changes, which is the difference between a framework you can adopt in a week and one you cannot. For the early stage there is a Simulator and a proof of concept mode for rapid development and prototyping, so a team can test the coordination before it has a second site. For the later stage there is deployment on cloud and on premises, a dashboard for project management and deployment, and built-in support for system resiliency and fault tolerance, which matters more in federated learning than in ordinary training, since any site can be slow, offline or misbehaving and the run has to survive that. The combination of a dashboard, an authorisation model and fault tolerance is what turns a research artefact into something a platform team can offer to customers.

Two frameworks live in one repository

The tree is worth a look, because the top level names tell you what the project contains. The `nvflare/` directory is the SDK itself, and `nvflight/` sits alongside it as a separate top-level package, distinct from the coordination runtime and worth understanding before you pick one. There is an `examples/` directory with a hello world, advanced examples, devops, docker and tutorials, and a `docs/` directory, plus `integration/`, `job_templates/`, `research/`, `skills/`, `tests/`, `ci/`, `docker/` and a `web/` directory for the dashboard. The `examples/README.md` and the tutorials are the fastest route to understanding what the framework expects a job to look like. There are also papers and publications, a developer portal, DLI courses on the learning portal, and a research directory, which together suggest a project that has to serve both a documentation audience and a research one.

Packaging details, and what they tell you

The build configuration is a small but revealing document. The package is built with setuptools, wheel, PyYAML and versioneer, and the version comes out of the git metadata, with the setup script loading a local copy of versioneer directly from the source tree rather than from an installed package. If the version cannot be determined, the script raises an error unless the environment variable below is set, which is what a build pipeline outside a git checkout needs:

base_version = os.environ.get("NVFL_BASE_VERSION")

The formatting configuration is black with a line length of 120 and isort with the black profile, and the black target versions run from Python 3.10 to 3.14, which is a useful signal about the range the project supports. The pytest configuration registers three markers, `timeout` for tests with an execution limit, `slow` for tests excluded from the default run, and `xdist_group` for tests that must share a worker, which tells you the suite is parallelised and has a tier of slow tests. The repository also carries a `CITATION.cff`, a `CODEOWNERS` file, a `CLAUDE.md` and an `AGENTS.md`, and a `codecov.yml`.

Release candidates, and what to check before you rely on it

The version state is the first thing to note. The listed releases are 2.9.1rc4, 2.9.1rc3 and 2.9.1rc2, published on consecutive days in October 2026, with the notes describing bug fixes, document updates and feature improvements. Those are release candidates, not a stable release, so pinning to a final tag is the sensible move for anyone who is not actively testing the newest code. The repository was last pushed on 2026-10-19, so the work is current. The licence is Apache-2.0 with the text in the LICENSE file, which is the permissive grant most platform teams want. Beyond that, the practical checklist for an adopter is short. Install the current release with `python -m pip install nvflare` and work through the quick start, decide whether you need horizontal or vertical federation before you design the data layout, choose the privacy technique deliberately rather than taking all three, and test the failure behaviour of a site that goes offline mid-round, because that is the case a federated system has to survive and the one a local simulation will not show you.

Editorial conclusion

NVFlare suits a team with several sites holding data that cannot be pooled, since the componentised architecture means the same code can be simulated on a laptop and deployed across sites, and it suits a research group that wants to compare federated algorithms rather than implement them. It is a poor fit for a single site with all the data in one place, since the coordination overhead buys nothing there, and it is a poor fit if you need a stable release, since the current versions are release candidates. Before you build on it, check three things: which algorithm and workflow you actually need, since the built-in set covers both classical averaging and more conservative variants, whether the privacy features you need are the ones it ships, since differential privacy, homomorphic encryption and private set intersection are different costs, and the version you pin, given the 2.9.1 release candidates in October 2026 and the last push to the repository on 2026-10-19.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. NVIDIA/NVFlare on GitHub
3. Project website
4. README
5. Releases