Security Overview

Flagpool is designed with security and privacy as foundational principles. All flag evaluation happens locally in your application, and user data never leaves your infrastructure.

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

What is sent to Flagpool:

• Flag evaluation counts (only if analytics is enabled, opt-in)
• Flag key names (no user data)

What is never sent to Flagpool:

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

Data encryption

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

Target list encryption

Target lists (collections of user IDs for targeting) are encrypted with AES-256-GCM before being stored on the CDN. The decryption key is provided to the SDK at initialization and never sent to Flagpool servers.

This means even if someone accesses the CDN payload, they cannot see the user IDs in your target lists.

Dashboard                  CDN (public)               Your SDK
──────────                 ────────────               ────────
Target list:               Encrypted blob:            Decrypted locally:
[user-1, user-2]  ──▶     { _encrypted: true,  ──▶  [user-1, user-2]
                            _data: "a3f2c1..." }
                           (unreadable without key)

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 its own API key (env_...). API keys are used to authenticate SDK requests to the CDN.

• Keep API keys confidential — do not commit them to public repositories
• Use environment variables — store keys in .env files or secret managers
• Rotate if compromised — regenerate keys in the dashboard; old keys stop working immediately

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

Decryption keys should be treated with the same care as API keys.

Client-side SDKs

When using Flagpool in a browser (React SDK, JavaScript SDK), the API key and decryption key are embedded in the client-side bundle. This is by design — the flag configuration on the CDN contains only flag definitions and encrypted target lists, not sensitive data.

However:

• Target lists are encrypted — user IDs cannot be extracted from the CDN payload without the decryption key
• No server-side secrets are exposed — the API key only grants read access to flag configurations
• User context never leaves the browser — evaluation is local

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
• JavaScript SDK — crypto adapter setup for target lists