Flower: A Framework for Federated AI Across Any Machine Learning Stack

Training AI When Raw Data Cannot Be Centralized

Federated learning addresses a specific constraint: organizations or devices that hold training data cannot or will not send that raw data to a central server. A hospital system cannot ship patient records to a cloud trainer. A mobile keyboard application that learns from typing cannot upload each user's input to a data center. A factory floor with sensor data subject to trade secrecy cannot pool its logs with competitors.

Flower places itself between those distributed data holders and the model aggregation step. Each participant runs local training on its own hardware using its own data, then sends only the resulting model update, a gradient or updated weight vector, back to a central Flower server. The server aggregates those updates according to a configurable strategy and distributes a new global model to all participants. The raw data never leaves the participant's system.

The project originated in a research project at the University of Oxford, which explains two aspects of its design: the emphasis on extensibility over fixed workflows, and the presence of a baselines/ directory for reproducing published experiments. A framework built in industry typically optimizes for deployment; one built in academia typically optimizes for experimental variation. Flower was designed to allow both.

Framework-Agnostic Architecture and the Backend List

The README describes Flower as 'Framework-agnostic' and lists the supported machine learning libraries explicitly: PyTorch, TensorFlow, Hugging Face Transformers, PyTorch Lightning, scikit-learn, JAX, TFLite, MONAI, fastai, MLX, XGBoost, CatBoost, LeRobot (for federated robotics), Pandas (for federated analytics), and raw NumPy.

This breadth matters because competing federated learning tools tend to be tied to one framework. TensorFlow Federated works within the TensorFlow ecosystem and can make assumptions about TF operations that Flower cannot make universally. For teams with a mixed ML stack, or for those already using XGBoost for tabular data or Hugging Face Transformers for language tasks, there is no equivalent alternative that covers the same range.

The trade-off is that Flower provides a general interface rather than a framework-specific optimized one. TensorFlow Federated can exploit TF's graph execution in ways Flower's abstraction cannot. Teams deeply committed to TensorFlow may find TFF's integration tighter; teams using any other framework have no comparable option.

Framework support varies in depth across the examples. The examples/ directory includes quickstart directories for Android (with TFLite), iOS (with CoreML), CatBoost, and C++, plus more advanced directories for flowertune-llm (fine-tuning large language models federatedly), flowertune-vit (vision transformer fine-tuning), fedrag (federated retrieval-augmented generation), and embedded-devices (suggesting use on microcontrollers and mobile chips). The presence of a federated-analytics/ example shows that Flower is not limited to model training: it can coordinate aggregation over Pandas DataFrames as well.

The flwr Package and Getting a First App Running

The Python package is named flwr. The README links directly to the installation documentation at flower.ai/docs/framework/how-to-install-flower.html. A series of quickstart guides for each supported framework is listed in the documentation section of the README, covering TensorFlow, PyTorch, Hugging Face, PyTorch Lightning, Pandas, fastai, JAX, scikit-learn, Android (TFLite), and iOS (CoreML).

A Flower application consists of two main pieces: a client implementation that wraps existing ML training code, and a server-side strategy that controls how client updates are aggregated. The tutorial series documented in the README walks through seven steps: from basic federated training, through using and customizing aggregation strategies, to communicating custom messages between clients and the server. The README also lists upcoming tutorial topics including privacy and security in federated learning and scaling.

For rapid experimentation without writing all client code from scratch, the examples/advanced-pytorch/ and examples/quickstart-catboost/ directories provide working starting points. The examples/flowertune-llm/ directory addresses federated fine-tuning for language models. The agent/, hub/, and model/ directories in the top-level repository suggest infrastructure for sharing and deploying models beyond what the README describes in detail.

Flower Baselines: Reproducible Federated Research

The baselines/ directory holds community-contributed implementations reproducing experiments from published federated learning papers. The README lists more than twenty: DASHA, DepthFL, FedBN, FedMeta, FedMLB, FedPer, FedProx, FedNova, HeteroFL, FedAvgM, FedRep, FedStar, FedWav2vec2, FjORD, MOON, niid-Bench, TAMUNA, FedVSSL, FedXGBoost (HFedXGBoost), FedPara, FedAvg (on MNIST), and FedOpt.

This is useful to researchers who need a working implementation of a specific aggregation algorithm without re-implementing the paper from pseudocode. It also provides a comparative starting point: teams that want to evaluate FedProx against FedNova on their own dataset can clone a baseline and substitute their data rather than starting from scratch.

The Flower Baselines documentation at flower.ai/docs/baselines/ categorizes the available implementations. These are community contributions, so quality and maintenance are not uniform across all entries. A baseline written for an earlier Flower API version may require updates when the core framework changes. Researchers submitting their own work as a baseline gain visibility while giving others a verified starting point.

The baselines/ directory is separate from the examples/ directory. Examples demonstrate features; baselines reproduce papers. Confusing the two leads to using a research-paper implementation in a production context where it was not intended to run.

Communication Overhead, Privacy Limits, and Debugging Complexity

Federated learning with Flower reduces privacy risk compared to sending raw data to a central trainer, but the README does not describe differential privacy guarantees. Privacy and security in federated learning are listed as upcoming tutorial topics in the README, which signals that the documentation on protecting against inference attacks on model updates is still being developed. Flower coordinates model updates; whether those updates themselves leak information about the training data is a separate problem the framework does not solve by default.

Communication overhead is a real constraint. Each training round transfers model weights or gradients over the network. For a large neural network with hundreds of millions of parameters, that transfer is substantial even for a single round. The embedded-devices examples suggest Flower has been used on bandwidth-limited hardware, but the framework does not apply gradient compression or quantization by default. Teams working with large models in a federated setting need to implement bandwidth reduction separately.

Debugging is harder than in centralized training. When a federated run produces unexpected results, determining whether the issue lies in one participant's data distribution, the aggregation strategy, the global model initialization, or a client implementation bug requires examining logs across multiple nodes. Single-machine training errors are typically easier to isolate.

Flower also provides no data loading infrastructure. Each participant's data pipeline is built independently, so federated setup does not simplify the data engineering side of the problem.

Release Cadence, Versioning, and the Apache-2.0 License

Flower releases on a roughly weekly schedule. Flower 1.38.0 was released on 2026-09-22, 1.37.0 on 2026-09-15, and 1.36.0 on 2026-09-01. The last push to the repository was on 2026-09-27. The release pace indicates sustained core development with no long gaps between versions.

The CHANGELOG.md records full history. The .pre-commit-config.yaml at the repository root indicates an organized contribution workflow with automated checks before code is merged. The .devcontainer/ directory supports development inside a container environment, which reduces setup friction for contributors on different operating systems.

The license is Apache-2.0. This permits use in commercial products, modification, and redistribution. Copyright and license notices must be preserved, and modified files must be marked as changed. There are no additional restrictions beyond the standard Apache-2.0 terms.

Upgrade cost depends on which ML framework the Flower clients use. Since Flower wraps training code rather than dictating it, major version changes in Flower itself tend to affect only the client and strategy APIs rather than the underlying training logic. The changelog should be reviewed at each upgrade for API surface changes, particularly for any alterations to the strategy interface or client communication protocol.

Editorial conclusion

Teams training models on healthcare records, financial data, or edge devices where raw data cannot leave each site should evaluate Flower before building a custom federated infrastructure. Those who only need centralized training on a single cluster will find it unnecessary overhead. Before adopting, check that your target ML framework has a Flower quickstart at flower.ai/docs, since integration depth varies by backend, and estimate the gradient communication volume that your model size will generate per training round.

Frequently asked questions

Official sources

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