Changelog

Unreleased

v1.22.0 (2025-09-21)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Dimitris Stripelis, Heng Pan, Javier, Mohammad Naseri, Patrick Foley, William Lindskog, Yan Gao

What’s new?

  • Migrate all strategies to Message API (#5845, #5850, #5851, #5867, #5884, #5894, #5904, #5905, #5908, #5913, #5914, #5915, #5917, #5919, #5920, #5931)

    Migrates and implements all federated learning strategies to support the new Message API. Strategies updated or introduced include FedAvg, FedOpt and its variants (FedAdam, FedYogi, FedAdagrad), FedProx, Krum, MultiKrum, FedAvgM, FedMedian, FedTrimmedAvg, QFedAvg, and Bulyan. Differential privacy strategies were also migrated, including both fixed and adaptive clipping mechanisms on the server and client sides.

  • Migrate flwr new templates to Message API (#5901, #5818, #5893, #5849, #5883)

    All flwr new templates have been updated to use the Message API. The PyTorch template based on the legacy API is retained and explicitly marked as legacy for those who prefer or require the older approach. A new template for XGBoost is introduced.

  • Revamp main tutorials to use the Message API (#5861)

    The primary tutorial series has been updated to showcase the Message API. The revamped content improves alignment with recent architectural changes and enhances learning clarity. See the updated tutorial: Get started with Flower.

  • Upgrade tutorials and how-to guides to the Message API (#5862, #5877, #5891, #5895, #5896, #5897, #5898, #5906, #5912, #5916, #5921, #5922, #5923, #5924, #5927, #5928, #5925)

    All framework tutorials and how-to guides have been fully migrated to the Message API. This includes quickstarts for JAX, TensorFlow, PyTorch Lightning, MLX, FastAI, Hugging Face Transformers, and XGBoost, along with comprehensive updates to guides covering strategy design, differential privacy, checkpointing, client configuration, evaluation aggregation, and stateful client implementation. These changes ensure all learning resources are up-to-date, aligned with the current architecture, and ready for developers building on the Message API.

  • Migrate and update examples to support the Message API (#5827, #5830, #5833, #5834, #5839, #5840, #5841, #5860, #5868, #5869, #5875, #5876, #5879, #5880, #5882, #5887, #5888, #5889, #5892, #5907, #5911, #5930)

    Migrates a wide range of examples to the new Message API, ensuring consistency with recent framework updates. Examples updated include quickstarts (e.g., TensorFlow, PyTorch Lightning, Hugging Face, MONAI, FastAI, MLX), advanced use cases (e.g., FlowerTune for ViT and LLMs, FedRAG, FL-VAE), and specialized scenarios (e.g., XGBoost, tabular data, embedded devices, authentication, and custom mods). Enhancements also include updated variable naming, model-saving logic, readme improvements, and import path corrections for better usability and alignment with the new API.

  • Introduce experimental flwr pull command (#5863)

    The flwr pull Flower CLI command is the foundation for future functionality allowing for the retrieval of artifacts generated by a ServerApp in a remote SuperLink.

  • Improve CI/CD workflows (#5810, #5842, #5843, #5854, #5856, #5857, #5858, #5859, #5865, #5874, #5900, #5815)

  • General improvements (#5844, #5847, #5870, #5872, #5873, #5881, #5886, #5890, #5902, #5903, #5909, #5910, #5918)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

v1.21.0 (2025-09-10)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Dimitris Stripelis, Evram, Heng Pan, Javier, Robert Steiner, Yan Gao

What’s new?

  • Introduce Message API strategies (#5710, #5766, #5770, #5771, #5774, #5779, #5787, #5794, #5798, #5804, #5807, #5813, #5824, #5831, #5838)

    Introduces a new abstract base class Strategy that operate on Message replies, mirroring the design of those operating on FitIns/FitRes or EvaluateIns/EvaluteRes while providing more versatility on the type of payloads that can be federated with Flower. The first batch of Message-based strategies are: FedAvg, FedOpt, FedAdam, FedAdagrad, FedYogi, and fixed-clipping Differential Privacy strategies. More will follow in subsequent releases. A migration guide has been added to help users transition their existing Flower Apps operating on the original Strategy and NumPyClient abstractions to the Message API.

  • Introduce Flower SuperExec (#5659, #5674, #5678, #5680, #5682, #5683, #5685, #5696, #5699, #5700, #5701, #5702, #5703, #5706, #5713, #5726, #5731, #5734, #5735, #5737, #5751, #5759, #5811, #5828)

    SuperExec is a new component responsible for scheduling, launching, and managing app processes (e.g., ServerApp, ClientApp) within the Flower deployment runtime. It is automatically spawned when running a SuperLink or SuperNode in subprocess mode (default). This also introduces a token-based mechanism that improves security by assigning a unique token to each app execution. Supporting changes include new RPCs, protocol updates, plugin abstractions, and Docker image support for SuperExec. For more details, refer to the updated Flower architecture explainer. Documentation has been revised to reflect the introduction of Flower SuperExec, including guides and tutorials such as quickstart with Docker, GCP deployment, and network communication to consistently use SuperExec.

  • Update quickstart-pytorch to use Message API (#5785, #5786, #5802)

    The quickstart-pytorch tutorial has been migrated to the Message API, using the new FedAvg strategy and the new flwr new template.

  • New PyTorch template with Message API (#5784)

    A new PyTorch template using the Message API is now available through flwr new.

  • Add OpenShift deployment guide for Flower (#5781)

    Introduces a guide for deploying Flower on Red Hat OpenShift, including setup steps and configuration examples.

  • Improve Helm documentation (#5711, #5733, #5748, #5758, #5765, #5816)

    Helm guide has been enhanced with additional configuration details and updated formatting. Changes include adding a parameters section, documenting how to set a custom secretKey, updating TLS instructions for version 1.20, introducing audit logging configuration, and using SuperExec.

  • Improve documentation (#5159, #5655, #5668, #5692, #5723, #5738, #5739, #5740, #5753, #5764, #5769, #5775, #5782, #5788, #5795, #5809, #5812, #5817, #5819, #5825, #5836)

    Restructures the tutorial series, removes flower-simulation references, and updates versioned docs to use the correct flwr versions. The framework documentation homepage now defaults to the latest stable release instead of the main branch.

  • Re-export user-facing API from flwr.*app (#5814, #5821, #5832, #5835)

    The following classes are now re-exported:

    • From flwr.serverapp: ServerApp, Grid

    • From flwr.clientapp: ClientApp, arrays_size_mod, message_size_mod

    • From flwr.app: Array, ArrayRecord, ConfigRecord, Context, Message, MetricRecord, RecordDict

    Importing these from flwr.server, flwr.client, or flwr.common is deprecated. Please update your imports to use flwr.serverapp, flwr.clientapp, or flwr.app instead to ensure forward compatibility.

  • Add --health-server-address flag to Flower SuperLink/SuperNode/SuperExec (#5792)

  • Update CI/CD workflows and dependencies (#5647, #5650, #5651, #5656, #5712, #5714, #5747, #5754, #5755, #5796, #5806, #5808, #5829)

  • General improvements (#5622, #5660, #5673, #5675, #5676, #5686, #5697, #5708, #5719, #5720, #5722, #5736, #5746, #5750, #5757, #5776, #5777, #5789, #5805, #5797, #5820)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Incompatible changes

  • Rename Exec API to Control API (#5663, #5665, #5667, #5671)

    The Exec API has been fully renamed to Control API to make its purpose clearer and avoid confusion with SuperExec. This includes renaming exec.proto to control.proto, updating documentation, and changing the --exec-api-address flag to --control-api-address. For backward compatibility, the old flag is still supported.

  • Deprecate flwr-* commands (#5707, #5725, #5727, #5760)

    The long-running commands flwr-serverapp, flwr-clientapp, and flwr-simulation are deprecated in favor of SuperExec. Invoking them now launches the corresponding SuperExec process for backward compatibility.

  • Remove --executor* flags (#5657, #5745, #5749)

    The --executor, --executor-dir, and --executor-config flags have been deprecated and the executor code removed. Use the new --simulation flag to run SuperLink with the simulation runtime.

v1.20.0 (2025-07-29)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Dimitris Stripelis, Heng Pan, Javier, Kumbham Ajay Goud, Robert Steiner, William Lindskog, Yan Gao

What’s new?

  • Send/receive arbitrarily large models (#5552, #5550, #5600, #5611, #5614, #5551)

    Flower 1.20 can send and receive arbitrarily large models like LLMs, way beyond the 2GB limit imposed by gRPC. It does so by chunking messages sent and received. The best part? This happens automatically without the user having to do anything.

  • Implement object-based messaging between SuperNode and ClientApp (#5540, #5577, #5581, #5582, #5583, #5584, #5585, #5586, #5587, #5589, #5590, #5592, #5595, #5597, #5598, #5599, #5602, #5604, #5605, #5606, #5607, #5609, #5613, #5616, #5624, #5645)

    Redesigns the messaging system to enable object-based communication between the SuperNode and ClientApp, replacing the previous message-coupled design. Introduces new RPCs and enhances the ClientAppIo and Fleet APIs to faciliate better object storage in SuperNode and decouple ObjectStore from Message, improving maintainability and extensibility. Several refactorings improve modularity, naming consistency, and model weight streaming.

  • Refactor SuperNode to use NodeState exclusively (#5535, #5536, #5537, #5541, #5542, #5610, #5628)

    Refactors SuperNode to rely solely on NodeState for managing all information, decoupling internal components for improved maintainability and clearer state handling. RPCs of the ClientAppIo API have been refactored accordingly, laying the groundwork for future concurrent ClientApps support.

  • Enforce maximum size limit for FAB files (#5493)

    Limits the size of FAB files to a maximum of 10MB to prevent oversized artifacts. Developers can reduce FAB size by excluding unnecessary files via the .gitignore file in the Flower app directory.

  • Add CatBoost federated learning quickstart example (#5564)

    This example shows how to use CatBoost with Flower for federated binary classification on the Adult Census Income dataset. It applies a tree-based bagging aggregation method. View the example for more details.

  • Fix Windows path issue in FAB builds (#5608)

    Updates the way FAB files represent relative paths to their internal files to ensure consistency across different operating systems. This fixes an issue where a FAB built on Windows would fail integrity checks when run on UNIX-based systems (e.g., Ubuntu).

  • Add explainer for pyproject.toml configuration (#5636)

    Adds a guide explaining how to configure a Flower app using its pyproject.toml file. The documentation is available here.

  • Improve flwr new templates with TOML comments and README links (#5635)

    Adds comments to the generated pyproject.toml and a new section in the README.md, both linking to the TOML explainer.

  • Warn when running Ray backend on Windows and update simulation guide (#5579)

    Logs a warning when using the Ray backend for simulation on Windows. Updates the simulation guide to include a corresponding note about limited Windows support.

  • Add Helm deployment guide (#5637)

    The documentation now includes a comprehensive guide for deploying Flower SuperLink and SuperNode using Helm charts. For full instructions, refer to the Helm Guide.

  • Add docs for user authentication and audit logging (#5630, #5643, #5649)

    Introduces documentation for configuring user authentication (User Authentication Guide) and audit logging (Audit Logging Guide) in Flower.

  • Support gRPC health check by default (#5591)

  • Bugfixes (#5567, #5545, #5534)

  • Improve CI/CD (#5560, #5544, #5531, #5532, #5547, #5578)

  • Improve and update documentation (#5558, #5603, #5538, #5626, #5566, #5553, #5588, #5549, #5618, #5612, #5646)

  • General improvements (#5543, #5594, #5623, #5615, #5629, #5571, #5617, #5563, #5620, #5619, #5546, #5601, #5641, #5555, #5533, #5548, #5557, #5565, #5554, #5621, #5644, #5576, #5648)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Incompatible changes

  • Remove non-grpc-bidi transport support from deprecated start_client (#5593)

    Drops support for non-grpc-bidi transport in the deprecated start_client API. Pleaes use flower-supernode instead.

v1.19.0 (2025-06-17)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Tupper, Andrej Jovanović, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Dimitris Stripelis, Haoran Jie, Heng Pan, Javier, Kevin Ta, Mohammad Naseri, Ragnar, Robert Steiner, William Lindskog, ashley09, dennis-grinwald, sukrucildirr

What’s new?

  • Revamp messaging system with content-addressable object model (#5513, #5477, #5424, #5379, #5353, #5372, #5507, #5364, #5517, #5514, #5342, #5393, #5508, #5504, #5335, #5341, #5430, #5308, #5487, #5509, #5438, #5369, #5354, #5486, #5380, #5496, #5399, #5489, #5446, #5432, #5456, #5442, #5462, #5429, #5497, #5435, #5371, #5450, #5384, #5488, #5434, #5425, #5475, #5458, #5494, #5449, #5492, #5426, #5445, #5467, #5474, #5527)

    Introduces a content-addressable messaging system that breaks messages into a tree of uniquely identified, SHA256-hashed objects. This model allows objects to be pushed and pulled efficiently, avoiding redundant uploads and enabling scalable message streaming and broadcasting. Core enhancements include the new InflatableObject abstraction and ObjectStore for storing and retrieving message content, with Array, Message, and *Record classes now inherit from InflatableObject. New utilities and RPCs facilitate recursive object handling, ID recomputation avoidance, and safe deletion. The framework’s servicers, REST, and gRPC layers were refactored to integrate this system, improving real-world deployment scalability and communication efficiency.

  • Improve user authorization and access control (#5428, #5505, #5506, #5422, #5510, #5421, #5420, #5448, #5447, #5503, #5501, #5502, #5511)

    Improves user authorization feature that integrates with the existing authentication protocol. When authentication is enabled, commands like flwr ls, flwr log, and flwr stop are restricted to displaying or affecting only the runs submitted by the authenticated user. This is enforced using the Flower Account ID. Additionally, fine-grained access control can be enforced for CLI operations based on assigned roles (RBAC).

  • Add Floco baseline for personalized federated learning (#4941)

    Introduces Floco, a method that enhances both personalized and global model performance in non-IID cross-silo federated learning. It trains a shared solution simplex across clients, promoting collaboration among similar clients and reducing interference from dissimilar ones. Learn more in Floco Baseline Documentation.

  • Add FEMNIST support to FedProx baseline (#5290)

    Adds FEMNIST dataset to FedProx with preprocessing matching the original paper—subsampling ‘a’-‘j’ and assigning 5 classes per device. More details: FedProx Baseline Documentation

  • Upgrade StatAvg baseline to new Flower App format (#4952)

    The StatAvg baseline is updated to use the new Flower App format. Changes include removing Hydra, switching to pyproject.toml configs, using ClientApp and ServerApp, and saving results via a custom Server class. More details: StatAvg Baseline Documentation.

  • Add guide for running Flower on Google Cloud Platform (#5327)

    The documentation now includes a detailed guide on deploying and running Flower on Google Cloud Platform (GCP). It provides step-by-step instructions for managing Flower workloads in a GCP environment. For more information, refer to the official guide.

  • Implement ServerApp heartbeat monitoring (#5228, #5370, #5358, #5332, #5322, #5324, #5230, #5325)

    Adds heartbeat support to ServerApp processes, enabling the SuperLink to detect crashed or terminated processes and mark them as finished:failed when no final status is received.

  • Extend NodeState to improve SuperNode state management (#5470, #5473, #5402, #5521)

    Extends the NodeState interface and implementation to manage all SuperNode state.

  • Refactor SuperNode for improved robustness and maintainability (#5398, #5397, #5443, #5410, #5411, #5469, #5419)

    Ongoing refactoring of SuperNode improves modularity, simplifies client execution, removes gRPC bidirectional streaming and unused code, and centralizes connection logic. These changes align SuperNode’s behavior more closely with SuperLink to make Flower the best platform for robust enterprise deployments..

  • Restructure Flower (#5465, #5476, #5460, #5409, #5408, #5396, #5389, #5392, #5461)

    Reorganizes infrastructure code into dedicated submodules to improve maintainability and clarify the separation from user-facing components.

  • Improve CI/CD workflows (#5498, #5265, #5266, #5328, #5500, #5346, #5318, #5256, #5298, #5257, #5483, #5440, #5304, #5313, #5381, #5385, #5316, #5260, #5349, #5319, #5296, #5294, #5317, #5482, #5282, #5223, #5225, #5326)

    Refines CI workflows, templates, and automation; improves Docker, dependency, and version management; removes legacy jobs and adds proactive maintainer tools.

  • Improve documentation and examples (#5345, #5400, #5406, #5401, #5283, #5416, #5337, #5436, #5373, #5471, #5395, #5279, #5288, #5457, #5305, #5365, #5491, #5463, #5367, #5360, #5374, #5361, #5063)

    Adds documentation for the Flower Components Network Interface and Communication Model, updates the Deployment Engine page, and clarifies the distinctions between simulation and deployment. The custom-mods example has also been revised.

  • Build FAB in memory with new utility function (#5334)

  • Add logging for incoming and outgoing messages in size modifiers (#5437)

  • Bugfixes (#5340, #5366, #5478)

  • General improvements (#5516, #5499, #4927, #5310, #5343, #5359, #5413, #5299, #5433, #5390, #5427, #5350, #5394, #5295, #5315, #5468, #5412, #5348, #5444, #5522)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

v1.18.0 (2025-04-23)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Alan Silva, Andrej Jovanović, Charles Beauville, Chong Shen Ng, Chunhui XU, Daniel J. Beutel, Daniel Nata Nugraha, Dimitris Stripelis, Guanheng Liu, Gustavo Bertoli, Heng Pan, Javier, Khoa Nguyen, Mohammad Naseri, Pinji Chen, Robert Steiner, Stephane Moroso, Taner Topal, William Lindskog, Yan Gao

What’s new?

  • Add support for Python 3.12 (#5238)

    Python 3.12 is officially supported (Python 3.12 was in preview support since Flower 1.6). Python 3.13 support continues to be in preview until all dependencies officially support Python 3.13.

  • Enable TLS connection for flwr CLI using CA certificates (#5227, #5237, #5253, #5254)

    flwr CLI now supports secure TLS connections to SuperLink instances with valid CA certificates. If no root certificates are provided, the CLI automatically uses the default CA certificates bundled with gRPC.

  • Add --version and -V flags to display flwr version (#5236)

    Users can run flwr --version or flwr -V to print the current Flower version. The update also adds -h as a shorthand for CLI help.

  • Use Hugging Face flwrlabs datasets in FlowerTune templates (#5205)

    FlowerTune templates switch to use datasets hosted under the flwrlabs organization on Hugging Face.

  • Upgrade FedBN baseline to support flwr CLI (#5115)

    Refactors the FedBN baseline to use the new Flower CLI, removes Hydra, migrates configs, enables result saving, adds run instructions, and ensures stateful clients.

  • Fix bug in Shamir’s secret sharing utilities affecting Secure Aggregation (#5252)

    Refactors Shamir’s secret sharing utilities to fix a bug impacting Secure Aggregation. Thanks to Pinji Chen and Guanheng Liu for their contributions.

  • Ensure backward compatibility for RecordDict (#5239, #5270)

    The RecordDict (formerly RecordSet) now maintains full backward compatibility. Legacy usages of RecordSet and its properties are supported, with deprecation warnings logged when outdated references are used. Users are encouraged to transition to the updated RecordDict interface promptly to avoid future issues.

  • Refactor and optimize CI/CD for repository restructuring (#5202, #5176, #5200, #5203, #5210, #5166, #5214, #5212, #5209, #5199, #5204, #5201, #5191, #5167, #5248, #5268, #5251)

    Improves CI/CD workflows to align with repository changes. Updates issue templates, fixes Docker and docs jobs, enhances script compatibility, adds checks, and bumps tool versions to streamline development and deployment.

  • Improve and clean up documentation (#5233, #5179, #5216, #5211, #5217, #5198, #5168, #5215, #5169, #5171, #5240, #5259)

    Removes outdated content, redundant CLI flags, and unnecessary sections; updates Docker READMEs and virtual environment setup guide; and syncs translation source texts.

  • General Improvements (#5241, #5180, #5226, #5173, #5219, #5208, #5158, #5255, #5264, #5272)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Incompatible changes

  • Restructure repository (breaking change for contributors only) (#5206, #5194, #5192, #5185, #5184, #5177, #5183, #5207, #5267, #5274)

    Restructures the Flower repository by moving all framework-related code, configs, and dev tools into the framework/ subdirectory. This includes relocating all files under src/, dev scripts, pyproject.toml and other configs. Contributor documentation has been updated to reflect these changes.

    Switching to the new structure is straightforward and should require only minimal adjustments for most contributors, though this is a breaking change—refer to the contributor guide for updated instructions.

v1.17.0 (2025-03-24)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Aline Almeida, Charles Beauville, Chong Shen Ng, Daniel Hinjos García, Daniel J. Beutel, Daniel Nata Nugraha, Dimitris Stripelis, Heng Pan, Javier, Robert Steiner, Yan Gao

What’s new?

  • Allow registration of functions for custom message types (#5093)

    Enables support for custom message types in ServerApp by allowing the message_type field to be set as "<action_type>.<action_name>", where <action_type> is one of train, evaluate, or query, and <action_name> is a valid Python identifier. Developers can now register handler functions for these custom message types using the decorator @app.<action_type>("<action_name>"). For example, the my_echo_fn function is called when the ServerApp sends a message with message_type set to "query.echo", and the get_mean_value function is called when it’s "query.mean":

    app = ClientApp()

@app.query("echo")
def my_echo_fn(message: Message, context: Context):
    # Echo the incoming message
    return Message(message.content, reply_to=message)

@app.query("mean")
def get_mean_value(message: Message, context: Context):
    # Calculate the mean value
    mean = ...  # Replace with actual computation

    # Wrap the result in a MetricRecord, then in a RecordDict
    metrics = MetricRecord({"mean": mean})
    content = RecordDict({"metrics": metrics})

    return Message(content, reply_to=message)

  • Rename core Message API components for clarity and consistency (#5140, #5133, #5139, #5129, #5150, #5151, #5146, #5152)

    To improve clarity and ensure consistency across the Message API, the following renamings have been made:

    • Driver → Grid

    • RecordSet → RecordDict

    • ParametersRecord → ArrayRecord

    • MetricsRecord → MetricRecord

    • ConfigsRecord → ConfigRecord

    Backward compatibility is maintained for all the above changes, and deprecation notices have been introduced to support a smooth transition.

  • Enable seamless conversions between ArrayRecord/Array and NumPy/PyTorch types (#4922, #4920)

    One-liner conversions are now supported between Array and numpy.ndarray or torch.Tensor, and between ArrayRecord (formerly ParametersRecord) and PyTorch state_dict or a list of numpy.ndarray. This simplifies workflows involving model parameters and tensor data structures. Example usage includes ArrayRecord(model.state_dict()) and array_record.to_torch_state_dict(). Refer to the ArrayRecord and Array documentation for details.

  • Revamp message creation using Message constructor (#5137, #5153)

    Revamps the Message creation workflow by enabling direct instantiation via the Message(...) constructor. This deprecates the previous APIs and simplifies message creation:

    • Driver.create_message(...) → Message(...)

    • <some_message>.create_reply(...) → Message(..., reply_to=<some_message>)

  • Stabilize low-level Message API (#5120)

    With all the changes above, the stability of the low-level Message API has been significantly improved. All preview feature warnings have been removed, marking the completion of its transition out of experimental status.

  • Add node availability check to reduce wait time (#4968)

    Adds a node availability check to SuperLink. If the target SuperNode is offline, SuperLink automatically generates an error reply message when the ServerApp attempts to pull the reply. This mechanism helps avoid unnecessary delays in each round caused by waiting for responses from unavailable nodes.

  • Enable extensible event logging for FleetServicer and ExecServicer (#4998, #4997, #4951, #4950, #5108)

    Introduces the necessary hooks and infrastructure to support RPC event logging for FleetServicer and ExecServicer. This enables advanced auditing and observability of RPC calls made by flwr CLI users and SuperNodes, when appropriate event log plugins are available.

  • Add CareQA benchmark for medical LLM evaluation (#4966)

    Adds the CareQA dataset as a new benchmark for evaluating medical knowledge in LLMs. CareQA consists of 5,621 QA pairs from official Spanish healthcare exams (2020–2024), translated to English and covering multiple disciplines. This enhances the diversity of datasets used in the Flower Medical LLM Leaderboard.

  • Fix docstrings and improve handling of Ray nodes without CPU resources (#5155, #5076, #5132)

    Fixes inaccurate or outdated docstrings in RecordDict and the FlowerClient used in FlowerTune templates, improving documentation clarity. Also adds handling for Ray nodes that report zero CPU resources, preventing potential runtime issues.

  • Improve documentation and examples (#5162, #5079, #5123, #5066, #5143, #5118, #5148, #5134, #5080, #5160, #5069, #5032)

  • Update CI/CD (#5125, #5062, #5056, #5048, #5065, #5061, #5057, #5064, #5144)

  • General Improvements (#5074, #5126, #5122, #5149, #5157)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

v1.16.0 (2025-03-11)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Alan Silva, Andrej Jovanović, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Dimitris Stripelis, Heng Pan, Javier, Kevin Ta, Li Shaoyu, Mohammad Naseri, Taner Topal, Yan Gao

What’s new?

  • Enhance RecordSet and Array for improved usability (#4963, #4980, #4918)

    RecordSet now supports dictionary-like access, allowing interactions similar to built-in Python dictionaries. For example, instead of recordset.parameters_records["model"], users can simply use recordset["model"]. This enhancement maintains backward compatibility with existing recordset.*_records properties.

    Additionally, the Array class now accepts numpy.ndarray instances directly in its constructor, enabling instantiation with a NumPy array via Array(your_numpy_ndarray).

  • Support function-specific Flower Mods for ClientApp (#4954, #4962)

    Flower Mods can now be applied to individual functions within the ClientApp rather than affecting the entire application. This allows for more granular control. The documentation has been updated to reflect these changes — please refer to How to Use Built-in Mods for details.

  • Introduce @app.lifespan() for lifecycle management (#4929, #4986)

    ServerApp and ClientApp now support @app.lifespan(), enabling custom enter/exit handlers for resource setup and cleanup. Throughout the entire FL training, these handlers in ClientApp may run multiple times as instances are dynamically managed.

  • Add FedRAG example (#4955, #5036, #5042)

    Adds a FedRAG example, integrating Federated Learning with Retrieval Augmented Generation (RAG). This approach allows Large Language Models (LLMs) to query distributed data silos without centrally aggregating the corpora, enhancing performance while preserving data privacy.

  • Upgrade FedProx baseline to a Flower App (#4937)

    Updates FedProx to the a Flower App by removing Hydra, migrating configs to pyproject.toml, using ClientApp and ServerApp, integrating flwr-datasets with DistributionPartitioner, enabling result saving, and updating README.md. This baseline now supports flwr run.

  • Migrate framework to Message-based system (#4959, #4993, #4979, #4999)

    The Flower framework has been fully migrated from a TaskIns/TaskRes-based system to a Message-based system, aligning with the user-facing Message class. This includes adding validator functions for Message, introducing LinkState methods that operate on Message, updating LinkState to use Message-only methods, and removing the Task-related code entirely.

  • Introduce event logging extension points (#4948, #5013)

    Begins implementing an event logging system for SuperLink, allowing RPC calls to be logged when enabled. These changes introduce initial extension points.

  • Increase default TTL and message size (#5011, #5028)

    The default TTL for messages is now 12 hours (up from 1 hour), and the gRPC message size limit has increased from 512MB to 2GB. TTL sets a hard limit on the time between the ServerApp sending an instruction and receiving a reply from the ClientApp.

  • Improve documentation (#4945, #4965, #4994, #4964, #4991, #5014, #4970, #4990, #4978, #4944, #5022, #5007, #4988, #5053)

  • Update CI/CD (#4943, #4942, #4953, #4985, #4984, #5025, #4987, #4912, #5049)

  • Bugfixes (#4969, #4974, #5017, #4995, #4971, #5037, #5038)

  • General Improvements (#4947, #4972, #4992, #5020, #5018, #4989, #4957, #5000, #5012, #5001)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Incompatible changes

  • Remove deprecated CLI commands (#4855)

    Removes deprecated CLI commands: flower-server-app, flower-superexec, and flower-client-app. These commands are no longer available in the framework.

  • Bump minimum Python and cryptography versions (#4946)

    Bumps the minimum Python version from 3.9 to 3.9.2 and updates the cryptography package from 43.0.1 to 44.0.1. This change ensures compatibility with the latest security updates and features.

v1.15.2 (2025-02-17)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Charles Beauville, Heng Pan, Javier, Leandro Collier, Stephane Moroso, Yan Gao

What’s new?

Free processed messages in LinkState (#4934)

When the ServerApp pulls the replies the SuperNodes sent to the SuperLink, these should be removed from the LinkState. In some situations, these weren’t erased, which could lead to high memory utilization by the SuperLink.

Introduce Windows CI tests (#4908)

We continue improving the experience of running Flower on Windows. Now, an automated CI test is run to ensure compatibility.

Update Ray version (Simulation Engine) (#4926)

The Simulation Engine has been upgraded to a version of Ray that is compatible with Python 3.12.

v1.15.1 (2025-02-05)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Dimitris Stripelis, Heng Pan, Javier, Taner Topal, Yan Gao

What’s new?

  • Improve time drift compensation in automatic SuperNode authentication (#4899)

    In addition to allowing for a time delay (positive time difference), SuperLink now also accounts for time drift, which might result in negative time differences between timestamps in SuperLink and SuperNode during authentication.

  • Rename constants for gRPC metadata (#4902)

    All metadata keys in gRPC messages that previously used underscores (_) have been replaced with hyphens (-). Using underscores is not recommended in setups where SuperLink may be deployed behind load balancers or reverse proxies.

  • Filtering out non-Fleet API requests at the FleetServicer (#4900)

    The Fleet API endpoint will now reject gRPC requests that are not part of its API.

  • Fix exit handlers mechanism for Windows (#4907)

    The SIGQUIT Python signal is not supported on Windows. This signal is now excluded when Flower is executed on Windows.

  • Updated Examples (#4895, #4158, #4879)

    Examples have been updated to the latest version of Flower. Some examples have also had their dependencies upgraded. The Federated Finetuning of a Whisper model example has been updated to use the new Flower execution method: flwr run.

  • Update FlowerTuneLLM Leaderboard evaluation scripts (#4910)

    We have updated the package versions used in the evaluation scripts. There is still time to participate in the Flower LLM Leaderboard!

  • Update Documentation (#4897, #4896, #4898, #4909)

v1.15.0 (2025-01-31)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Haoran Jie, Heng Pan, Ivelin Ivanov, Javier, Kevin Patel, Mohammad Naseri, Pavlos Bouzinis, Robert Steiner

What’s new?

  • Enhance SuperNode authentication (#4767, #4791, #4765, #4857, #4867)

    Enhances the SuperNode authentication system, making it more efficient and resilient against replay attacks. There’s no longer a need to pass --auth-superlink-private-key and --auth-superlink-public-key when running the SuperLink. Additionally, Flower now enables automatic node authentication by default, preventing impersonation even when node authentication is not explicitly used. For more details, see the documentation.

  • Add guide for running Flower with Deployment Engine (#4811, #4733)

    Introduces the How to run Flower with Deployment Engine guide, providing detailed instructions on deploying Federated Learning in production environments using the Flower Deployment Engine.

  • Add Flower Network Communication reference documentation (#4805)

    Introduces the Flower Network Communication documentation, which details the network connections used in a deployed Flower federated AI system.

  • Add LeRobot quickstart example (#4607, #4816)

    Introduces an example demonstrating federated training of a Diffusion policy on the PushT dataset using LeRobot and Flower. The dataset is partitioned with Flower Datasets, and the example runs best with a GPU. More details: Flower LeRobot Example.

  • Add video tutorial to simulation documentation (#4768)

    The Flower AI Simulation 2025 tutorial series is now available on YouTube. You can watch all the videos here or via the embedded previews in the documentation. The accompanying code for the tutorial can be found in the Flower GitHub repository.

  • Introduce StatAvg baseline (#3921)

    StatAvg mitigates non-IID feature distributions in federated learning by sharing and aggregating data statistics before training. It is compatible with any FL aggregation strategy. More details: StatAvg baseline.

  • Allow setting log level via environment variable (#4860, #4880, #4886)

    Log level can now be configured using the FLWR_LOG_LEVEL environment variable. For example, running FLWR_LOG_LEVEL=DEBUG flower-superlink --insecure will set the log level to DEBUG. For more details, see the guide.

  • Enable dynamic overrides for federation configuration in CLI (#4841, #4843, #4838)

    Similar to how the --run-config flag allows overriding the run configuration in flwr run, the new --federation-config flag enables dynamic overrides for federation configurations. This flag is supported in all flwr CLI commands except flwr build, flwr install, and flwr new.

  • Migrate TaskIns/TaskRes to Message-based communication (#4311, #4310, #4849, #4308, #4307, #4800, #4309, #4875, #4874, #4877, #4876)

    The Fleet API and the ServerAppIO API (formerly known as the Driver API) now use message-based communication instead of TaskIns/TaskRes, making interactions more intuitive and better aligned with their Python counterparts. This migration introduces new RPCs, such as PullMessages, PushMessages, and other message-based operations in the gRPC stack.

  • Introduce exit codes (#4801, #4845)

    Improves system error and help messages by introducing a dedicated flwr_exit function with standardized exit codes.

  • Update gRPC-related dependencies (#4833, #4836, #4887)

    Increases the version numbers of gRPC-related dependencies. In rare cases, if you encounter pip warnings about unresolved gRPC dependencies, it may be due to residual dependencies from older Flower versions.

  • Update app-pytorch example (#4842)

    The app-pytorch example is revamped to use the low-level API.

  • Improve CLI-side user authentication (#4862, #4861, #4832, #4850, #4703, #4885)

    User authentication in the CLI is enhanced with better handling, configuration options, and security enforcement.

  • Ensure graceful exit for SuperLink and SuperNode (#4829, #4846, #4798, #4826, #4881, #4797)

    Ensures proper resource cleanup and prevents zombie subprocesses during SuperLink and SuperNode shutdown.

  • Improve documentation (#4380, #4853, #4214, #4215, #4863, #4825, #4759, #4851, #4779, #4813, #4812, #4761, #4859, #4754, #4839, #4216, #4852, #4869)

    Updates PyTorch device selection in the tutorial series notebook and adds two molecular datasets to the recommended-fl-datasets table. Additional improvements include metadata updates, translation updates, and refinements to various documentation sections.

  • Update Docker dependencies and documentation (#4763, #4804, #4762, #4803, #4753)

  • Update CI/CD (#4756, #4834, #4824, #3493, #4096, #4807, #3956, #3168, #4835, #4884)

  • Bugfixes (#4766, #4764, #4795, #4840, #4868, #4872, #4890)

  • General improvements (#4748, #4799, #4645, #4819, #4755, #4789, #4771, #4854, #4796, #4865, #4820, #4790, #4821, #4822, #4751, #4793, #4871, #4785, #4787, #4775, #4783, #4818, #4786, #4773, #4772, #4784, #4810, #4770, #4870, #4878, #4889, #4893)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Incompatible changes

  • Remove deprecated app/--server arguments from flower-supernode (#4864, #4891)

    The deprecated app and --server arguments in flower-supernode has been removed. Please use --superlink instead of --server.

  • Deprecate --auth-superlink-private-key/--auth-superlink-public-key arguments from flower-superlink (#4848)

    The two arguments are no longer necessary for SuperNode authentication following the recent improvement mentioned above.

v1.14.0 (2024-12-20)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Chong Shen Ng, Daniel Nata Nugraha, Dimitris Stripelis, Heng Pan, Javier, Meng Yan, Mohammad Naseri, Robert Steiner, Taner Topal, Vidit Khandelwal, Yan Gao

What’s new?

  • Introduce flwr stop command (#4647, #4629, #4694, #4646, #4634, #4700, #4684, #4642, #4682, #4683, #4639, #4668, #4658, #4693, #4704, #4729)

    The flwr stop command is now available to stop a submitted run. You can use it as follows:

    • flwr stop <run-id>

    • flwr stop <run-id> [<app>] [<federation>]

    This command instructs the SuperLink to terminate the specified run. While the execution of ServerApp and ClientApp processes will not be interrupted instantly, they will be informed of the stopped run and will gracefully terminate when they next communicate with the SuperLink.

  • Add JSON format output for CLI commands (#4610, #4613, #4710, #4621, #4612, #4619, #4611, #4620, #4712, #4633, #4632, #4711, #4714, #4734, #4738)

    The flwr run, flwr ls, and flwr stop commands now support JSON-formatted output using the --format json flag. This makes it easier to parse and integrate CLI output with other tools. Feel free to check the “How to Use CLI JSON output” guide for details!

  • Document Microsoft Azure deployment (#4625)

    A new how-to guide shows a simple Flower deployment for federated learning on Microsoft Azure VM instances.

  • Introduce OIDC user authentication infrastructure (#4630, #4244, #4602, #4618, #4717, #4719, #4745)

    Flower has supported SuperNode authentication since Flower 1.9. This release adds initial extension points for user authentication via OpenID Connect (OIDC).

  • Update FedRep baseline (#4681)

    We have started the process of migrating some baselines from using start_simulation to be launched via flwr run. We chose FedRep as the first baseline to migrate due to its very impressive results. New baselines can be created following a flwr run-compatible format by starting from the flwr new template for baselines. We welcome contributions! Read more in the how to contribute a baseline documentation.

  • Revamp simulation series tutorial (#4663, #4696)

    We have updated the Step-by-step Tutorial Series for Simulations. It now shows how to create and run Flower Apps via flwr run. The videos walk you through the process of creating custom strategies, effectively make use of metrics between ClientApp and ServerApp, create global model checkpoints, log metrics to Weights & Biases, and more.

  • Improve connection reliability (#4649, #4636, #4637)

    Connections between ServerApp<>SuperLink, ClientApp<>SuperNode, and SuperLink<>Simulation are now more robust against network issues.

  • Fix flwr new issue on Windows (#4653)

    The flwr new command now works correctly on Windows by setting UTF-8 encoding, ensuring compatibility across all platforms when creating and transferring files.

  • Update examples and flwr new templates (#4725, #4724, #4589, #4690, #4708, #4689, #4740, #4741, #4744)

    Code examples and flwr new templates have been updated to improve compatibility and usability. Notable changes include removing unnecessary numpy dependencies, upgrading the mlx version, and enhancing the authentication example. A link to previous tutorial versions has also been added for reference.

  • Improve documentation (#4713, #4624, #4606, #4596, #4695, #4654, #4656, #4603, #4727, #4723, #4598, #4661, #4655, #4659)

    Documentation has been improved with updated docstrings, typo fixes, and new contributions guidance. Automated updates ensure source texts for translations stay current.

  • Update infrastructure and CI/CD (#4614, #4686, #4587, #4715, #4728, #4679, #4675, #4680, #4676)

  • Bugfixes (#4677, #4671, #4670, #4674, #4687, #4605, #4736)

  • General improvements (#4631, #4660, #4599, #4672, #4705, #4688, #4691, #4706, #4709, #4623, #4697, #4597, #4721, #4730, #4720, #4747, #4716, #4752)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Incompatible changes

  • Remove context property from Client and NumPyClient (#4652)

    Now that Context is available as an argument in client_fn and server_fn, the context property is removed from Client and NumPyClient. This feature has been deprecated for several releases and is now removed.

v1.13.1 (2024-11-26)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Heng Pan, Javier, Robert Steiner

What’s new?

  • Fix SimulationEngine Executor for SuperLink (#4563, #4568, #4570)

    Resolved an issue that prevented SuperLink from functioning correctly when using the SimulationEngine executor.

  • Improve FAB build and install (#4571)

    An updated FAB build and install process produces smaller FAB files and doesn’t rely on pip install any more. It also resolves an issue where all files were unnecessarily included in the FAB file. The flwr CLI commands now correctly pack only the necessary files, such as .md, .toml and .py, ensuring more efficient and accurate packaging.

  • Update embedded-devices example (#4381)

    The example now uses the flwr run command and the Deployment Engine.

  • Update Documentation (#4566, #4569, #4560, #4556, #4581, #4537, #4562, #4582)

    Enhanced documentation across various aspects, including updates to translation workflows, Docker-related READMEs, and recommended datasets. Improvements also include formatting fixes for dataset partitioning docs and better references to resources in the datasets documentation index.

  • Update Infrastructure and CI/CD (#4577, #4578, #4558, #4551, #3356, #4559, #4575)

  • General improvements (#4557, #4564, #4573, #4561, #4579, #4572)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

v1.13.0 (2024-11-20)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Dimitris Stripelis, Heng Pan, Javier, Mohammad Naseri, Robert Steiner, Waris Gill, William Lindskog, Yan Gao, Yao Xu, wwjang

What’s new?

  • Introduce flwr ls command (#4460, #4459, #4477)

    The flwr ls command is now available to display details about all runs (or one specific run). It supports the following usage options:

    • flwr ls --runs [<app>] [<federation>]: Lists all runs.

    • flwr ls --run-id <run-id> [<app>] [<federation>]: Displays details for a specific run.

    This command provides information including the run ID, FAB ID and version, run status, elapsed time, and timestamps for when the run was created, started running, and finished.

  • Fuse SuperLink and SuperExec (#4358, #4403, #4406, #4357, #4359, #4354, #4229, #4283, #4352)

    SuperExec has been integrated into SuperLink, enabling SuperLink to directly manage ServerApp processes (flwr-serverapp). The flwr CLI now targets SuperLink’s Exec API. Additionally, SuperLink introduces two isolation modes for running ServerApps: subprocess (default) and process, which can be specified using the --isolation {subprocess,process} flag.

  • Introduce flwr-serverapp command (#4394, #4370, #4367, #4350, #4364, #4400, #4363, #4401, #4388, #4402)

    The flwr-serverapp command has been introduced as a CLI entry point that runs a ServerApp process. This process communicates with SuperLink to load and execute the ServerApp object, enabling isolated execution and more flexible deployment.

  • Improve simulation engine and introduce flwr-simulation command (#4433, #4486, #4448, #4427, #4438, #4421, #4430, #4462)

    The simulation engine has been significantly improved, resulting in dramatically faster simulations. Additionally, the flwr-simulation command has been introduced to enhance maintainability and provide a dedicated entry point for running simulations.

  • Improve SuperLink message management (#4378, #4369)

    SuperLink now validates the destination node ID of instruction messages and checks the TTL (time-to-live) for reply messages. When pulling reply messages, an error reply will be generated and returned if the corresponding instruction message does not exist, has expired, or if the reply message exists but has expired.

  • Introduce FedDebug baseline (#3783)

    FedDebug is a framework that enhances debugging in Federated Learning by enabling interactive inspection of the training process and automatically identifying clients responsible for degrading the global model’s performance—all without requiring testing data or labels. Learn more in the FedDebug baseline documentation.

  • Update documentation (#4511, #4010, #4396, #4499, #4269, #3340, #4482, #4387, #4342, #4492, #4474, #4500, #4514, #4236, #4112, #3367, #4501, #4373, #4409, #4356, #4520, #4524, #4525, #4526, #4527, #4528, #4545, #4522, #4534, #4513, #4529, #4441, #4530, #4470, #4553, #4531, #4554, #4555, #4552, #4533)

    Many documentation pages and tutorials have been updated to improve clarity, fix typos, incorporate user feedback, and stay aligned with the latest features in the framework. Key updates include adding a guide for designing stateful ClientApp objects, updating the comprehensive guide for setting up and running Flower’s Simulation Engine, updating the XGBoost, scikit-learn, and JAX quickstart tutorials to use flwr run, updating DP guide, removing outdated pages, updating Docker docs, and marking legacy functions as deprecated. The Secure Aggregation Protocols page has also been updated.

  • Update examples and templates (#4510, #4368, #4121, #4329, #4382, #4248, #4395, #4386, #4408)

    Multiple examples and templates have been updated to enhance usability and correctness. The updates include the 30-minute-tutorial, quickstart-jax, quickstart-pytorch, advanced-tensorflow examples, and the FlowerTune template.

  • Improve Docker support (#4506, #4424, #4224, #4413, #4414, #4336, #4420, #4407, #4422, #4532, #4540)

    Docker images and configurations have been updated, including updating Docker Compose files to version 1.13.0, refactoring the Docker build matrix for better maintainability, updating docker/build-push-action to 6.9.0, and improving Docker documentation.

  • Allow app installation without internet access (#4479, #4475)

    The flwr build command now includes a wheel file in the FAB, enabling Flower app installation in environments without internet access via flwr install.

  • Improve flwr log command (#4391, #4411, #4390, #4397)

  • Refactor SuperNode for better maintainability and efficiency (#4439, #4348, #4512, #4485)

  • Support NumPy 2.0 (#4440)

  • Update infrastructure and CI/CD (#4466, #4419, #4338, #4334, #4456, #4446, #4415)

  • Bugfixes (#4404, #4518, #4452, #4376, #4493, #4436, #4410, #4442, #4375, #4515)

  • General improvements (#4454, #4365, #4423, #4516, #4509, #4498, #4371, #4449, #4488, #4478, #4392, #4483, #4517, #4330, #4458, #4347, #4429, #4463, #4496, #4508, #4444, #4417, #4504, #4418, #4480, #4455, #4468, #4385, #4487, #4393, #4489, #4389, #4507, #4469, #4340, #4353, #4494, #4461, #4362, #4473, #4405, #4416, #4453, #4491, #4539, #4542, #4538, #4543, #4541, #4550, #4481)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Deprecations

  • Deprecate Python 3.9

    Flower is deprecating support for Python 3.9 as several of its dependencies are phasing out compatibility with this version. While no immediate changes have been made, users are encouraged to plan for upgrading to a supported Python version.

Incompatible changes

  • Remove flower-superexec command (#4351)

    The flower-superexec command, previously used to launch SuperExec, is no longer functional as SuperExec has been merged into SuperLink. Starting an additional SuperExec is no longer necessary when SuperLink is initiated.

  • Remove flower-server-app command (#4490)

    The flower-server-app command has been removed. To start a Flower app, please use the flwr run command instead.

  • Remove app argument from flower-supernode command (#4497)

    The usage of flower-supernode <app-dir> has been removed. SuperNode will now load the FAB delivered by SuperLink, and it is no longer possible to directly specify an app directory.

  • Remove support for non-app simulations (#4431)

    The simulation engine (via flower-simulation) now exclusively supports passing an app.

  • Rename CLI arguments for flower-superlink command (#4412)

    The --driver-api-address argument has been renamed to --serverappio-api-address in the flower-superlink command to reflect the renaming of the Driver service to the ServerAppIo service.

  • Rename CLI arguments for flwr-serverapp and flwr-clientapp commands (#4495)

    The CLI arguments have been renamed for clarity and consistency. Specifically, --superlink for flwr-serverapp is now --serverappio-api-address, and --supernode for flwr-clientapp is now --clientappio-api-address.

v1.12.0 (2024-10-14)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Audris, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Heng Pan, Javier, Jiahao Tan, Julian Rußmeyer, Mohammad Naseri, Ray Sun, Robert Steiner, Yan Gao, xiliguguagua

What’s new?

  • Introduce SuperExec log streaming (#3577, #3584, #4242, #3611, #3613)

    Flower now supports log streaming from a remote SuperExec using the flwr log command. This new feature allows you to monitor logs from SuperExec in real time via flwr log <run-id> (or flwr log <run-id> <app-dir> <federation>).

  • Improve flwr new templates (#4291, #4292, #4293, #4294, #4295)

    The flwr new command templates for MLX, NumPy, sklearn, JAX, and PyTorch have been updated to improve usability and consistency across frameworks.

  • Migrate ID handling to use unsigned 64-bit integers (#4170, #4237, #4243)

    Node IDs, run IDs, and related fields have been migrated from signed 64-bit integers (sint64) to unsigned 64-bit integers (uint64). To support this change, the uint64 type is fully supported in all communications. You may now use uint64 values in config and metric dictionaries. For Python users, that means using int values larger than the maximum value of sint64 but less than the maximum value of uint64.

  • Add Flower architecture explanation (#3270)

    A new Flower architecture explainer page introduces Flower components step-by-step. Check out the EXPLANATIONS section of the Flower documentation if you’re interested.

  • Introduce FedRep baseline (#3790)

    FedRep is a federated learning algorithm that learns shared data representations across clients while allowing each to maintain personalized local models, balancing collaboration and individual adaptation. Read all the details in the paper: “Exploiting Shared Representations for Personalized Federated Learning” (arxiv)

  • Improve FlowerTune template and LLM evaluation pipelines (#4286, #3769, #4272, #4257, #4220, #4282, #4171, #4228, #4258, #4296, #4287, #4217, #4249, #4324, #4219, #4327)

    Refined evaluation pipelines, metrics, and documentation for the upcoming FlowerTune LLM Leaderboard across multiple domains including Finance, Medical, and general NLP. Stay tuned for the official launch—we welcome all federated learning and LLM enthusiasts to participate in this exciting challenge!

  • Enhance Docker Support and Documentation (#4191, #4251, #4190, #3928, #4298, #4192, #4136, #4187, #4261, #4177, #4176, #4189, #4297, #4226)

    Upgraded Ubuntu base image to 24.04, added SBOM and gcc to Docker images, and comprehensively updated Docker documentation including quickstart guides and distributed Docker Compose instructions.

  • Introduce Flower glossary (#4165, #4235)

    Added the Federated Learning glossary to the Flower repository, located under the flower/glossary/ directory. This resource aims to provide clear definitions and explanations of key FL concepts. Community contributions are highly welcomed to help expand and refine this knowledge base — this is probably the easiest way to become a Flower contributor!

  • Implement Message Time-to-Live (TTL) (#3620, #3596, #3615, #3609, #3635)

    Added comprehensive TTL support for messages in Flower’s SuperLink. Messages are now automatically expired and cleaned up based on configurable TTL values, available through the low-level API (and used by default in the high-level API).

  • Improve FAB handling (#4303, #4264, #4305, #4304)

    An 8-character hash is now appended to the FAB file name. The flwr install command installs FABs with a more flattened folder structure, reducing it from 3 levels to 1.

  • Update documentation (#3341, #3338, #3927, #4152, #4151, #3993)

    Updated quickstart tutorials (PyTorch Lightning, TensorFlow, Hugging Face, Fastai) to use the new flwr run command and removed default title from documentation base template. A new blockchain example has been added to FAQ.

  • Update example projects (#3716, #4007, #4130, #4234, #4206, #4188, #4247, #4331)

    Refreshed multiple example projects including vertical FL, PyTorch (advanced), Pandas, Secure Aggregation, and XGBoost examples. Optimized Hugging Face quickstart with a smaller language model and removed legacy simulation examples.

  • Update translations (#4070, #4316, #4252, #4256, #4210, #4263, #4259)

  • General improvements (#4239, 4276, 4204, 4184, 4227, 4183, 4202, 4250, 4267, 4246, 4240, 4265, 4238, 4275, 4318, #4178, #4315, #4241, #4289, #4290, #4181, #4208, #4225, #4314, #4174, #4203, #4274, #3154, #4201, #4268, #4254, #3990, #4212, #2938, #4205, #4222, #4313, #3936, #4278, #4319, #4332, #4333)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Incompatible changes

  • Drop Python 3.8 support and update minimum version to 3.9 (#4180, #4213, #4193, #4199, #4196, #4195, #4198, #4194)

    Python 3.8 support was deprecated in Flower 1.9, and this release removes support. Flower now requires Python 3.9 or later (Python 3.11 is recommended). CI and documentation were updated to use Python 3.9 as the minimum supported version. Flower now supports Python 3.9 to 3.12.

v1.11.1 (2024-09-11)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Heng Pan, Javier, Robert Steiner, Yan Gao

Improvements

  • Implement keys/values/items methods for TypedDict (#4146)

  • Fix parsing of --executor-config if present (#4125)

  • Adjust framework name in templates docstrings (#4127)

  • Update flwr new Hugging Face template (#4169)

  • Fix flwr new FlowerTune template (#4123)

  • Add buffer time after ServerApp thread initialization (#4119)

  • Handle unsuitable resources for simulation (#4143)

  • Update example READMEs (#4117)

  • Update SuperNode authentication docs (#4160)

Incompatible changes

None

v1.11.0 (2024-08-30)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Edoardo Gabrielli, Heng Pan, Javier, Meng Yan, Michal Danilowski, Mohammad Naseri, Robert Steiner, Steve Laskaridis, Taner Topal, Yan Gao

What’s new?

  • Deliver Flower App Bundle (FAB) to SuperLink and SuperNodes (#4006, #3945, #3999, #4027, #3851, #3946, #4003, #4029, #3942, #3957, #4020, #4044, #3852, #4019, #4031, #4036, #4049, #4017, #3943, #3944, #4011, #3619)

    Dynamic code updates are here! flwr run can now ship and install the latest version of your ServerApp and ClientApp to an already-running federation (SuperLink and SuperNodes).

    How does it work? flwr run bundles your Flower app into a single FAB (Flower App Bundle) file. It then ships this FAB file, via the SuperExec, to both the SuperLink and those SuperNodes that need it. This allows you to keep SuperExec, SuperLink and SuperNodes running as permanent infrastructure, and then ship code updates (including completely new projects!) dynamically.

    flwr run is all you need.

  • Introduce isolated ClientApp execution (#3970, #3976, #4002, #4001, #4034, #4037, #3977, #4042, #3978, #4039, #4033, #3971, #4035, #3973, #4032)

    The SuperNode can now run your ClientApp in a fully isolated way. In an enterprise deployment, this allows you to set strict limits on what the ClientApp can and cannot do.

    flower-supernode supports three --isolation modes:

    • Unset: The SuperNode runs the ClientApp in the same process (as in previous versions of Flower). This is the default mode.

    • --isolation=subprocess: The SuperNode starts a subprocess to run the ClientApp.

    • --isolation=process: The SuperNode expects an externally-managed process to run the ClientApp. This external process is not managed by the SuperNode, so it has to be started beforehand and terminated manually. The common way to use this isolation mode is via the new flwr/clientapp Docker image.

  • Improve Docker support for enterprise deployments (#4050, #4090, #3784, #3998, #4094, #3722)

    Flower 1.11 ships many Docker improvements that are especially useful for enterprise deployments:

    • flwr/supernode comes with a new Alpine Docker image.

    • flwr/clientapp is a new image to be used with the --isolation=process option. In this mode, SuperNode and ClientApp run in two different Docker containers. flwr/supernode (preferably the Alpine version) runs the long-running SuperNode with --isolation=process. flwr/clientapp runs the ClientApp. This is the recommended way to deploy Flower in enterprise settings.

    • New all-in-one Docker Compose enables you to easily start a full Flower Deployment Engine on a single machine.

    • Completely new Docker documentation: https://flower.ai/docs/framework/docker/index.html

  • Improve SuperNode authentication (#4043, #4047, #4074)

    SuperNode auth has been improved in several ways, including improved logging, improved testing, and improved error handling.

  • Update flwr new templates (#3933, #3894, #3930, #3931, #3997, #3979, #3965, #4013, #4064)

    All flwr new templates have been updated to show the latest recommended use of Flower APIs.

  • Improve Simulation Engine (#4095, #3913, #4059, #3954, #4071, #3985, #3988)

    The Flower Simulation Engine comes with several updates, including improved run config support, verbose logging, simulation backend configuration via flwr run, and more.

  • Improve RecordSet (#4052, #3218, #4016)

    RecordSet is the core object to exchange model parameters, configuration values and metrics between ClientApp and ServerApp. This release ships several smaller improvements to RecordSet and related *Record types.

  • Update documentation (#3972, #3925, #4061, #3984, #3917, #3900, #4066, #3765, #4021, #3906, #4063, #4076, #3920, #3916)

    Many parts of the documentation, including the main tutorial, have been migrated to show new Flower APIs and other new Flower features like the improved Docker support.

  • Migrate code example to use new Flower APIs (#3758, #3701, #3919, #3918, #3934, #3893, #3833, #3922, #3846, #3777, #3874, #3873, #3935, #3754, #3980, #4089, #4046, #3314, #3316, #3295, #3313)

    Many code examples have been migrated to use new Flower APIs.

  • Update Flower framework, framework internals and quality infrastructure (#4018, #4053, #4098, #4067, #4105, #4048, #4107, #4069, #3915, #4101, #4108, #3914, #4068, #4041, #4040, #3986, #4026, #3961, #3975, #3983, #4091, #3982, #4079, #4073, #4060, #4106, #4080, #3974, #3996, #3991, #3981, #4093, #4100, #3939, #3955, #3940, #4038)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Deprecations

  • Deprecate accessing Context via Client.context (#3797)

    Now that both client_fn and server_fn receive a Context object, accessing Context via Client.context is deprecated. Client.context will be removed in a future release. If you need to access Context in your Client implementation, pass it manually when creating the Client instance in client_fn:

    def client_fn(context: Context) -> Client:
    return FlowerClient(context).to_client()

Incompatible changes

  • Update CLIs to accept an app directory instead of ClientApp and ServerApp (#3952, #4077, #3850)

    The CLI commands flower-supernode and flower-server-app now accept an app directory as argument (instead of references to a ClientApp or ServerApp). An app directory is any directory containing a pyproject.toml file (with the appropriate Flower config fields set). The easiest way to generate a compatible project structure is to use flwr new.

  • Disable flower-client-app CLI command (#4022)

    flower-client-app has been disabled. Use flower-supernode instead.

  • Use spaces instead of commas for separating config args (#4000)

    When passing configs (run config, node config) to Flower, you now need to separate key-value pairs using spaces instead of commas. For example:

    flwr run . --run-config "learning-rate=0.01 num_rounds=10"  # Works

    Previously, you could pass configs using commas, like this:

    flwr run . --run-config "learning-rate=0.01,num_rounds=10"  # Doesn't work

  • Remove flwr example CLI command (#4084)

    The experimental flwr example CLI command has been removed. Use flwr new to generate a project and then run it using flwr run.

v1.10.0 (2024-07-24)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Gustavo Bertoli, Heng Pan, Ikko Eltociear Ashimine, Javier, Jiahao Tan, Mohammad Naseri, Robert Steiner, Sebastian van der Voort, Taner Topal, Yan Gao

What’s new?

  • Introduce flwr run (beta) (#3810, #3826, #3880, #3807, #3800, #3814, #3811, #3809, #3819)

    Flower 1.10 ships the first beta release of the new flwr run command. flwr run can run different projects using flwr run path/to/project, it enables you to easily switch between different federations using flwr run . federation and it runs your Flower project using either local simulation or the new (experimental) SuperExec service. This allows Flower to scale federatated learning from fast local simulation to large-scale production deployment, seamlessly. All projects generated with flwr new are immediately runnable using flwr run. Give it a try: use flwr new to generate a project and then run it using flwr run.

  • Introduce run config (#3751, #3750, #3845, #3824, #3746, #3728, #3730, #3725, #3729, #3580, #3578, #3576, #3798, #3732, #3815)

    The new run config feature allows you to run your Flower project in different configurations without having to change a single line of code. You can now build a configurable ServerApp and ClientApp that read configuration values at runtime. This enables you to specify config values like learning-rate=0.01 in pyproject.toml (under the [tool.flwr.app.config] key). These config values can then be easily overridden via flwr run --run-config learning-rate=0.02, and read from Context using lr = context.run_config["learning-rate"]. Create a new project using flwr new to see run config in action.

  • Generalize client_fn signature to client_fn(context: Context) -> Client (#3779, #3697, #3694, #3696)

    The client_fn signature has been generalized to client_fn(context: Context) -> Client. It now receives a Context object instead of the (now depreacated) cid: str. Context allows accessing node_id, node_config and run_config, among other things. This enables you to build a configurable ClientApp that leverages the new run config system.

    The previous signature client_fn(cid: str) is now deprecated and support for it will be removed in a future release. Use client_fn(context: Context) -> Client everywhere.

  • Introduce new server_fn(context) (#3773, #3796, #3771)

    In addition to the new client_fn(context:Context), a new server_fn(context: Context) -> ServerAppComponents can now be passed to ServerApp (instead of passing, for example, Strategy, directly). This enables you to leverage the full Context on the server-side to build a configurable ServerApp.

  • Relaunch all flwr new templates (#3877, #3821, #3587, #3795, #3875, #3859, #3760)

    All flwr new templates have been significantly updated to showcase new Flower features and best practices. This includes using flwr run and the new run config feature. You can now easily create a new project using flwr new and, after following the instructions to install it, flwr run it.

  • Introduce flower-supernode (preview) (#3353)

    The new flower-supernode CLI is here to replace flower-client-app. flower-supernode brings full multi-app support to the Flower client-side. It also allows to pass --node-config to the SuperNode, which is accessible in your ClientApp via Context (using the new client_fn(context: Context) signature).

  • Introduce node config (#3782, #3780, #3695, #3886)

    A new node config feature allows you to pass a static configuration to the SuperNode. This configuration is read-only and available to every ClientApp running on that SuperNode. A ClientApp can access the node config via Context (context.node_config).

  • Introduce SuperExec (experimental) (#3605, #3723, #3731, #3589, #3604, #3622, #3838, #3720, #3606, #3602, #3603, #3555, #3808, #3724, #3658, #3629)

    This is the first experimental release of Flower SuperExec, a new service that executes your runs. It’s not ready for production deployment just yet, but don’t hesitate to give it a try if you’re interested.

  • Add new federated learning with tabular data example (#3568)

    A new code example exemplifies a federated learning setup using the Flower framework on the Adult Census Income tabular dataset.

  • Create generic adapter layer (preview) (#3538, #3536, #3540)

    A new generic gRPC adapter layer allows 3rd-party frameworks to integrate with Flower in a transparent way. This makes Flower more modular and allows for integration into other federated learning solutions and platforms.

  • Refactor Flower Simulation Engine (#3581, #3471, #3804, #3468, #3839, #3806, #3861, #3543, #3472, #3829, #3469)

    The Simulation Engine was significantly refactored. This results in faster and more stable simulations. It is also the foundation for upcoming changes that aim to provide the next level of performance and configurability in federated learning simulations.

  • Optimize Docker containers (#3591)

    Flower Docker containers were optimized and updated to use that latest Flower framework features.

  • Improve logging (#3776, #3789)

    Improved logging aims to be more concise and helpful to show you the details you actually care about.

  • Refactor framework internals (#3621, #3792, #3772, #3805, #3583, #3825, #3597, #3802, #3569)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Documentation improvements

Deprecations

  • Deprecate client_fn(cid: str)

    client_fn used to have a signature client_fn(cid: str) -> Client. This signature is now deprecated. Use the new signature client_fn(context: Context) -> Client instead. The new argument context allows accessing node_id, node_config, run_config and other Context features. When running using the simulation engine (or using flower-supernode with a custom --node-config partition-id=...), context.node_config["partition-id"] will return an int partition ID that can be used with Flower Datasets to load a different partition of the dataset on each simulated or deployed SuperNode.

  • Deprecate passing Server/ServerConfig/Strategy/ClientManager to ServerApp directly

    Creating ServerApp using ServerApp(config=config, strategy=strategy) is now deprecated. Instead of passing Server/ServerConfig/Strategy/ClientManager to ServerApp directly, pass them wrapped in a server_fn(context: Context) -> ServerAppComponents function, like this: ServerApp(server_fn=server_fn). ServerAppComponents can hold references to Server/ServerConfig/Strategy/ClientManager. In addition to that, server_fn allows you to access Context (for example, to read the run_config).

Incompatible changes

  • Remove support for client_ids in start_simulation (#3699)

    The (rarely used) feature that allowed passing custom client_ids to the start_simulation function was removed. This removal is part of a bigger effort to refactor the simulation engine and unify how the Flower internals work in simulation and deployment.

  • Remove flower-driver-api and flower-fleet-api (#3418)

    The two deprecated CLI commands flower-driver-api and flower-fleet-api were removed in an effort to streamline the SuperLink developer experience. Use flower-superlink instead.

v1.9.0 (2024-06-10)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Heng Pan, Javier, Mahdi Beitollahi, Robert Steiner, Taner Topal, Yan Gao, bapic, mohammadnaseri

What’s new?

Deprecations

  • Deprecate Python 3.8 support

    Python 3.8 will stop receiving security fixes in October 2024. Support for Python 3.8 is now deprecated and will be removed in an upcoming release.

  • Deprecate (experimental) flower-driver-api and flower-fleet-api (#3416, #3420)

    Flower 1.9 deprecates the two (experimental) commands flower-driver-api and flower-fleet-api. Both commands will be removed in an upcoming release. Use flower-superlink instead.

  • Deprecate --server in favor of --superlink (#3518)

    The commands flower-server-app and flower-client-app should use --superlink instead of the now deprecated --server. Support for --server will be removed in a future release.

Incompatible changes

  • Replace flower-superlink CLI option --certificates with --ssl-ca-certfile , --ssl-certfile and --ssl-keyfile (#3512, #3408)

    SSL-related flower-superlink CLI arguments were restructured in an incompatible way. Instead of passing a single --certificates flag with three values, you now need to pass three flags (--ssl-ca-certfile, --ssl-certfile and --ssl-keyfile) with one value each. Check out the SSL connections documentation page for details.

  • Remove SuperLink --vce option (#3513)

    Instead of separately starting a SuperLink and a ServerApp for simulation, simulations must now be started using the single flower-simulation command.

  • Merge --grpc-rere and --rest SuperLink options (#3527)

    To simplify the usage of flower-superlink, previously separate sets of CLI options for gRPC and REST were merged into one unified set of options. Consult the Flower CLI reference documentation for details.

v1.8.0 (2024-04-03)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Gustavo Bertoli, Heng Pan, Ikko Eltociear Ashimine, Jack Cook, Javier, Raj Parekh, Robert Steiner, Sebastian van der Voort, Taner Topal, Yan Gao, mohammadnaseri, tabdar-khan

What’s new?

  • Introduce Flower Next high-level API (stable) (#3002, #2934, #2958, #3173, #3174, #2923, #2691, #3079, #2961, #2924, #3166, #3031, #3057, #3000, #3113, #2957, #3183, #3180, #3035, #3189, #3185, #3190, #3191, #3195, #3197)

    The Flower Next high-level API is stable! Flower Next is the future of Flower - all new features (like Flower Mods) will be built on top of it. You can start to migrate your existing projects to Flower Next by using ServerApp and ClientApp (check out quickstart-pytorch or quickstart-tensorflow, a detailed migration guide will follow shortly). Flower Next allows you to run multiple projects concurrently (we call this multi-run) and execute the same project in either simulation environments or deployment environments without having to change a single line of code. The best part? It’s fully compatible with existing Flower projects that use Strategy, NumPyClient & co.

  • Introduce Flower Next low-level API (preview) (#3062, #3034, #3069)

    In addition to the Flower Next high-level API that uses Strategy, NumPyClient & co, Flower 1.8 also comes with a preview version of the new Flower Next low-level API. The low-level API allows for granular control of every aspect of the learning process by sending/receiving individual messages to/from client nodes. The new ServerApp supports registering a custom main function that allows writing custom training loops for methods like async FL, cyclic training, or federated analytics. The new ClientApp supports registering train, evaluate and query functions that can access the raw message received from the ServerApp. New abstractions like RecordSet, Message and Context further enable sending multiple models, multiple sets of config values and metrics, stateful computations on the client node and implementations of custom SMPC protocols, to name just a few.

  • Introduce Flower Mods (preview) (#3054, #2911, #3083)

    Flower Modifiers (we call them Mods) can intercept messages and analyze, edit or handle them directly. Mods can be used to develop pluggable modules that work across different projects. Flower 1.8 already includes mods to log the size of a message, the number of parameters sent over the network, differential privacy with fixed clipping and adaptive clipping, local differential privacy and secure aggregation protocols SecAgg and SecAgg+. The Flower Mods API is released as a preview, but researchers can already use it to experiment with arbirtrary SMPC protocols.

  • Fine-tune LLMs with LLM FlowerTune (#3029, #3089, #3092, #3100, #3114, #3162, #3172)

    We are introducing LLM FlowerTune, an introductory example that demonstrates federated LLM fine-tuning of pre-trained Llama2 models on the Alpaca-GPT4 dataset. The example is built to be easily adapted to use different models and/or datasets. Read our blog post LLM FlowerTune: Federated LLM Fine-tuning with Flower for more details.

  • Introduce built-in Differential Privacy (preview) (#2798, #2959, #3038, #3147, #2909, #2893, #2892, #3039, #3074)

    Built-in Differential Privacy is here! Flower supports both central and local differential privacy (DP). Central DP can be configured with either fixed or adaptive clipping. The clipping can happen either on the server-side or the client-side. Local DP does both clipping and noising on the client-side. A new documentation page explains Differential Privacy approaches and a new how-to guide describes how to use the new Differential Privacy components in Flower.

  • Introduce built-in Secure Aggregation (preview) (#3120, #3110, #3108)

    Built-in Secure Aggregation is here! Flower now supports different secure aggregation protocols out-of-the-box. The best part? You can add secure aggregation to your Flower projects with only a few lines of code. In this initial release, we inlcude support for SecAgg and SecAgg+, but more protocols will be implemented shortly. We’ll also add detailed docs that explain secure aggregation and how to use it in Flower. You can already check out the new code example that shows how to use Flower to easily combine Federated Learning, Differential Privacy and Secure Aggregation in the same project.

  • Introduce flwr CLI (preview) (#2942, #3055, #3111, #3130, #3136, #3094, #3059, #3049, #3142)

    A new flwr CLI command allows creating new Flower projects (flwr new) and then running them using the Simulation Engine (flwr run).

  • Introduce Flower Next Simulation Engine (#3024, #3061, #2997, #2783, #3184, #3075, #3047, #2998, #3009, #3008)

    The Flower Simulation Engine can now run Flower Next projects. For notebook environments, there’s also a new run_simulation function that can run ServerApp and ClientApp.

  • Handle SuperNode connection errors (#2969)

    A SuperNode will now try to reconnect indefinitely to the SuperLink in case of connection errors. The arguments --max-retries and --max-wait-time can now be passed to the flower-client-app command. --max-retries will define the number of tentatives the client should make before it gives up trying to reconnect to the SuperLink, and, --max-wait-time defines the time before the SuperNode gives up trying to reconnect to the SuperLink.

  • General updates to Flower Baselines (#2904, #2482, #2985, #2968)

    There’s a new FedStar baseline. Several other baselined have been updated as well.

  • Improve documentation and translations (#3050, #3044, #3043, #2986, #3041, #3046, #3042, #2978, #2952, #3167, #2953, #3045, #2654, #3082, #2990, #2989)

    As usual, we merged many smaller and larger improvements to the documentation. A special thank you goes to Sebastian van der Voort for landing a big documentation PR!

  • General updates to Flower Examples (3134, 2996, 2930, 2967, 2467, 2910, #2918, #2773, #3063, #3116, #3117)

    Two new examples show federated training of a Vision Transformer (ViT) and federated learning in a medical context using the popular MONAI library. quickstart-pytorch and quickstart-tensorflow demonstrate the new Flower Next ServerApp and ClientApp. Many other examples received considerable updates as well.

  • General improvements (#3171, 3099, 3003, 3145, 3017, 3085, 3012, 3119, 2991, 2970, 2980, 3086, 2932, 2928, 2941, 2933, 3181, 2973, 2992, 2915, 3040, 3022, 3032, 2902, 2931, 3005, 3132, 3115, 2944, 3064, 3106, 2974, 3178, 2993, 3186, 3091, 3125, 3093, 3013, 3033, 3133, 3068, 2916, 2975, 2984, 2846, 3077, 3143, 2921, 3101, 2927, 2995, 2972, 2912, 3065, 3028, 2922, 2982, 2914, 3179, 3080, 2994, 3187, 2926, 3018, 3144, 3011, #3152, #2836, #2929, #2943, #2955, #2954)

Incompatible changes

None

v1.7.0 (2024-02-05)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Aasheesh Singh, Adam Narozniak, Aml Hassan Esmil, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Edoardo Gabrielli, Gustavo Bertoli, HelinLin, Heng Pan, Javier, M S Chaitanya Kumar, Mohammad Naseri, Nikos Vlachakis, Pritam Neog, Robert Kuska, Robert Steiner, Taner Topal, Yahia Salaheldin Shaaban, Yan Gao, Yasar Abbas

What’s new?

Incompatible changes

  • Deprecate start_numpy_client (#2563, #2718)

    Until now, clients of type NumPyClient needed to be started via start_numpy_client. In our efforts to consolidate framework APIs, we have introduced changes, and now all client types should start via start_client. To continue using NumPyClient clients, you simply need to first call the .to_client() method and then pass returned Client object to start_client. The examples and the documentation have been updated accordingly.

  • Deprecate legacy DP wrappers (#2749)

    Legacy DP wrapper classes are deprecated, but still functional. This is in preparation for an all-new pluggable version of differential privacy support in Flower.

  • Make optional arg --callable in flower-client a required positional arg (#2673)

  • Rename certificates to root_certificates in Driver (#2890)

  • Drop experimental Task fields (#2866, #2865)

    Experimental fields sa, legacy_server_message and legacy_client_message were removed from Task message. The removed fields are superseded by the new RecordSet abstraction.

  • Retire MXNet examples (#2724)

    The development of the MXNet fremework has ended and the project is now archived on GitHub. Existing MXNet examples won’t receive updates.

v1.6.0 (2023-11-28)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Aashish Kolluri, Adam Narozniak, Alessio Mora, Barathwaja S, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Gabriel Mota, Heng Pan, Ivan Agarský, JS.KIM, Javier, Marius Schlegel, Navin Chandra, Nic Lane, Peterpan828, Qinbin Li, Shaz-hash, Steve Laskaridis, Taner Topal, William Lindskog, Yan Gao, cnxdeveloper, k3nfalt

What’s new?

  • Add experimental support for Python 3.12 (#2565)

  • Add new XGBoost examples (#2612, #2554, #2617, #2618, #2619, #2567)

    We have added a new xgboost-quickstart example alongside a new xgboost-comprehensive example that goes more in-depth.

  • Add Vertical FL example (#2598)

    We had many questions about Vertical Federated Learning using Flower, so we decided to add an simple example for it on the Titanic dataset alongside a tutorial (in the README).

  • Support custom ClientManager in start_driver() (#2292)

  • Update REST API to support create and delete nodes (#2283)

  • Update the Android SDK (#2187)

    Add gRPC request-response capability to the Android SDK.

  • Update the C++ SDK (#2537, #2528, #2523, #2522)

    Add gRPC request-response capability to the C++ SDK.

  • Make HTTPS the new default (#2591, #2636)

    Flower is moving to HTTPS by default. The new flower-server requires passing --certificates, but users can enable --insecure to use HTTP for prototyping. The same applies to flower-client, which can either use user-provided credentials or gRPC-bundled certificates to connect to an HTTPS-enabled server or requires opt-out via passing --insecure to enable insecure HTTP connections.

    For backward compatibility, start_client() and start_numpy_client() will still start in insecure mode by default. In a future release, insecure connections will require user opt-in by passing insecure=True.

  • Unify client API (#2303, #2390, #2493)

    Using the client_fn, Flower clients can interchangeably run as standalone processes (i.e. via start_client) or in simulation (i.e. via start_simulation) without requiring changes to how the client class is defined and instantiated. The to_client() function is introduced to convert a NumPyClient to a Client.

  • Add new Bulyan strategy (#1817, #1891)

    The new Bulyan strategy implements Bulyan by El Mhamdi et al., 2018

  • Add new XGB Bagging strategy (#2611)

  • Introduce WorkloadState (#2564, #2632)

  • Update Flower Baselines

  • General updates to Flower Examples (#2384, #2425, #2526, #2302, #2545)

  • General updates to Flower Baselines (#2301, #2305, #2307, #2327, #2435, #2462, #2463, #2461, #2469, #2466, #2471, #2472, #2470)

  • General updates to the simulation engine (#2331, #2447, #2448, #2294)

  • General updates to Flower SDKs (#2288, #2429, #2555, #2543, #2544, #2597, #2623)

  • General improvements (#2309, #2310, #2313, #2316, #2317, #2349, #2360, #2402, #2446, #2561, #2273, #2267, #2274, #2275, #2432, #2251, #2321, #1936, #2408, #2413, #2401, #2531, #2534, #2535, #2521, #2553, #2596)

    Flower received many improvements under the hood, too many to list here.

Incompatible changes

  • Remove support for Python 3.7 (#2280, #2299, #2304, #2306, #2355, #2356)

    Python 3.7 support was deprecated in Flower 1.5, and this release removes support. Flower now requires Python 3.8.

  • Remove experimental argument rest from start_client (#2324)

    The (still experimental) argument rest was removed from start_client and start_numpy_client. Use transport="rest" to opt into the experimental REST API instead.

v1.5.0 (2023-08-31)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Anass Anhari, Charles Beauville, Dana-Farber, Daniel J. Beutel, Daniel Nata Nugraha, Edoardo Gabrielli, Gustavo Bertoli, Heng Pan, Javier, Mahdi, Steven Hé (Sīchàng), Taner Topal, achiverram28, danielnugraha, eunchung, ruthgal

What’s new?

  • Introduce new simulation engine (#1969, #2221, #2248)

    The new simulation engine has been rewritten from the ground up, yet it remains fully backwards compatible. It offers much improved stability and memory handling, especially when working with GPUs. Simulations transparently adapt to different settings to scale simulation in CPU-only, CPU+GPU, multi-GPU, or multi-node multi-GPU environments.

    Comprehensive documentation includes a new how-to run simulations guide, new simulation-pytorch and simulation-tensorflow notebooks, and a new YouTube tutorial series.

  • Restructure Flower Docs (#1824, #1865, #1884, #1887, #1919, #1922, #1920, #1923, #1924, #1962, #2006, #2133, #2203, #2215, #2122, #2223, #2219, #2232, #2233, #2234, #2235, #2237, #2238, #2242, #2231, #2243, #2227)

    Much effort went into a completely restructured Flower docs experience. The documentation on flower.ai/docs is now divided into Flower Framework, Flower Baselines, Flower Android SDK, Flower iOS SDK, and code example projects.

  • Introduce Flower Swift SDK (#1858, #1897)

    This is the first preview release of the Flower Swift SDK. Flower support on iOS is improving, and alongside the Swift SDK and code example, there is now also an iOS quickstart tutorial.

  • Introduce Flower Android SDK (#2131)

    This is the first preview release of the Flower Kotlin SDK. Flower support on Android is improving, and alongside the Kotlin SDK and code example, there is now also an Android quickstart tutorial.

  • Introduce new end-to-end testing infrastructure (#1842, #2071, #2072, #2068, #2067, #2069, #2073, #2070, #2074, #2082, #2084, #2093, #2109, #2095, #2140, #2137, #2165)

    A new testing infrastructure ensures that new changes stay compatible with existing framework integrations or strategies.

  • Deprecate Python 3.7

    Since Python 3.7 reached its end of life (EOL) on 2023-06-27, support for Python 3.7 is now deprecated and will be removed in an upcoming release.

  • Add new FedTrimmedAvg strategy (#1769, #1853)

    The new FedTrimmedAvg strategy implements Trimmed Mean by Dong Yin, 2018.

  • Introduce start_driver (#1697)

    In addition to start_server and using the raw Driver API, there is a new start_driver function that allows for running start_server scripts as a Flower driver with only a single-line code change. Check out the mt-pytorch code example to see a working example using start_driver.

  • Add parameter aggregation to mt-pytorch code example (#1785)

    The mt-pytorch example shows how to aggregate parameters when writing a driver script. The included driver.py and server.py have been aligned to demonstrate both the low-level way and the high-level way of building server-side logic.

  • Migrate experimental REST API to Starlette (2171)

    The (experimental) REST API used to be implemented in FastAPI, but it has now been migrated to use Starlette directly.

    Please note: The REST request-response API is still experimental and will likely change significantly over time.

  • Introduce experimental gRPC request-response API (#1867, #1901)

    In addition to the existing gRPC API (based on bidirectional streaming) and the experimental REST API, there is now a new gRPC API that uses a request-response model to communicate with client nodes.

    Please note: The gRPC request-response API is still experimental and will likely change significantly over time.

  • Replace the experimental start_client(rest=True) with the new start_client(transport="rest") (#1880)

    The (experimental) start_client argument rest was deprecated in favour of a new argument transport. start_client(transport="rest") will yield the same behaviour as start_client(rest=True) did before. All code should migrate to the new argument transport. The deprecated argument rest will be removed in a future release.

  • Add a new gRPC option (#2197)

    We now start a gRPC server with the grpc.keepalive_permit_without_calls option set to 0 by default. This prevents the clients from sending keepalive pings when there is no outstanding stream.

  • Improve example notebooks (#2005)

    There’s a new 30min Federated Learning PyTorch tutorial!

  • Example updates (#1772, #1873, #1981, #1988, #1984, #1982, #2112, #2144, #2174, #2225, #2183)

    Many examples have received significant updates, including simplified advanced-tensorflow and advanced-pytorch examples, improved macOS compatibility of TensorFlow examples, and code examples for simulation. A major upgrade is that all code examples now have a requirements.txt (in addition to pyproject.toml).

  • General improvements (#1872, #1866, #1837, #1477, #2171)

    Flower received many improvements under the hood, too many to list here.

Incompatible changes

None

v1.4.0 (2023-04-21)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Alexander Viala Bellander, Charles Beauville, Chenyang Ma (Danny), Daniel J. Beutel, Edoardo, Gautam Jajoo, Iacob-Alexandru-Andrei, JDRanpariya, Jean Charle Yaacoub, Kunal Sarkhel, L. Jiang, Lennart Behme, Max Kapsecker, Michał, Nic Lane, Nikolaos Episkopos, Ragy, Saurav Maheshkar, Semo Yang, Steve Laskaridis, Steven Hé (Sīchàng), Taner Topal

What’s new?

  • Introduce support for XGBoost (FedXgbNnAvg strategy and example) (#1694, #1709, #1715, #1717, #1763, #1795)

    XGBoost is a tree-based ensemble machine learning algorithm that uses gradient boosting to improve model accuracy. We added a new FedXgbNnAvg strategy, and a code example that demonstrates the usage of this new strategy in an XGBoost project.

  • Introduce iOS SDK (preview) (#1621, #1764)

    This is a major update for anyone wanting to implement Federated Learning on iOS mobile devices. We now have a swift iOS SDK present under src/swift/flwr that will facilitate greatly the app creating process. To showcase its use, the iOS example has also been updated!

  • Introduce new “What is Federated Learning?” tutorial (#1657, #1721)

    A new entry-level tutorial in our documentation explains the basics of Fedetated Learning. It enables anyone who’s unfamiliar with Federated Learning to start their journey with Flower. Forward it to anyone who’s interested in Federated Learning!

  • Introduce new Flower Baseline: FedProx MNIST (#1513, #1680, #1681, #1679)

    This new baseline replicates the MNIST+CNN task from the paper Federated Optimization in Heterogeneous Networks (Li et al., 2018). It uses the FedProx strategy, which aims at making convergence more robust in heterogeneous settings.

  • Introduce new Flower Baseline: FedAvg FEMNIST (#1655)

    This new baseline replicates an experiment evaluating the performance of the FedAvg algorithm on the FEMNIST dataset from the paper LEAF: A Benchmark for Federated Settings (Caldas et al., 2018).

  • Introduce (experimental) REST API (#1594, #1690, #1695, #1712, #1802, #1770, #1733)

    A new REST API has been introduced as an alternative to the gRPC-based communication stack. In this initial version, the REST API only supports anonymous clients.

    Please note: The REST API is still experimental and will likely change significantly over time.

  • Improve the (experimental) Driver API (#1663, #1666, #1667, #1664, #1675, #1676, #1693, #1662, #1794)

    The Driver API is still an experimental feature, but this release introduces some major upgrades. One of the main improvements is the introduction of an SQLite database to store server state on disk (instead of in-memory). Another improvement is that tasks (instructions or results) that have been delivered will now be deleted. This greatly improves the memory efficiency of a long-running Flower server.

  • Fix spilling issues related to Ray during simulations (#1698)

    While running long simulations, ray was sometimes spilling huge amounts of data that would make the training unable to continue. This is now fixed! 🎉

  • Add new example using TabNet and Flower (#1725)

    TabNet is a powerful and flexible framework for training machine learning models on tabular data. We now have a federated example using Flower: quickstart-tabnet.

  • Add new how-to guide for monitoring simulations (#1649)

    We now have a documentation guide to help users monitor their performance during simulations.

  • Add training metrics to History object during simulations (#1696)

    The fit_metrics_aggregation_fn can be used to aggregate training metrics, but previous releases did not save the results in the History object. This is now the case!

  • General improvements (#1646, #1647, #1471, #1648, #1651, #1652, #1653, #1659, #1665, #1670, #1672, #1677, #1684, #1683, #1686, #1682, #1685, #1692, #1705, #1708, #1711, #1713, #1714, #1718, #1716, #1723, #1735, #1678, #1750, #1753, #1736, #1766, #1760, #1775, #1776, #1777, #1779, #1784, #1773, #1755, #1789, #1788, #1798, #1799, #1739, #1800, #1804, #1805)

    Flower received many improvements under the hood, too many to list here.

Incompatible changes

None

v1.3.0 (2023-02-06)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Alexander Viala Bellander, Charles Beauville, Daniel J. Beutel, JDRanpariya, Lennart Behme, Taner Topal

What’s new?

  • Add support for workload_id and group_id in Driver API (#1595)

    The (experimental) Driver API now supports a workload_id that can be used to identify which workload a task belongs to. It also supports a new group_id that can be used, for example, to indicate the current training round. Both the workload_id and group_id enable client nodes to decide whether they want to handle a task or not.

  • Make Driver API and Fleet API address configurable (#1637)

    The (experimental) long-running Flower server (Driver API and Fleet API) can now configure the server address of both Driver API (via --driver-api-address) and Fleet API (via --fleet-api-address) when starting:

    flower-server --driver-api-address "0.0.0.0:8081" --fleet-api-address "0.0.0.0:8086"

    Both IPv4 and IPv6 addresses are supported.

  • Add new example of Federated Learning using fastai and Flower (#1598)

    A new code example (quickstart-fastai) demonstrates federated learning with fastai and Flower. You can find it here: quickstart-fastai.

  • Make Android example compatible with flwr >= 1.0.0 and the latest versions of Android (#1603)

    The Android code example has received a substantial update: the project is compatible with Flower 1.0 (and later), the UI received a full refresh, and the project is updated to be compatible with newer Android tooling.

  • Add new FedProx strategy (#1619)

    This strategy is almost identical to FedAvg, but helps users replicate what is described in this paper. It essentially adds a parameter called proximal_mu to regularize the local models with respect to the global models.

  • Add new metrics to telemetry events (#1640)

    An updated event structure allows, for example, the clustering of events within the same workload.

  • Add new custom strategy tutorial section #1623

    The Flower tutorial now has a new section that covers implementing a custom strategy from scratch: Open in Colab

  • Add new custom serialization tutorial section (#1622)

    The Flower tutorial now has a new section that covers custom serialization: Open in Colab

  • General improvements (#1638, #1634, #1636, #1635, #1633, #1632, #1631, #1630, #1627, #1593, #1616, #1615, #1607, #1609, #1608, #1590, #1580, #1599, #1600, #1601, #1597, #1591, #1588, #1589, #1587, #1573, #1581, #1578, #1574, #1572, #1586)

    Flower received many improvements under the hood, too many to list here.

  • Updated documentation (#1629, #1628, #1620, #1618, #1617, #1613, #1614)

    As usual, the documentation has improved quite a bit. It is another step in our effort to make the Flower documentation the best documentation of any project. Stay tuned and as always, feel free to provide feedback!

Incompatible changes

None

v1.2.0 (2023-01-13)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Daniel J. Beutel, Edoardo, L. Jiang, Ragy, Taner Topal, dannymcy

What’s new?

  • Introduce new Flower Baseline: FedAvg MNIST (#1497, #1552)

    Over the coming weeks, we will be releasing a number of new reference implementations useful especially to FL newcomers. They will typically revisit well known papers from the literature, and be suitable for integration in your own application or for experimentation, in order to deepen your knowledge of FL in general. Today’s release is the first in this series. Read more.

  • Improve GPU support in simulations (#1555)

    The Ray-based Virtual Client Engine (start_simulation) has been updated to improve GPU support. The update includes some of the hard-earned lessons from scaling simulations in GPU cluster environments. New defaults make running GPU-based simulations substantially more robust.

  • Improve GPU support in Jupyter Notebook tutorials (#1527, #1558)

    Some users reported that Jupyter Notebooks have not always been easy to use on GPU instances. We listened and made improvements to all of our Jupyter notebooks! Check out the updated notebooks here:

  • Introduce optional telemetry (#1533, #1544, #1584)

    After a request for feedback from the community, the Flower open-source project introduces optional collection of anonymous usage metrics to make well-informed decisions to improve Flower. Doing this enables the Flower team to understand how Flower is used and what challenges users might face.

    Flower is a friendly framework for collaborative AI and data science. Staying true to this statement, Flower makes it easy to disable telemetry for users who do not want to share anonymous usage metrics. Read more..

  • Introduce (experimental) Driver API (#1520, #1525, #1545, #1546, #1550, #1551, #1567)

    Flower now has a new (experimental) Driver API which will enable fully programmable, async, and multi-tenant Federated Learning and Federated Analytics applications. Phew, that’s a lot! Going forward, the Driver API will be the abstraction that many upcoming features will be built on - and you can start building those things now, too.

    The Driver API also enables a new execution mode in which the server runs indefinitely. Multiple individual workloads can run concurrently and start and stop their execution independent of the server. This is especially useful for users who want to deploy Flower in production.

    To learn more, check out the mt-pytorch code example. We look forward to you feedback!

    Please note: The Driver API is still experimental and will likely change significantly over time.

  • Add new Federated Analytics with Pandas example (#1469, #1535)

    A new code example (quickstart-pandas) demonstrates federated analytics with Pandas and Flower. You can find it here: quickstart-pandas.

  • Add new strategies: Krum and MultiKrum (#1481)

    Edoardo, a computer science student at the Sapienza University of Rome, contributed a new Krum strategy that enables users to easily use Krum and MultiKrum in their workloads.

  • Update C++ example to be compatible with Flower v1.2.0 (#1495)

    The C++ code example has received a substantial update to make it compatible with the latest version of Flower.

  • General improvements (#1491, #1504, #1506, #1514, #1522, #1523, #1526, #1528, #1547, #1549, #1560, #1564, #1566)

    Flower received many improvements under the hood, too many to list here.

  • Updated documentation (#1494, #1496, #1500, #1503, #1505, #1524, #1518, #1519, #1515)

    As usual, the documentation has improved quite a bit. It is another step in our effort to make the Flower documentation the best documentation of any project. Stay tuned and as always, feel free to provide feedback!

    One highlight is the new first time contributor guide: if you’ve never contributed on GitHub before, this is the perfect place to start!

Incompatible changes

None

v1.1.0 (2022-10-31)

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Akis Linardos, Christopher S, Daniel J. Beutel, George, Jan Schlicht, Mohammad Fares, Pedro Porto Buarque de Gusmão, Philipp Wiesner, Rob Luke, Taner Topal, VasundharaAgarwal, danielnugraha, edogab33

What’s new?

  • Introduce Differential Privacy wrappers (preview) (#1357, #1460)

    The first (experimental) preview of pluggable Differential Privacy wrappers enables easy configuration and usage of differential privacy (DP). The pluggable DP wrappers enable framework-agnostic and strategy-agnostic usage of both client-side DP and server-side DP. Head over to the Flower docs, a new explainer goes into more detail.

  • New iOS CoreML code example (#1289)

    Flower goes iOS! A massive new code example shows how Flower clients can be built for iOS. The code example contains both Flower iOS SDK components that can be used for many tasks, and one task example running on CoreML.

  • New FedMedian strategy (#1461)

    The new FedMedian strategy implements Federated Median (FedMedian) by Yin et al., 2018.

  • Log Client exceptions in Virtual Client Engine (#1493)

    All Client exceptions happening in the VCE are now logged by default and not just exposed to the configured Strategy (via the failures argument).

  • Improve Virtual Client Engine internals (#1401, #1453)

    Some internals of the Virtual Client Engine have been revamped. The VCE now uses Ray 2.0 under the hood, the value type of the client_resources dictionary changed to float to allow fractions of resources to be allocated.

  • Support optional Client/NumPyClient methods in Virtual Client Engine

    The Virtual Client Engine now has full support for optional Client (and NumPyClient) methods.

  • Provide type information to packages using flwr (#1377)

    The package flwr is now bundled with a py.typed file indicating that the package is typed. This enables typing support for projects or packages that use flwr by enabling them to improve their code using static type checkers like mypy.

  • Updated code example (#1344, #1347)

    The code examples covering scikit-learn and PyTorch Lightning have been updated to work with the latest version of Flower.

  • Updated documentation (#1355, #1379, #1380, #1381, #1332, #1391, #1403, #1364, #1409, #1419, #1444, #1448, #1417, #1449, #1465, #1467)

    There have been so many documentation updates that it doesn’t even make sense to list them individually.

  • Restructured documentation (#1387)

    The documentation has been restructured to make it easier to navigate. This is just the first step in a larger effort to make the Flower documentation the best documentation of any project ever. Stay tuned!

  • Open in Colab button (#1389)

    The four parts of the Flower Federated Learning Tutorial now come with a new Open in Colab button. No need to install anything on your local machine, you can now use and learn about Flower in your browser, it’s only a single click away.

  • Improved tutorial (#1468, #1470, #1472, #1473, #1474, #1475)

    The Flower Federated Learning Tutorial has two brand-new parts covering custom strategies (still WIP) and the distinction between Client and NumPyClient. The existing parts one and two have also been improved (many small changes and fixes).

Incompatible changes

None

v1.0.0 (2022-07-28)

Highlights

  • Stable Virtual Client Engine (accessible via start_simulation)

  • All Client/NumPyClient methods are now optional

  • Configurable get_parameters

  • Tons of small API cleanups resulting in a more coherent developer experience

Thanks to our contributors

We would like to give our special thanks to all the contributors who made Flower 1.0 possible (in reverse GitHub Contributors order):

@rtaiello, @g-pichler, @rob-luke, @andreea-zaharia, @kinshukdua, @nfnt, @tatiana-s, @TParcollet, @vballoli, @negedng, @RISHIKESHAVAN, @hei411, @SebastianSpeitel, @AmitChaulwar, @Rubiel1, @FANTOME-PAN, @Rono-BC, @lbhm, @sishtiaq, @remde, @Jueun-Park, @architjen, @PratikGarai, @mrinaald, @zliel, @MeiruiJiang, @sancarlim, @gubertoli, @Vingt100, @MakGulati, @cozek, @jafermarq, @sisco0, @akhilmathurs, @CanTuerk, @mariaboerner1987, @pedropgusmao, @tanertopal, @danieljanes.

Incompatible changes

  • All arguments must be passed as keyword arguments (#1338)

    Pass all arguments as keyword arguments, positional arguments are not longer supported. Code that uses positional arguments (e.g., start_client("127.0.0.1:8080", FlowerClient())) must add the keyword for each positional argument (e.g., start_client(server_address="127.0.0.1:8080", client=FlowerClient())).

  • Introduce configuration object ServerConfig in start_server and start_simulation (#1317)

    Instead of a config dictionary {"num_rounds": 3, "round_timeout": 600.0}, start_server and start_simulation now expect a configuration object of type flwr.server.ServerConfig. ServerConfig takes the same arguments that as the previous config dict, but it makes writing type-safe code easier and the default parameters values more transparent.

  • Enhance Strategy evaluation API for clarity and consistency (#1334)

    The following built-in strategy parameters were renamed to improve readability and consistency with other API’s:

    • fraction_eval –> fraction_evaluate

    • min_eval_clients –> min_evaluate_clients

    • eval_fn –> evaluate_fn

    The Strategy method evaluate now receives the current round of federated learning/evaluation as the first parameter.

    The evaluate_fn passed to built-in strategies like FedAvg now takes three parameters: (1) The current round of federated learning/evaluation (server_round), (2) the model parameters to evaluate (parameters), and (3) a config dictionary (config).

  • Update default arguments of built-in strategies (#1278)

    All built-in strategies now use fraction_fit=1.0 and fraction_evaluate=1.0, which means they select all currently available clients for training and evaluation. Projects that relied on the previous default values can get the previous behaviour by initializing the strategy in the following way:

    strategy = FedAvg(fraction_fit=0.1, fraction_evaluate=0.1)

  • Rename rnd to server_round (#1321)

    Several Flower methods and functions (evaluate_fn, configure_fit, aggregate_fit, configure_evaluate, aggregate_evaluate) receive the current round of federated learning/evaluation as their first parameter. To improve reaability and avoid confusion with random, this parameter has been renamed from rnd to server_round.

  • Move flwr.dataset to flwr_baselines (#1273)

    The experimental package flwr.dataset was migrated to Flower Baselines.

  • Remove experimental strategies (#1280)

    Remove unmaintained experimental strategies (FastAndSlow, FedFSv0, FedFSv1).

  • Rename Weights to NDArrays (#1296)

    flwr.common.Weights was renamed to flwr.common.NDArrays to better capture what this type is all about.

  • Remove antiquated force_final_distributed_eval from start_server (#1315)

    The start_server parameter force_final_distributed_eval has long been a historic artefact, in this release it is finally gone for good.

  • Make get_parameters configurable (#1242)

    The get_parameters method now accepts a configuration dictionary, just like get_properties, fit, and evaluate.

  • Update start_simulation to align with start_server (#1281)

    The start_simulation function now accepts a configuration dictionary config instead of the num_rounds integer. This improves the consistency between start_simulation and start_server and makes transitioning between the two easier. Additionally, start_simulation now accepts a full Server instance. This enables users to heavily customize the execution of eperiments and opens the door to running, for example, async FL using the Virtual Client Engine.

What’s new?

  • Support Python 3.10 (#1320)

    The previous Flower release introduced experimental support for Python 3.10, this release declares Python 3.10 support as stable.

  • Make all Client and NumPyClient methods optional (#1260, #1277)

    The Client/NumPyClient methods get_properties, get_parameters, fit, and evaluate are all optional. This enables writing clients that implement, for example, only fit, but no other method. No need to implement evaluate when using centralized evaluation!

    Similar to start_server, start_simulation now accepts a full Server instance. This enables users to heavily customize the execution of eperiments and opens the door to running, for example, async FL using the Virtual Client Engine.

  • Update code examples (#1291, #1286, #1282)

    Many code examples received small or even large maintenance updates, among them are

    • scikit-learn

    • simulation_pytorch

    • quickstart_pytorch

    • quickstart_simulation

    • quickstart_tensorflow

    • advanced_tensorflow

  • Remove the obsolete simulation example (#1328)

    Removes the obsolete simulation example and renames quickstart_simulation to simulation_tensorflow so it fits withs the naming of simulation_pytorch

  • Update documentation (#1223, #1209, #1251, #1257, #1267, #1268, #1300, #1304, #1305, #1307)

    One substantial documentation update fixes multiple smaller rendering issues, makes titles more succinct to improve navigation, removes a deprecated library, updates documentation dependencies, includes the flwr.common module in the API reference, includes support for markdown-based documentation, migrates the changelog from .rst to .md, and fixes a number of smaller details!

  • Minor updates

v0.19.0 (2022-05-18)

What’s new?

  • Flower Baselines (preview): FedOpt, FedBN, FedAvgM (#919, #1127, #914)

    The first preview release of Flower Baselines has arrived! We’re kickstarting Flower Baselines with implementations of FedOpt (FedYogi, FedAdam, FedAdagrad), FedBN, and FedAvgM. Check the documentation on how to use Flower Baselines. With this first preview release we’re also inviting the community to contribute their own baselines.

  • C++ client SDK (preview) and code example (#1111)

    Preview support for Flower clients written in C++. The C++ preview includes a Flower client SDK and a quickstart code example that demonstrates a simple C++ client using the SDK.

  • Add experimental support for Python 3.10 and Python 3.11 (#1135)

    Python 3.10 is the latest stable release of Python and Python 3.11 is due to be released in October. This Flower release adds experimental support for both Python versions.

  • Aggregate custom metrics through user-provided functions (#1144)

    Custom metrics (e.g., accuracy) can now be aggregated without having to customize the strategy. Built-in strategies support two new arguments, fit_metrics_aggregation_fn and evaluate_metrics_aggregation_fn, that allow passing custom metric aggregation functions.

  • User-configurable round timeout (#1162)

    A new configuration value allows the round timeout to be set for start_server and start_simulation. If the config dictionary contains a round_timeout key (with a float value in seconds), the server will wait at least round_timeout seconds before it closes the connection.

  • Enable both federated evaluation and centralized evaluation to be used at the same time in all built-in strategies (#1091)

    Built-in strategies can now perform both federated evaluation (i.e., client-side) and centralized evaluation (i.e., server-side) in the same round. Federated evaluation can be disabled by setting fraction_eval to 0.0.

  • Two new Jupyter Notebook tutorials (#1141)

    Two Jupyter Notebook tutorials (compatible with Google Colab) explain basic and intermediate Flower features:

    An Introduction to Federated Learning: Open in Colab

    Using Strategies in Federated Learning: Open in Colab

  • New FedAvgM strategy (Federated Averaging with Server Momentum) (#1076)

    The new FedAvgM strategy implements Federated Averaging with Server Momentum [Hsu et al., 2019].

  • New advanced PyTorch code example (#1007)

    A new code example (advanced_pytorch) demonstrates advanced Flower concepts with PyTorch.

  • New JAX code example (#906, #1143)

    A new code example (jax_from_centralized_to_federated) shows federated learning with JAX and Flower.

  • Minor updates

    • New option to keep Ray running if Ray was already initialized in start_simulation (#1177)

    • Add support for custom ClientManager as a start_simulation parameter (#1171)

    • New documentation for implementing strategies (#1097, #1175)

    • New mobile-friendly documentation theme (#1174)

    • Limit version range for (optional) ray dependency to include only compatible releases (>=1.9.2,<1.12.0) (#1205)

Incompatible changes

  • Remove deprecated DefaultStrategy strategy (#1142)

    Removes the deprecated DefaultStrategy strategy, along with deprecated support for the eval_fn accuracy return value and passing initial parameters as NumPy ndarrays.

  • Remove deprecated support for Python 3.6 (#871)

  • Remove deprecated KerasClient (#857)

  • Remove deprecated no-op extra installs (#973)

  • Remove deprecated proto fields from FitRes and EvaluateRes (#870)

  • Remove deprecated QffedAvg strategy (replaced by QFedAvg) (#1107)

v0.18.0 (2022-02-28)

What’s new?

  • Improved Virtual Client Engine compatibility with Jupyter Notebook / Google Colab (#866, #872, #1036)

    Simulations (using the Virtual Client Engine through start_simulation) now work more smoothly on Jupyter Notebooks (incl. Google Colab) after installing Flower with the simulation extra (pip install 'flwr[simulation]').

  • New Jupyter Notebook code example (#833)

    A new code example (quickstart_simulation) demonstrates Flower simulations using the Virtual Client Engine through Jupyter Notebook (incl. Google Colab).

  • Client properties (feature preview) (#795)

    Clients can implement a new method get_properties to enable server-side strategies to query client properties.

  • Experimental Android support with TFLite (#865)

    Android support has finally arrived in main! Flower is both client-agnostic and framework-agnostic by design. One can integrate arbitrary client platforms and with this release, using Flower on Android has become a lot easier.

    The example uses TFLite on the client side, along with a new FedAvgAndroid strategy. The Android client and FedAvgAndroid are still experimental, but they are a first step towards a fully-fledged Android SDK and a unified FedAvg implementation that integrated the new functionality from FedAvgAndroid.

  • Make gRPC keepalive time user-configurable and decrease default keepalive time (#1069)

    The default gRPC keepalive time has been reduced to increase the compatibility of Flower with more cloud environments (for example, Microsoft Azure). Users can configure the keepalive time to customize the gRPC stack based on specific requirements.

  • New differential privacy example using Opacus and PyTorch (#805)

    A new code example (opacus) demonstrates differentially-private federated learning with Opacus, PyTorch, and Flower.

  • New Hugging Face Transformers code example (#863)

    A new code example (quickstart_huggingface) demonstrates usage of Hugging Face Transformers with Flower.

  • New MLCube code example (#779, #1034, #1065, #1090)

    A new code example (quickstart_mlcube) demonstrates usage of MLCube with Flower.

  • SSL-enabled server and client (#842, #844, #845, #847, #993, #994)

    SSL enables secure encrypted connections between clients and servers. This release open-sources the Flower secure gRPC implementation to make encrypted communication channels accessible to all Flower users. The advanced_tensorflow code example now uses secure gRPC connection.

  • Updated FedAdam and FedYogi strategies (#885, #895)

    FedAdam and FedAdam match the latest version of the Adaptive Federated Optimization paper.

  • Initialize start_simulation with a list of client IDs (#860)

    start_simulation can now be called with a list of client IDs (clients_ids, type: List[str]). Those IDs will be passed to the client_fn whenever a client needs to be initialized, which can make it easier to load data partitions that are not accessible through int identifiers.

  • Minor updates

    • Update num_examples calculation in PyTorch code examples in (#909)

    • Expose Flower version through flwr.__version__ (#952)

    • start_server in app.py now returns a History object containing metrics from training (#974)

    • Make max_workers (used by ThreadPoolExecutor) configurable (#978)

    • Increase sleep time after server start to three seconds in all code examples (#1086)

    • Added a new FAQ section to the documentation (#948)

    • And many more under-the-hood changes, library updates, documentation changes, and tooling improvements!

Incompatible changes

  • Removed flwr_example and flwr_experimental from release build (#869)

    The packages flwr_example and flwr_experimental have been deprecated since Flower 0.12.0 and they are not longer included in Flower release builds. The associated extras (baseline, examples-pytorch, examples-tensorflow, http-logger, ops) are now no-op and will be removed in an upcoming release.

v0.17.0 (2021-09-24)

What’s new?

  • Experimental virtual client engine (#781 #790)

    One of Flower’s goals is to enable research at scale. This release enables a first (experimental) peek at a major new feature, codenamed the virtual client engine. Virtual clients enable simulations that scale to a (very) large number of clients on a single machine or compute cluster. The easiest way to test the new functionality is to look at the two new code examples called quickstart_simulation and simulation_pytorch.

    The feature is still experimental, so there’s no stability guarantee for the API. It’s also not quite ready for prime time and comes with a few known caveats. However, those who are curious are encouraged to try it out and share their thoughts.

  • New built-in strategies (#828 #822)

    • FedYogi - Federated learning strategy using Yogi on server-side. Implementation based on https://arxiv.org/abs/2003.00295

    • FedAdam - Federated learning strategy using Adam on server-side. Implementation based on https://arxiv.org/abs/2003.00295

  • New PyTorch Lightning code example (#617)

  • New Variational Auto-Encoder code example (#752)

  • New scikit-learn code example (#748)

  • New experimental TensorBoard strategy (#789)

  • Minor updates

    • Improved advanced TensorFlow code example (#769)

    • Warning when min_available_clients is misconfigured (#830)

    • Improved gRPC server docs (#841)

    • Improved error message in NumPyClient (#851)

    • Improved PyTorch quickstart code example (#852)

Incompatible changes

  • Disabled final distributed evaluation (#800)

    Prior behaviour was to perform a final round of distributed evaluation on all connected clients, which is often not required (e.g., when using server-side evaluation). The prior behaviour can be enabled by passing force_final_distributed_eval=True to start_server.

  • Renamed q-FedAvg strategy (#802)

    The strategy named QffedAvg was renamed to QFedAvg to better reflect the notation given in the original paper (q-FFL is the optimization objective, q-FedAvg is the proposed solver). Note the original (now deprecated) QffedAvg class is still available for compatibility reasons (it will be removed in a future release).

  • Deprecated and renamed code example simulation_pytorch to simulation_pytorch_legacy (#791)

    This example has been replaced by a new example. The new example is based on the experimental virtual client engine, which will become the new default way of doing most types of large-scale simulations in Flower. The existing example was kept for reference purposes, but it might be removed in the future.

v0.16.0 (2021-05-11)

What’s new?

  • New built-in strategies (#549)

    • (abstract) FedOpt

    • FedAdagrad

  • Migration warnings for deprecated functionality (#690)

    Earlier versions of Flower were often migrated to new APIs, while maintaining compatibility with legacy APIs. This release introduces detailed warning messages if usage of deprecated APIs is detected. The new warning messages often provide details on how to migrate to more recent APIs, thus easing the transition from one release to another.

  • Improved docs and docstrings (#691 #692 #713)

  • MXNet example and documentation

  • FedBN implementation in example PyTorch: From Centralized To Federated (#696 #702 #705)

Incompatible changes

  • Custom metrics for server and strategies (#717)

    The Flower server is now fully task-agnostic, all remaining instances of task-specific metrics (such as accuracy) have been replaced by custom metrics dictionaries. Flower 0.15 introduced the capability to pass a dictionary containing custom metrics from client to server. As of this release, custom metrics replace task-specific metrics on the server.

    Custom metric dictionaries are now used in two user-facing APIs: they are returned from Strategy methods aggregate_fit/aggregate_evaluate and they enable evaluation functions passed to built-in strategies (via eval_fn) to return more than two evaluation metrics. Strategies can even return aggregated metrics dictionaries for the server to keep track of.

    Strategy implementations should migrate their aggregate_fit and aggregate_evaluate methods to the new return type (e.g., by simply returning an empty {}), server-side evaluation functions should migrate from return loss, accuracy to return loss, {"accuracy": accuracy}.

    Flower 0.15-style return types are deprecated (but still supported), compatibility will be removed in a future release.

    Deprecated flwr.server.Server.evaluate, use flwr.server.Server.evaluate_round instead

  • Serialization-agnostic server (#721)

    The Flower server is now fully serialization-agnostic. Prior usage of class Weights (which represents parameters as deserialized NumPy ndarrays) was replaced by class Parameters (e.g., in Strategy). Parameters objects are fully serialization-agnostic and represents parameters as byte arrays, the tensor_type attributes indicates how these byte arrays should be interpreted (e.g., for serialization/deserialization).

    Built-in strategies implement this approach by handling serialization and deserialization to/from Weights internally. Custom/3rd-party Strategy implementations should update to the slightly changed Strategy method definitions. Strategy authors can consult PR #721 to see how strategies can easily migrate to the new format.

v0.15.0 (2021-03-12)

What’s new?

  • Server-side parameter initialization (#658)

    Model parameters can now be initialized on the server-side. Server-side parameter initialization works via a new Strategy method called initialize_parameters.

    Built-in strategies support a new constructor argument called initial_parameters to set the initial parameters. Built-in strategies will provide these initial parameters to the server on startup and then delete them to free the memory afterwards.

    # Create model
model = tf.keras.applications.EfficientNetB0(
    input_shape=(32, 32, 3), weights=None, classes=10
)
model.compile("adam", "sparse_categorical_crossentropy", metrics=["accuracy"])

# Create strategy and initialize parameters on the server-side
strategy = fl.server.strategy.FedAvg(
    # ... (other constructor arguments)
    initial_parameters=model.get_weights(),
)

# Start Flower server with the strategy
fl.server.start_server("[::]:8080", config={"num_rounds": 3}, strategy=strategy)

    If no initial parameters are provided to the strategy, the server will continue to use the current behaviour (namely, it will ask one of the connected clients for its parameters and use these as the initial global parameters).

Deprecations

  • Deprecate flwr.server.strategy.DefaultStrategy (migrate to flwr.server.strategy.FedAvg, which is equivalent)

v0.14.0 (2021-02-18)

What’s new?

  • Generalized Client.fit and Client.evaluate return values (#610 #572 #633)

    Clients can now return an additional dictionary mapping str keys to values of the following types: bool, bytes, float, int, str. This means one can return almost arbitrary values from fit/evaluate and make use of them on the server side!

    This improvement also allowed for more consistent return types between fit and evaluate: evaluate should now return a tuple (float, int, dict) representing the loss, number of examples, and a dictionary holding arbitrary problem-specific values like accuracy.

    In case you wondered: this feature is compatible with existing projects, the additional dictionary return value is optional. New code should however migrate to the new return types to be compatible with upcoming Flower releases (fit: List[np.ndarray], int, Dict[str, Scalar], evaluate: float, int, Dict[str, Scalar]). See the example below for details.

    Code example: note the additional dictionary return values in both FlwrClient.fit and FlwrClient.evaluate:

    class FlwrClient(fl.client.NumPyClient):
    def fit(self, parameters, config):
        net.set_parameters(parameters)
        train_loss = train(net, trainloader)
        return net.get_weights(), len(trainloader), {"train_loss": train_loss}

    def evaluate(self, parameters, config):
        net.set_parameters(parameters)
        loss, accuracy, custom_metric = test(net, testloader)
        return loss, len(testloader), {"accuracy": accuracy, "custom_metric": custom_metric}

  • Generalized config argument in Client.fit and Client.evaluate (#595)

    The config argument used to be of type Dict[str, str], which means that dictionary values were expected to be strings. The new release generalizes this to enable values of the following types: bool, bytes, float, int, str.

    This means one can now pass almost arbitrary values to fit/evaluate using the config dictionary. Yay, no more str(epochs) on the server-side and int(config["epochs"]) on the client side!

    Code example: note that the config dictionary now contains non-str values in both Client.fit and Client.evaluate:

    class FlwrClient(fl.client.NumPyClient):
    def fit(self, parameters, config):
        net.set_parameters(parameters)
        epochs: int = config["epochs"]
        train_loss = train(net, trainloader, epochs)
        return net.get_weights(), len(trainloader), {"train_loss": train_loss}

    def evaluate(self, parameters, config):
        net.set_parameters(parameters)
        batch_size: int = config["batch_size"]
        loss, accuracy = test(net, testloader, batch_size)
        return loss, len(testloader), {"accuracy": accuracy}

v0.13.0 (2021-01-08)

What’s new?

  • New example: PyTorch From Centralized To Federated (#531)

  • Improved documentation

    • New documentation theme (#551)

    • New API reference (#554)

    • Updated examples documentation (#534)

    • Removed obsolete documentation (#548)

Bugfix:

  • Server.fit does not disconnect clients when finished, disconnecting the clients is now handled in flwr.server.start_server (#553 #540).

v0.12.0 (2020-12-07)

Important changes:

  • Added an example for embedded devices (#507)

  • Added a new NumPyClient (in addition to the existing KerasClient) (#504 #508)

  • Deprecated flwr_example package and started to migrate examples into the top-level examples directory (#494 #512)

v0.11.0 (2020-11-30)

Incompatible changes:

  • Renamed strategy methods (#486) to unify the naming of Flower’s public APIs. Other public methods/functions (e.g., every method in Client, but also Strategy.evaluate) do not use the on_ prefix, which is why we’re removing it from the four methods in Strategy. To migrate rename the following Strategy methods accordingly:

    • on_configure_evaluate => configure_evaluate

    • on_aggregate_evaluate => aggregate_evaluate

    • on_configure_fit => configure_fit

    • on_aggregate_fit => aggregate_fit

Important changes:

  • Deprecated DefaultStrategy (#479). To migrate use FedAvg instead.

  • Simplified examples and baselines (#484).

  • Removed presently unused on_conclude_round from strategy interface (#483).

  • Set minimal Python version to 3.6.1 instead of 3.6.9 (#471).

  • Improved Strategy docstrings (#470).