Reference Deployment at a Glance

2.1 Reference deployment assumptions

This guide focuses on cross-silo Horizontal Federated Learning (HFL) as the primary reference deployment pattern, where participating organisations hold datasets with similar features or schemas but different records. Basic Vertical FL workflows, including secure entity alignment for identifying overlapping entities across participants, are also covered. Full production implementation of Federated Transfer Learning is outside the main quickstart path and may require additional framework support and custom engineering.

The reference deployment was developed and tested in GovTech’s Government Commercial Cloud (GCC) environment. While examples and implementation references are drawn from this environment, the architectural patterns, governance considerations, operational practices, and design decisions are intended to be broadly applicable across cloud deployment environments. Where services specific to the cloud service provider are used, these will be highlighted in the text.

Area	Reference assumption
Deployment pattern	Cross-silo FL, where each participant is a known organisation or controlled environment.
Cloud pattern	Reference deployment tested in GovTech’s GCC environment (AWS-based). Equivalent cloud environments may be used, subject to organisational requirements.
Reference framework	Flower for federation, PyTorch for model training, and Opacus for DP-SGD. See Appendix A for framework alternatives.
Security baseline	mTLS for participant authentication, signed container images, restricted network paths, least privilege, and audit logging.
Privacy controls	Secure aggregation and differential privacy are configurable controls, with stronger expectations for cross-organisation personal-data use cases.
Data mode	The first run should use synthetic data. Production data should only be used after data protection, security, and governance reviews are complete.
Production posture	Production deployment requires runbooks, monitoring, backup and recovery, security hardening, model lifecycle controls, and sponsor sign-off.

The reference path is most directly applicable to structured or tabular cross-silo HFL, but the same deployment pattern may be adapted to image or text models where participating teams have the required ML and infrastructure capability.

2.2 What you will deploy

The reference deployment consists of one FL coordinator and two or more FL client nodes. Each client node sits within a participating organisation’s environment and trains locally on that organisation’s data. The coordinator manages training rounds, receives model updates, aggregates them, and returns the updated global model.

Raw training data does not leave the participant environment. Depending on the privacy configuration, model updates may be protected using secure aggregation so that the coordinator can only recover the aggregate update, not each participant’s individual update. Differential privacy may also be applied at the client before updates are sent.

Figure 1. Reference deployment architecture. This shows one realisation of the platform-neutral architecture, including the FL server, clients, PKI, secrets, logging, and optional inference components.

2.3 Core components

Component	Role in the deployment
FL coordinator	Selects participants for each round, distributes the current model, receives model updates, aggregates updates, and stores model checkpoints.
FL client node	Runs inside each participant environment, loads local data, trains locally, applies local privacy controls where configured, and returns model updates.
Reference repository	Contains the server application, client application, task definitions, infrastructure templates, scripts, and documentation needed to run the guide.
Certificate and identity layer	Authenticates the coordinator and each client, typically using mTLS and per-client certificates.
Privacy controls	Secure aggregation, DP-SGD, and privacy testing reduce the risk that model updates or trained models reveal sensitive information.
Audit and monitoring layer	Records training events, participant activity, metrics, alerts, model artefacts, and evidence needed for review.
Operator runbooks	Document deployment, monitoring, incident response, rollback, disaster recovery, certificate rotation, and participant onboarding procedures.

2.4 Reference repository and implementation artefacts

This guide is paired with a reference implementation repository.

The guide and repository should be read together. The guide explains the reference deployment pattern, key design decisions, readiness checks, governance considerations, and operating model. The repository provides the runnable implementation and the artefacts that technical users need to execute, adapt, and operate the deployment.

Resource	Primary purpose
Deployment guide	Explains what the system is, why each step matters, what decisions need to be made, and what evidence reviewers should look for.
Reference repository	Provides the runnable implementation, commands, configuration files, infrastructure templates, validation scripts, templates, and runbooks.
Operational guidance boxes	Highlight production and operator considerations in the guide, while pointing to repository artefacts for command-level procedures.

As a rule, stable guidance should remain in this document, while implementation details that change with the code should be maintained in the repository. This includes exact commands, environment variables, configuration schemas, infrastructure modules, certificate procedures, validation scripts, troubleshooting runbooks, and example manifests.

The repository should be organised to help readers move from a local quickstart to a cloud pilot without searching across unrelated folders. The structure below is illustrative and should be updated to match the final repository before publication.

fl-reference/
├── serverapp/    # Coordinator logic and aggregation strategies
├── clientapp/    # Client-side local training and evaluation
├── tasks/        # smoke.yaml and task-specific configs
├── privacy/      # DP budget tooling and privacy tests
├── secagg/       # Secure aggregation integration or adapters
├── psi/          # Optional secure entity alignment for VFL
├── infra/        # Infrastructure templates
│   ├── cdk/
│   └── terraform/
├── scripts/      # Preflight, deployment, validation, diagnostics
├── runbooks/     # Operator runbooks and troubleshooting guides
├── docs/         # Extended technical documentation
└── docker/       # Container build, signing, and scanning configuration