Privacy & Data Handling

Flagpool is built on a fundamental principle: your user data never leaves your infrastructure. All flag evaluations happen locally inside the SDK — no user attributes, identifiers, or context data are ever sent to Flagpool servers.

Zero data transmission

Unlike traditional feature flag services that evaluate flags on a remote server (requiring you to send user data over the network), Flagpool SDKs evaluate flags entirely locally:

Traditional approach:               Flagpool approach:
─────────────────────               ──────────────────
Your App → sends user data →        Your App → evaluates locally
Remote Server → returns result      No user data leaves your app

What is sent to Flagpool

• Flag evaluation counts — only if analytics is explicitly enabled (opt-in)
• Flag key names (e.g., new-checkout) — no user data attached
• Anonymous, aggregated counts — never individual user evaluations

What is never sent to Flagpool

• User IDs, emails, names, or any PII
• Context attributes (plan, country, device, etc.)
• Application data or business logic
• IP addresses or browser fingerprints of your users

How it works

1. Flag configurations are exported to the CDN as a static JSON payload
2. The SDK downloads this payload once and caches it locally
3. When your code calls isEnabled() or getValue(), the SDK evaluates the flag against the user context in-memory — no network request
4. The CDN payload contains only flag definitions, rules, and encrypted target lists — never user data

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│   Flagpool   │  Flag   │     SDK      │  Local  │    Your      │
│     CDN      │  config │   (Cached)   │  eval   │ Application  │
└──────────────┘ ──────▶ └──────────────┘ ──────▶ └──────────────┘
                                                          ↑
                                               User data stays here

Target list encryption

Target lists (collections of user IDs used for precise targeting) contain sensitive data. Flagpool encrypts them with AES-256-GCM before they are stored on the CDN:

1. Target lists are encrypted server-side in the dashboard
2. The encrypted blob is uploaded to the CDN
3. The SDK downloads the encrypted blob
4. Decryption happens locally using a key you provide at SDK initialization
5. The decryption key never leaves your infrastructure

This means even if someone accesses the CDN payload, they cannot read the user IDs in your target lists. Even Flagpool cannot read them.

Data encryption at every layer

Data state	Encryption
In transit	TLS 1.3
At rest (storage)	AES-256
Target lists	AES-256-GCM (client-side decryption)
Backups	AES-256

GDPR compliance by design

Because Flagpool never processes user data on its servers, many GDPR concerns are eliminated by architecture:

• No data processing agreement needed for flag evaluation — user data never reaches Flagpool
• No cross-border data transfer of user data — evaluation is local to your infrastructure
• Data minimization — the CDN payload contains only flag definitions, not user data
• Right to erasure — there is no user data on Flagpool servers to erase

If analytics is enabled, only anonymous flag evaluation counts are transmitted — no user identifiers are included.

Comparison with remote evaluation

Aspect	Remote evaluation (others)	Local evaluation (Flagpool)
User data sent to vendor	Yes — every evaluation	Never
Latency per evaluation	50-200ms (network round trip)	< 1ms (in-memory)
Works offline	No	Yes
Privacy compliance	Requires DPA and audit	Privacy by architecture
Vendor can see user data	Yes	No

Next steps

• Security Overview — full security model including API keys and audit logging
• Access Control — roles, permissions, and team management
• Architecture & Performance — CDN and caching architecture