Security Overview

Flagpool SDKs evaluate flags locally in your application. The SDK does not send evaluation context as part of a flag-fetch request; review enabled analytics and your surrounding application for any other data flows.

Privacy-first architecture

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 locally:

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

SDK configuration and requests:

• The SDK is configured with the environment SDK API key; browser applications expose that value to their users.
• SDK flag downloads use a URL derived from the project ID and decryption key. Depending on the SDK and enabled features, the SDK API key is used for optional analytics or streaming requests.
• Flag evaluation counts are sent only if analytics is enabled (opt-in).

What is not included in SDK flag-evaluation requests:

• User IDs, emails, or any PII
• Context attributes (plan, country, etc.)
• Application data

Data encryption

Target-list encryption

Target-list values are encrypted with AES-256-GCM in the exported targetLists object when encryption is enabled for an environment. Flag definitions and targeting rules remain readable. Browser SDKs receive the decryption key and can inspect decrypted target-list values, so encrypted exports do not keep membership confidential from the client doing the evaluation. Use server-side evaluation with the key and plaintext list kept out of browser-delivered code and data if values must remain confidential from end users.

CDN architecture

Flag configurations are served via globally distributed infrastructure through global edge caching:

• No origin server hit for SDK requests — configurations are cached at the edge
• Egress is free — no bandwidth charges regardless of scale
• Flag updates propagate globally in under 50ms
• SDKs cache flags locally and work offline after the initial fetch

SDK security

API keys

Each environment has an SDK API key (env_...) used to authenticate SDK requests.

• In a browser application, the SDK API key is client-delivered configuration and users can inspect it. Do not treat it as a server-only secret.
• In server applications, keep SDK keys in environment variables or a secret manager.
• Do not confuse the SDK API key with dashboard administrator credentials, database credentials, or service-role keys; never put those server-only credentials in browser code.
• Rotate an environment SDK API key from the dashboard if needed; the prior key stops working.

Decryption keys

Decryption keys (tlk_...) serve two purposes:

1. Computing the CDN URL hash (so the URL is not guessable)
2. Decrypting target lists client-side

In server processes, protect decryption keys with server-side environment configuration or a secret manager. A key passed to a browser SDK is intentionally delivered to that browser and can be recovered by its user.

Client-side SDKs

When using Flagpool in a browser (React SDK, JavaScript SDK), the environment API key and decryption key are delivered to the client. Treat both as visible client configuration, not as secrets. The flag definitions and targeting rules remain readable in the export; only target-list values are encrypted.

Anything passed to a browser SDK (including its environment API key and decryption key) is client-visible. Do not place dashboard administrator credentials, service-role keys, or other server-only secrets in browser code. Feature flags and target-list rules do not enforce authorization or paid entitlements.

Audit logging

On Pro plans and above, Flagpool logs all changes to flags, targeting rules, environments, and team members:

• Who made the change
• What was changed (before/after values)
• When the change was made
• IP address and user agent (if configured)

Audit logs are accessible in the dashboard under Settings → Audit Logs.

Next steps

• Access Control — roles and permissions
• Environments — environment-specific credentials
• Crypto adapter guide — encryption contract, setup for every SDK, and security boundaries