How flairOS works

flairOS turns every installation of your product into a place your ML model trains and serves — without any of the data those installations hold ever leaving them.

If you have one product deployed at many sites — hospitals, factories, branch offices, customer servers — you have a training-data problem you cannot solve by centralizing: the data is sensitive, regulated, or contractually pinned to where it lives. flairOS trains where the data is and moves only the model.

The journey, end to end

1. Upload your model. A wizard with static code analysis maps your training and evaluation entry points to the platform's thin contract. Your code is analyzed, never rewritten, and never executed during analysis. scikit-learn and PyTorch are supported today, on tabular and imaging data.

2. Dry-run in a sandbox. Before anything reaches a real site, the platform builds your model into its serving image and proves one full training round in an isolated sandbox. Only a green dry run can be deployed.

3. Create a federation, enroll your sites. A federation trains one model across one fleet. For each installation you issue an enrollment key and hand over a small docker-compose file — the integration kit. The site runs docker compose up -d and it joins. One key per site, revocable individually.

4. Training happens in windows. On the schedule you set, connected sites train locally for a few rounds and send back only weight updates — never rows of data. The platform aggregates them into a new model version. If too few sites are connected, the window is skipped and recorded, not forced.

5. You promote, everyone serves. Each training run produces a candidate version with its metrics. You promote the one you trust; every site picks it up at its next check-in and serves it locally — your app calls localhost:8080/predict (or client.predict() in Python) and the answer is computed on that machine, from that promoted version. Rollback is promoting an earlier version. Model updates stop being releases.

What this means for privacy

The platform sees model weights, training metrics, and per-site health. It does not see rows of data, and it cannot identify your sites. That boundary is a structural property of the system, not a policy, and it has honest consequences worth reading before you commit: what the platform sees — and structurally cannot.

What your engineers get

The integration kit is deliberately boring: one docker-compose service per site, a local HTTP endpoint for predictions, an optional local ingest API for feeding training data, and a signed artifact chain — every model image and every kit carries a cosign signature you can verify against our published key. The integration overview has the exact commands.