Why feature flags for EU data sovereignty need their own setup
Self-hosting flag evaluation inside the EU is the main route for organizations that cannot send user attributes to US SaaS. The platform matters less than where the attributes, logs and remote access sit. A targeting rule that checks country, plan or account age sends those values to the flag service every time it evaluates, and under GDPR Article 44 every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. Attributes used for targeting are personal data, so a US-hosted evaluation endpoint is a transfer that needs a documented basis. Fines for infringements of Articles 44 to 49 reach EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).
For most EU teams the realistic shortlist is Unleash or GrowthBook, self-hosted in the organization's own cloud account or data center. Both let you keep the evaluation service, database and SDK traffic inside the EU. Edition limits matter here: Unleash Open Source is limited to 1 project and 2 environments, so most regulated setups will need the Enterprise edition for single sign-on, SCIM and change requests. GrowthBook's self-hosted Open Source plan is free with unlimited users but one project, and approval workflows, SSO and SCIM sit in its Enterprise features. Confirm current edition terms with each vendor before you size the deployment.
Before choosing a platform, map every place attributes and events leave the boundary: SDK calls, streaming or update channels, analytics or experiment exports, support access and log shipping. Confirm which of these run to a vendor-hosted service and which stay in your environment. Treat the answer as the input to your transfer assessment, not as a footnote to the platform comparison.
Which GDPR and Data Act requirements shape the flag architecture
This table maps each GDPR and Data Act requirement to what it means for where flag evaluation runs, who holds administrative access, which vendor locations matter and which fines apply. Read each row as a design question to answer before choosing a platform, and treat the main takeaway as this: any path that carries targeting attributes outside the EEA is a transfer that needs documented justification.
| Requirement | What it means for the flag service | Evidence to keep and where it usually fails |
|---|---|---|
| Article 44 GDPR, including onward transfers | Every transfer of personal data to a third country, including onward transfers by a vendor's sub-processors, must meet Chapter V. Targeting attributes such as user IDs, plan tier or country are personal data when they identify a person. | Transfer register entries per vendor and sub-processor. Failure point: a SaaS flag vendor that routes evaluation events through sub-processors outside the EEA without disclosing it. |
| EDPB view on remote access and cloud storage | Remote access from a third country, even only viewing data on screen for support, is a transfer, and so is storage in a cloud outside the EEA. Vendor support staff outside the EEA therefore count. | Support access logs and data location statements. Failure point: vendor engineers troubleshooting a flag from abroad with screen sharing of targeting rules. |
| Schrems II and the Data Privacy Framework position | Privacy Shield was invalidated in 2020 while standard contractual clauses survived. The DPF adequacy decision covers only US organizations on the DPF List, and an appeal in Case C-703/25 P is pending, so adequacy for a US vendor may change. | Transfer impact assessment plus a DPF List check. Confirm the vendor's current listing and the appeal status with counsel before relying on it, since the outcome is open. |
| Article 48 GDPR, third-country disclosure orders | A foreign court or authority order to disclose data is enforceable in the EU only under an international agreement such as a mutual legal assistance treaty. Without one, a vendor's compliance with such an order is a risk the controller must assess. | Vendor statements on handling government requests and their legal basis. Failure point: contracts that promise notification of requests without a stated process. |
| CLOUD Act reach under 18 U.S.C. 2713 | US providers must preserve or disclose data in their possession, custody or control whether it sits inside or outside the United States. A US-headquartered SaaS flag service can be reached even when its servers are in the EU. | Vendor's answer on data control and key custody. Self-hosting in the EU with EU-held keys reduces, but does not remove, the question of who controls the operator and support access. |
| Data Act Article 32, non-personal data | Providers of data processing services must prevent third-country governmental access to non-personal data held in the Union where it would conflict with EU or national law. Flag configurations, segment definitions and experiment metadata often fall here when they hold no personal data. | Provider's technical and legal measures statement. Failure point: treating flag rules as harmless because they contain no personal data, while they still reveal business logic. |
| Fines under Article 83(5)(c) GDPR | Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. The exposure sits with the controller that chose the transfer, not only the vendor. | A written decision record showing why each transfer was avoided or justified. Confirm the exact turnover basis with counsel. |
What user attributes and telemetry still leave the EU
Targeting attributes are only safe in the EU if you know which pattern sends them out. Four data flows look similar in a flag platform but carry different data. In server-side evaluation, the application sends the user's attributes (country, plan, account age, cohort) in the request to a flag service, so those attributes cross the boundary on every call unless the service runs in your own EU infrastructure. In client-side evaluation, the browser or app sends attributes to a remote API to receive its flag set. Analytics events carry whatever the SDK or your code attaches to a tracked action, and experiment exposure logs record which user saw which variant, often with the same attributes. Each flow needs its own answer, because a self-hosted evaluation service does not change where the event pipeline sends data.
Local evaluation keeps targeting attributes inside the application. In this pattern the SDK downloads the flag definitions and evaluates rules in process, so the user's attributes never leave the application server or device. Even so, some traffic still leaves. Update polling fetches flag configuration, so the flag server or edge layer sees the requesting host and timing. SDK version checks and telemetry may report SDK versions and environment identifiers. Event ingestion sends exposures and metrics, and admin sessions expose the staff who change flags, with their IP addresses and identities. Confirm with each vendor which of these calls it makes by default, which can be turned off, and whether the destination is inside the EEA. Check the SDK configuration for each language you use, not just the product documentation.
Map every data flow before you choose a deployment pattern. Build a table with one row per flow: the endpoint, the fields sent, whether they include personal data under GDPR, the destination country and the sub-processors involved. Include the self-hosted flag server, any managed edge or CDN, the event pipeline and the warehouse. Then decide where the transfer documentation applies. Any flow that reaches a US-based service needs a transfer basis, and EDPB Guidelines 05/2021 treat remote access from a third country as a transfer too. Keep that map with your records of processing so the reviewer can see which attributes stayed local and which did not.
Which self-hosted platforms fit an EU data sovereignty brief
For an EU sovereignty brief, the question is less which tool has the most features and more where flag evaluation runs, which edition holds the access controls auditors expect, and what licence obligations follow the deployment. The cards below cover the three platforms named in this hub and the edition trade-off that sits across all of them.
GrowthBook self-hosted
GrowthBook ships a single Docker image with its front end, API and statistics engine, and stores metadata in MongoDB or a compatible database. Its LICENSE places code outside the enterprise directories under MIT Expat, so the self-hosted Open Source plan keeps flag data in your infrastructure without a per-seat fee. Experiment analysis runs against your own warehouse, and only aggregated statistics leave it. Confirm which directories your build includes before you rely on the Open Source plan, since the free tier allows 1 project.
GrowthBook Enterprise controls
The self-hosted Enterprise tier adds SSO and SCIM, advanced permissioning, approval workflows and safe rollouts, which are the controls a sovereignty review usually asks about first. These features sit under the GrowthBook Enterprise License, so the licence obligation changes once you move past the free directories. Ask the vendor whether the audit trail and approval records can be exported and retained inside your EU environment, and what the Enterprise license covers for your hosting model.
Unleash server licence split
From v8.0.0, Unleash moved its main repository and the unleash-server package to AGPLv3, while the official open-source Docker images remain under Apache 2.0. If you run unmodified images inside your own network, the AGPL source obligations are not triggered by ordinary internal use, but modifying the server and offering it as a service triggers them. Have counsel confirm your use pattern against the Unleash licence post before you fork or patch the server.
Unleash Open Source and Edge limits
The Open Source edition allows 1 project and 2 environments with basic roles, which is rarely enough for separate EU production and staging tenants. Edge OSS, the caching layer that keeps SDK traffic local, reaches end of life on December 31, 2026, and Unleash recommends OSS Edge users move to an Enterprise plan. Plan the caching and proxy layer as its own component with a maintained version, because an unsupported edge would sit between your EU services and the flag API.
Unleash Enterprise access controls
Unleash Enterprise adds unlimited projects and environments, single sign-on, SCIM provisioning, custom roles, user groups and change requests. For a sovereignty brief, these matter because they keep identity and approval records under your control instead of an external admin console. Confirm the self-hosted Enterprise deployment options in writing, since the pricing page lists cloud, self-hosted and hybrid hosting under custom contracts.
Flagsmith edition and hosting check
Flagsmith is a common shortlist entry for self-hosted flags, but this hub has not verified its current edition limits, self-hosting packaging, licence terms or SDK local evaluation behavior. Before it goes into an EU brief, ask the vendor which features are available without an enterprise agreement, where the evaluation service runs, and whether any telemetry or usage data leaves your network. Record the answers with the version you intend to deploy.
How a sovereign flag rollout runs in phases
The sequence moves flag evaluation and its targeting data into EU infrastructure in controlled stages, so each phase closes with evidence a data protection lead, auditor or works council can check. Each phase produces a named artifact that the next phase depends on.
Map data flows and assess transfers
Your privacy team and the flag owners list every user attribute that a flag rule reads, every SDK call that sends data out, and every place a US SaaS vendor would store or access that data today. The output is a data flow register that marks each flow as stays in the EU, leaves the EU with a named transfer tool, or needs redesign. The step is done when the privacy lead signs off the register and each third-country flow has a recorded legal basis or a removal action.
Decide platform, edition and licence obligations
Compare GrowthBook, Unleash and Flagsmith against the attribute, approval and identity needs from the register, and check which features sit only in paid editions, such as SSO, SCIM and change requests. Review the licence terms for each candidate, including the AGPLv3 change in Unleash v8.0.0 if you plan to modify the server or offer it to others. The output is a hosting and platform decision record that names the edition, the licence reading your counsel accepted, and the features you are paying for. Confirm current edition limits on each vendor's pricing and comparison pages before you sign.
Set up EU hosting and identity
Deploy the flag server, its database (PostgreSQL for Unleash, MongoDB or a compatible store for GrowthBook) and its backups in EU regions or on your own data center, and confirm that logs, metrics and support access follow the same boundary. Connect administrator access to your identity provider with role mapping so that only named staff can change production flags. The output is a hosting record with region, subprocessors and network paths, plus a tested access matrix. The step closes when a test shows that a flag can be created and changed only by approved roles, and that the admin UI is reachable only from the expected networks.
Configure local SDK evaluation and telemetry
Configure server-side and client-side SDKs to evaluate flags locally from a downloaded or cached ruleset, so that targeting attributes such as account tier or region are compared inside your application and not sent to the flag server on every call. Decide which events, such as flag exposure and experiment metrics, are sent back and strip or hash identifiers that are not needed. The output is a tested SDK configuration document listing what each SDK sends, what it caches and what happens when the server is unreachable. The step closes when network capture in a test environment confirms that no targeting attribute leaves the application.
Migrate flags from the US SaaS service
Export flag and segment definitions from the existing service as JSON through its API, then recreate them in the new platform by the import or admin API route. Map targeting rules, percentage rollouts, prerequisites and segments one by one, and record any rule the importer cannot carry over. Segments and custom strategies must exist in the target before import, so create them first. The output is a migration log that pairs every source flag with its target flag and marks anything rebuilt by hand. The step closes when a reviewer has compared a sample of flags in both systems and found the same evaluation result for the same test users.
Run in parallel and cut over
Run both systems behind an abstraction layer in your code, so that a flag read goes to the EU platform while the old service stays as a fallback for a defined window. Compare decisions from both systems on live traffic and investigate every mismatch before you switch the default. Cut over one flag group at a time, keep a tested rollback path, and remove the US SDK only after the last flag group is stable. The output is a cutover record with mismatch counts, the switch dates and the rollback steps you tested. Confirm the window length with your engineering and privacy leads before the run begins.
Compile transfer documentation and review access
Assemble a transfer file that holds the final data flow register, the hosting record, the SDK configuration, the vendor contract terms and any transfer tool still in use, such as standard contractual clauses for support access from a third country. Record the exit path under the EU Data Act, including export formats, so you can move to another provider or on-premises later. Schedule periodic access reviews of admin roles and remove old keys and SDK credentials. The output is a signed transfer file and an access review calendar, and the step closes when the data protection officer accepts the file. Your external auditor or supervisory authority decides whether the file is sufficient.
Deployment options for EU-only flag evaluation
In this model, the flag server, its database and the SDK evaluation path all run in infrastructure the organization controls, in EU data centers, and the people with administrative access are EU-based staff or EU-based operators under contract. Targeting attributes such as account tier, country or cohort never leave that environment, so the main transfer question moves to remote access. Any support session where a non-EU engineer can see a screen, a log or a database row counts as access from a third country under EDPB Guidelines 05/2021, so the access model has to be designed as carefully as the hosting.
- Flag server and database: Unleash or GrowthBook run as containers on EU-hosted Kubernetes or virtual machines, with PostgreSQL 15 or later for Unleash or MongoDB for GrowthBook, both in the same region.
- Attribute holders: Context fields sent with each evaluation, plus any segments stored on the server, hold the personal data. Confirm which fields are required and drop those that are not needed for targeting.
- Operator access: Limit production access to named EU personnel, and record the operators' locations and any contractor access in the transfer assessment.
- Logs and backups: Application logs, error tracking and backup copies can contain attributes, so confirm their location and retention.
- Vendor support: Ask the platform vendor whether support tickets, crash dumps or diagnostics would expose data, and whether they can be redacted.
Check whether the chosen edition includes the single sign-on and audit features your access reviews depend on, because the free editions limit those features.
Here the organization runs the flag platform in an EU region of a cloud account it owns, and uses that cloud provider's managed database service instead of a vendor-operated cloud. Attributes are stored and evaluated inside the organization's account, so the vendor does not receive them. The residual risk is the cloud provider itself. If the provider is a US-headquartered company, its staff, support channels and its legal obligations under instruments such as the CLOUD Act can reach data it holds, which is why EDPB Recommendations 01/2020 and the transfer assessment must address it directly.
- Account and region: Keep the cloud account, the Kubernetes cluster, the managed database and object storage in EU regions, and document each service's location.
- Provider exposure: Record the provider's headquarters, its key management options and whether customer-managed encryption keys are available, then assess legal access risk before signing.
- Managed database: Services such as MongoDB Atlas or a comparable managed database for GrowthBook, or a managed PostgreSQL service for Unleash, may replicate or back up data outside the chosen region, so confirm the replication settings.
- Infrastructure as code: Store the deployment definitions in the organization's repository so the same region and configuration can be reproduced and audited.
- Contract terms: Obtain the provider's data processing terms and the transfer documentation, including the standard contractual clauses where they apply.
Ask the cloud provider in writing where support engineers can access customer data and under what legal process.
In a hybrid model, the flag evaluation and the data it uses stay in the organization's EU infrastructure, while a vendor-hosted interface manages flag definitions and users. This is the option that most often leaves data in the clear outside the EU, so it needs the closest review. Whether a flag definition contains personal data depends on how targeting rules are written, for example a rule that names a specific customer identifier. Those rules may travel to the vendor even when evaluation does not, and any vendor-hosted telemetry or analytics would also be a transfer.
- Evaluation location: Confirm that SDKs evaluate flags against local rules and attributes, so targeting inputs are not sent to the vendor for each request.
- Definitions in the cloud: Identify which fields the vendor interface stores, including rule names, segment names and user lists, and treat any personal data there as a transfer.
- Telemetry: Check which events, usage metrics and error reports leave the environment, and whether they can be disabled or reduced.
- Vendor personnel: Ask where the vendor's support and engineering staff are located and whether they can view production definitions.
- Edition limits: Some governance features, such as approvals and advanced permissions, appear only in paid editions, so confirm the features exist in the version you plan to run.
Check every data flow in writing against the vendor's documentation before accepting that attributes stay in the EU.
Evidence a data protection officer or auditor will ask for
This table maps each item a data protection officer or auditor is likely to request to the component that produces it and the gap that usually appears. Read it as a checklist for the flag platform, the SDKs, the hosting team and the vendor contracts, since no single system holds all of the evidence. DeployOpen prepares these records and data flow documentation, but assessments, transfer impact conclusions and certifications are issued by the controller's counsel, the DPO or independent auditors.
| Evidence item | Produced by | What it must show |
|---|---|---|
| Records of processing | Controller's privacy team, with the platform owner's input | Flag attributes used for targeting, purposes, retention periods and the EU hosting location of the flag service |
| Data flow diagrams | Platform team and DeployOpen documentation | Which SDKs send which attributes to which endpoint, including any telemetry or stats calls leaving the EU |
| Transfer impact assessment | Controller, with counsel and the DPO (DeployOpen supplies technical inputs) | Whether any remote access or storage outside the EEA exists, and how third-country authority requests are assessed |
| SCCs under Decision 2021/914 | Controller and each non-EU vendor or sub-processor | Signed clauses covering any residual transfer, such as vendor support sessions or telemetry storage |
| Admin and remote session access logs | Flag platform audit log, plus the hosting team's jump host and VPN logs | Who opened admin sessions or support screens, from which country, and when, with approvals linked |
| SDK configuration exports | Flag platform export function, run by the platform team | Which attributes and targeting rules each SDK receives, proving local evaluation keeps user data in the EU |
| Vendor location and sub-processor list | Vendor contracts and the hosting provider's documentation | Where each component runs, which sub-processors touch data, and notice of changes |
| Data retention settings | Platform configuration and the data warehouse owner | How long experiment assignments, events and exported statistics are kept and where they are deleted |
| Evidence gaps to confirm | Controller and DeployOpen, before the assessment starts | Items the vendor cannot produce, such as sub-processor locations or telemetry details, flagged as open risks |
What EU teams ask before self-hosting flags
Does self-hosting feature flags remove all transfer risk?
No. Self-hosting keeps flag evaluation and targeting attributes in the infrastructure you choose, but it does not automatically end every transfer. Remote access from a third country, even only viewing data on a screen for support, counts as a transfer under the EDPB Guidelines 05/2021 (version 2.0). Vendor telemetry, crash reports, update checks, licence validation and any SaaS-hosted add-on can still send data out. Map every outbound connection from your flag server and SDKs, confirm which ones carry user attributes, and document the ones you keep. Any support access by a vendor or partner also needs to be scoped and logged.
What does the internal team need to provide for a self-hosted flag platform?
Your team needs an owner for the flag server, a database administrator familiar with the chosen backing store, someone who can operate containers or Kubernetes, and developers who will integrate SDKs into each service. Security and privacy staff must decide which attributes may be sent for targeting, how long they are kept, and who may change flags in production. Plan for an internal approver for flag changes, because the platform does not make that decision for you. Ask a partner to name which of these roles it will cover and which it expects you to staff.
How long does it take to set up EU-hosted feature flags?
The timeline depends on the drivers, not on a standard duration. The main ones are how many applications and SDK languages must be integrated, whether the flag server runs on Kubernetes, Docker or a virtual machine in your EU region, whether SSO and role mapping are required, and how many existing flags need migrating. Data residency reviews and approvals of the list of outbound connections often take longer than the installation itself. Ask for a fixed-scope plan that lists these phases and the dependencies your own teams must meet.
What drives the cost of self-hosted flags, and what recurs?
The main one-time costs are infrastructure setup, integration work in each service, migration of existing flags and targeting rules, and the review of data flows. Recurring costs include hosting, the managed database if you use one, staff time for upgrades and monitoring, and any subscription for an edition that adds features you need. Subscription pricing for hosted vendors is published on their pricing pages, while self-hosted costs depend on your infrastructure and staffing. Ask any implementation partner for a written quote that separates one-time work, recurring support and third-party licences.
Is the open-source edition enough for EU targeting and approvals?
It depends on what you need to govern. GrowthBook's free self-hosted Open Source plan includes unlimited users and one project, but SSO, SCIM, advanced permissioning, approval workflows and sticky bucketing are listed as Enterprise features on its pricing page. Unleash Open Source is limited to one project and two environments with basic roles, while its Enterprise edition adds SSO, SCIM, project roles and change requests. Check each platform's comparison page against your requirements for identity, approvals, audit logs and environments before you decide. Also confirm licence terms, since Unleash moved its server source to AGPLv3 from v8.0.0.
How do we migrate from LaunchDarkly or Statsig to self-hosted flags?
Migration starts by exporting your flag definitions, segments and targeting rules, then recreating them on the target platform. GrowthBook documents an importer for LaunchDarkly that fetches projects, environments and flags through the LaunchDarkly REST API, and a Statsig importer that retrieves gates, configs and experiments with a Console API key. Both importers have limits, and the GrowthBook documentation warns that advanced setups may not import cleanly and that application code must still switch from the vendor SDK to the new one. Unleash's migration guide maps LaunchDarkly targeting rules to activation strategies and suggests running both systems in parallel behind an abstraction layer before cutover. Inventory your flags and SDK calls first, because that list sets the effort.
Does DeployOpen issue GDPR or compliance certificates?
No. DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Your data protection officer and legal team decide on transfer mechanisms, such as standard contractual clauses, and on any transfer impact assessment. A partner can supply configuration records, data flow diagrams and runbooks for those reviews, but the conclusions remain yours and your assessor's.
Questions to put to an implementation partner
Start with the network path, because it decides whether the sovereignty claim holds at all. Ask the partner to list every SDK call that leaves the application network by default, including initial flag fetches, event ingestion, streaming connections and any telemetry or version checks the SDK sends on startup. Ask whether local evaluation works offline once the flag configuration is cached, and which fallback values apply if the EU-hosted server is unreachable. Require a written answer for each SDK your teams use, since the default behavior differs between server SDKs, browser SDKs and mobile SDKs. Confirm how the partner will prove the answer, for example with egress captures taken in a test environment, rather than accepting a diagram.
Next, pin down who can see user attributes. Ask who holds administrator, support and database access to the self-hosted flag service, and where those people are located when they log in. The EDPB guidance treats remote access from a third country, even only viewing data on a screen, as a transfer, so ask the partner how support sessions will be run, whether vendor engineers get standing access or only break-glass access, and how each session is logged. Ask how single sign-on and role assignments will be configured, and whether the editions in scope provide the SSO, SCIM and role features needed for that control. Check any edition feature against the product documentation, since the free editions often omit them.
Then ask about commercial terms and documentation. Ask the partner to price each Enterprise feature the sovereignty design depends on separately from the base platform, and to state which recur annually and which are one-time. Ask how transfer documentation will be delivered: the data flow map, the list of processors and sub-processors, the transfer impact assessment, and the contract clauses that apply to any non-EU party in the support chain. Finally, require the fixed scope to name the data flow mapping work, the egress tests, the number of environments tested and the handover format. Ask what is excluded, and what changes the price if the partner finds a path that leaves the EU.
