Flower 1.13.0

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](https:...

Flower 1.12.0

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](https:/...

Flower 1.11.1

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

Flower 1.11.0

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](http...

Flower 1.10.0

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

• Add 🇰🇷 Korean translations (#3680)

• Update translations (#3586, #3679, #3570, [#3681](https://github.com/adap/flower/pu...

Flower 1.9.0

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?

• Introduce built-in authentication (preview) (#2946, #3388, #2948, #2917, #3386, #3308, #3001, #3409, #2999, #2979, #3389, #3503, #3366, #3357)

  Flower 1.9 introduces the first build-in version of client node authentication. In previous releases, users often wrote glue code to connect Flower to external authentication systems. With this release, the SuperLink can authenticate SuperNodes using a built-in authentication system. A new how-to guide and a new code example help you to get started.

  This is the first preview release of the Flower-native authentication system. Many additional features are on the roadmap for upcoming Flower releases - stay tuned.

• Introduce end-to-end Docker support (#3483, #3266, #3390, #3283, #3285, #3391, #3403, #3458, #3533, #3453, #3486, #3290)

  Full Flower Next Docker support is here! With the release of Flower 1.9, Flower provides stable Docker images for the Flower SuperLink, the Flower SuperNode, and the Flower ServerApp. This set of images enables you to run all Flower components in Docker. Check out the new how-to guide to get stated.

• Re-architect Flower Next simulation engine (#3307, #3355, #3272, #3273, #3417, #3281, #3343, #3326)

  Flower Next simulations now use a new in-memory Driver that improves the reliability of simulations, especially in notebook environments. This is a significant step towards a complete overhaul of the Flower Next simulation architecture.

• Upgrade simulation engine (#3354, #3378, #3262, #3435, #3501, #3482, #3494)

  The Flower Next simulation engine comes with improved and configurable logging. The Ray-based simulation backend in Flower 1.9 was updated to use Ray 2.10.

• Introduce FedPFT baseline (#3268)

  FedPFT allows you to perform one-shot Federated Learning by leveraging widely available foundational models, dramatically reducing communication costs while delivering high performing models. This is work led by Mahdi Beitollahi from Huawei Noah's Ark Lab (Montreal, Canada). Read all the details in their paper: "Parametric Feature Transfer: One-shot Federated Learning with Foundation Models" (arxiv)

• Launch additional flwr new templates for Apple MLX, Hugging Face Transformers, scikit-learn and TensorFlow (#3291, #3139, #3284, #3251, #3376, #3287)

  The flwr CLI's flwr new command is starting to become everone's favorite way of creating new Flower projects. This release introduces additional flwr new templates for Apple MLX, Hugging Face Transformers, scikit-learn and TensorFlow. In addition to that, existing templates also received updates.

• Refine RecordSet API (#3209, #3331, #3334, #3335, #3375, #3368)

  RecordSet is part of the Flower Next low-level API preview release. In Flower 1.9, RecordSet received a number of usability improvements that make it easier to build RecordSet-based ServerApps and ClientApps.

• Beautify logging (#3379, #3430, #3461, #3360, #3433)

  Logs received a substantial update. Not only are logs now much nicer to look at, but they are also more configurable.

• Improve reliability (#3564, #3561, #3566, #3462, #3225, #3514, #3535, #3372)

  Flower 1.9 includes reliability improvements across many parts of the system. One example is a much improved SuperNode shutdown procedure.

• Update Swift and C++ SDKs (#3321, #2763)

  In the C++ SDK, communication-related code is now separate from main client logic. A new abstract class Communicator has been introduced alongside a gRPC implementation of it.

• Improve testing, tooling and CI/CD infrastructure (#3294, #3282, #3311, #2878, #3333, #3255, #3349, #3400, #3401, #3399, #3346, #3398, #3397, #3347, #3502, #3387, #3542, #3396, #3496, #3465, #3473, #3484, #3521, #3363, #3497, #3464, #3495, #3478, #3271)

  As always, the Flower tooling, testing, and CI/CD infrastructure has received many updates.

• Improve documentation (#3530, #3539, #3425, #3520, #3286, #3516, #3523, #3545, #3498, #3439, #3440, #3382, #3559, #3432, #3278, #3371, #3519, #3267, #3204, #3274)

  As always, the Fl...

Flower 1.8.0

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, [#316...

Flower 1.7.0

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?

• Introduce stateful clients (experimental) (#2770, #2686, #2696, #2643, #2769)

  Subclasses of Client and NumPyClient can now store local state that remains on the client. Let's start with the highlight first: this new feature is compatible with both simulated clients (via start_simulation) and networked clients (via start_client). It's also the first preview of new abstractions like Context and RecordSet. Clients can access state of type RecordSet via state: RecordSet = self.context.state. Changes to this RecordSet are preserved across different rounds of execution to enable stateful computations in a unified way across simulation and deployment.

• Improve performance (#2293)

  Flower is faster than ever. All FedAvg-derived strategies now use in-place aggregation to reduce memory consumption. The Flower client serialization/deserialization has been rewritten from the ground up, which results in significant speedups, especially when the client-side training time is short.

• Support Federated Learning with Apple MLX and Flower (#2693)

  Flower has official support for federated learning using Appple MLX via the new quickstart-mlx code example.

• Introduce new XGBoost cyclic strategy (#2666, #2668)

  A new strategy called FedXgbCyclic supports a client-by-client style of training (often called cyclic). The xgboost-comprehensive code example shows how to use it in a full project. In addition to that, xgboost-comprehensive now also supports simulation mode. With this, Flower offers best-in-class XGBoost support.

• Support Python 3.11 (#2394)

  Framework tests now run on Python 3.8, 3.9, 3.10, and 3.11. This will ensure better support for users using more recent Python versions.

• Update gRPC and ProtoBuf dependencies (#2814)

  The grpcio and protobuf dependencies were updated to their latest versions for improved security and performance.

• Introduce Docker image for Flower server (#2700, #2688, #2705, #2695, #2747, #2746, #2680, #2682, #2701)

  The Flower server can now be run using an official Docker image. A new how-to guide explains how to run Flower using Docker. An official Flower client Docker image will follow.

• Introduce flower-via-docker-compose example (#2626)

• Introduce quickstart-sklearn-tabular example (#2719)

• Introduce custom-metrics example (#1958)

• Update code examples to use Flower Datasets (#2450, #2456, #2318, #2712)

  Several code examples were updated to use Flower Datasets.

• General updates to Flower Examples (#2381, #2805, #2782, #2806, #2829, #2825, #2816, #2726, #2659, #2655)

  Many Flower code examples received substantial updates.

• Update Flower Baselines

  • HFedXGBoost (#2226, #2771)
  • FedVSSL (#2412)
  • FedNova (#2179)
  • HeteroFL (#2439)
  • FedAvgM (#2246)
  • FedPara (#2722)

• Improve documentation (#2674, #2480, #2826, #2727, #2761, #2900)

• Improved testing and development infrastructure (#2797, #2676, #2644, #2656, #2848, #2675, #2735, #2767, #2732, #2744, #2681, #2699, #2745, #2734, #2731, #2652, #2720, #2721, #2717, #2864, #2694, #2709, #2658, #2796, #2692, #2657, #2813, #2661, #2398)

  The Flower testing and development infrastructure has received substantial updates. This makes Flower 1.7 the most tested release ever.

• Update dependencies (#2753, #2651, #2739, #2837, #2788, #2811, #2774, #2790, #2751, #2850, #2812, #2872, #2736, #2756, #2857, #2757, #2810, #2740, #2789)

• General improvements (#2803, #2847, #2877, #2690, #2889, #2874, #2819, #2689, #2457, #2870, #2669, #2876, #2885, #2858, #2867, #2351, #2886, #2860, #2828, #2869, #2875, #2733, #2488, #2646, #2879, #2821, [#2855](https://...

Flower 1.6.0

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)

• Update Flower Baselines

  • FedProx (#2210, #2286, #2509)

  • Baselines Docs (#2290, #2400)

  • FedMLB (#2340, #2507)

  • TAMUNA (#2254, #2508)

  • FedMeta #2438

  • FjORD #2431

  • MOON #2421

  • DepthFL #2295

  • FedPer #2266

  • FedWav2vec #2551

  • niid-Bench #2428

  • FedBN (#2608, #2615)

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

Flower 1.5.0

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):

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

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.dev/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, #1884, #1837, #1477, #2171)

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

Incompatible changes

None