Running FlyttGo across EU, AF and MENA — a data residency playbook

Operators deploying across multiple jurisdictions ask the same early question: where does our data live, and can we prove it? This is the pattern we ship for customers running simultaneously in the EU, Africa and MENA.

The three-tier residency model

Every FlyttGo tenant runs under one of three residency tiers: managed EU, customer cloud, or sovereign datacenter. A single operator can run different tiers for different regions — EU managed for efficiency, GCC sovereign for national compliance, customer-cloud in South Africa to satisfy POPIA.

• Managed EU — region-locked tenants under GDPR, Data Processing Agreement with the FlyttGo-managed infrastructure entity.
• Customer cloud — your AWS / Azure / GCP tenancy, your contractual terms, your residency posture.
• Sovereign — national datacenter, national key management, optional air-gap.

How data stays in-region

Each tenant declares a primary region at provisioning. Database, object storage and queue clusters are all pinned. Cross-region reads only happen through explicit federation (e.g., a regulator dashboard) and go through an access layer that records every cross-border access in a tamper-evident log.

Keys and secrets

Encryption keys live with the tenant. Managed deployments use FlyttGo-operated HSMs region-locked to the primary region. Customer-cloud deployments integrate with the customer's KMS (AWS KMS, Azure Key Vault, GCP KMS). Sovereign deployments use national HSMs, with quarterly key rotation under the customer SOC's control.

Cross-border programmes

Programmes that span regions — freight corridors, regional student ID federations, cross-border payments — run as federations of independent per-region tenants that exchange only the specific message types required for the corridor. The default is no sharing; sharing is a per-data-class decision documented in the DPA.