Security at Featureflip
Our infrastructure, the data we hold, account and key protection, and how to report a vulnerability.
Feature flags sit on the request path of everything you ship, so it is fair to ask what the service behind them does with your data. This page answers that from what Featureflip runs today. Every claim below is checkable against the product, the documentation, or our privacy policy.
Where your data lives
Featureflip runs on Hetzner Cloud in the European Union, and the PostgreSQL database behind it sits on the same infrastructure. Your data is stored and processed in the EU whether you sign in from Berlin, Atlanta, or Singapore. If your own compliance posture requires data to stay in the EU, that is the default here rather than a configuration step you have to find and switch on.
Cloudflare fronts the public endpoints for DNS, CDN, and web application firewall. Everything is served over HTTPS. featureflip.io sends HTTP Strict Transport Security with a two-year lifetime, subdomain coverage, and preload, so a browser that has reached us once will refuse to fall back to plain HTTP even if something tries to strip the scheme. Frame, content-type, referrer, and permissions policies are set on every response.
We use a small number of third-party processors and name all of them: Stripe for payments, Cloudflare, Hetzner, Resend for transactional email, Grafana Cloud for monitoring, and Google Analytics plus Microsoft Clarity for marketing-site analytics. Card details never reach our systems, because Stripe handles payment processing end to end. The privacy policy carries the current list along with what each one receives.
What we store, and what we do not
The most sensitive data a flag platform can touch is the evaluation context: the user IDs, email addresses, plan tiers, and custom attributes your application passes into a flag check so the right variation comes back. Featureflip does not store it.
Server-side SDKs go a step further and never transmit it. A server SDK downloads the flag configuration once at startup and keeps it in memory, so evaluating a flag is a local lookup with no network round trip. The attributes are read inside your own process and stay there. This is the same architecture that keeps flags resolving during a Featureflip outage, described in the reliability guide.
Client-side SDKs work differently. A browser cannot hold your targeting rules without exposing them to anyone who opens devtools, so client SDKs send the evaluation context to us and receive pre-evaluated values back. That context is used for the evaluation and then discarded. Your rule logic, your segment definitions, and any flag you have left unmarked for client-side use all stay on our side of the wire.
Beyond that we hold what you would expect an account to need: your name, email, a hashed password, your flag and targeting configuration, and the audit log. Deleting your account deactivates it immediately and removes personal data permanently after a 30-day grace period, with audit entries anonymized.
Signing in
Two-factor authentication is available on every plan, including the free one. Featureflip uses standard time-based one-time codes, so any authenticator app works. Turning 2FA on issues a set of recovery codes, each usable once, for the day your phone goes in a river. You can regenerate them whenever you want by confirming with your password, which invalidates the old set.
You can also sign in with Google and skip having a Featureflip password at all. If an account already exists under the same address, Featureflip links the two only when that email has been verified, because automatically linking an unverified account is a well-worn route to account takeover. Enterprise plans add SAML and SCIM. The account security guide walks through enrollment.
Passwords are stored hashed, never in plain text, and are subject to length and complexity requirements at sign-up. Repeated failed sign-in attempts lock the account temporarily, which makes online password guessing impractical without slowing down anyone who simply mistyped.
Inside an organization, members hold one of three roles. Owners have full access including billing and member management, Admins manage flags, environments, segments, and members but cannot reach billing, and Members can view and edit flags and targeting rules without touching environments or team membership. Role changes and removals are themselves recorded in the audit log.
Keys, tokens, and blast radius
Featureflip issues a separate SDK key per environment. A key that escapes therefore reaches development, or staging, or production, instead of all three at once.
Server and client keys are separate too, and they expose different things. A server SDK key can read every flag in the project and belongs on infrastructure you control. A client SDK key is public by design, because it ships inside a browser bundle where nothing stays secret, and it returns only the flags you have explicitly marked as client-side visible, as pre-evaluated values rather than rules. Deciding which flags carry that mark is the security decision, and it is yours to make per flag. The SDK overview lays out the split.
The Management API uses two token types. Personal access tokens, prefixed ffp_, act as you. Service tokens, prefixed ffs_, are machine identities scoped to one organization, carrying an explicit role and an optional allowlist of the projects they may touch. A service token is the right choice for CI and automation, because it is not tied to a person and keeps working after someone leaves the team. Tokens can carry an expiry, and revoking one takes effect immediately.
Rotating any key or token is recorded, so the change shows up in the log alongside everything else.
Every change is recorded
The audit log runs automatically, with nothing to switch on. It covers creates, updates, and deletes across flags, variations, targeting rules, per-environment configuration, environments, segments, SDK keys, projects, and the organization itself.
Each entry records who acted, by name and email, when they acted, and the IP address and user agent of the request. For an edit it also records the individual property that changed together with its value before and after, which is what turns "someone touched this flag on Tuesday" into an answer you can act on during an incident review. Every flag additionally carries a History tab scoped to itself and everything beneath it.
Retention depends on your plan: 7 days on Solo, 30 on Pro, 90 on Business, and 365 on Enterprise, with entries past the window removed automatically. Moving up a plan is what buys a longer window, so check pricing if a compliance review needs records going further back than yours holds.
Reporting a vulnerability
Email security@featureflip.io. The inbox is monitored and we read every report.
Include whatever gets us to a reproduction fastest: the affected endpoint, SDK, or page, the steps you took, what you expected, and what actually happened. A proof of concept helps. So does telling us how you would exploit it, because the severity of a finding usually turns on what it chains into.
Two requests in return. Give us a chance to ship a fix before you publish, and please keep your testing away from anything that degrades the service or reaches data belonging to another customer. Testing against your own account and your own projects is welcome.
Frequently asked questions
Where does Featureflip store my data?
In the European Union. Featureflip runs on Hetzner Cloud in an EU region, and the PostgreSQL database sits on the same infrastructure. Your data is stored and processed in the EU regardless of where you or your users connect from. The full list of third-party processors, covering Stripe for payments, Cloudflare for DNS and CDN, Resend for transactional email, and Grafana Cloud for monitoring, is published in our privacy policy.
Does Featureflip store the user attributes I pass into a flag evaluation?
No. Evaluation context is processed for the evaluation and is not written to storage. Server-side SDKs go further and never transmit it: they download the flag configuration at startup, hold it in memory, and evaluate locally, so a flag check involves no network call and the attributes stay inside your process. Client-side SDKs do send context, because a browser cannot hold your targeting rules without exposing them, and they receive pre-evaluated values in return.
Does Featureflip support two-factor authentication?
Yes, on every plan. Featureflip uses time-based one-time codes (TOTP), which work with Google Authenticator, 1Password, Authy, and any other standard authenticator app. Enabling 2FA issues a set of single-use recovery codes for the case where you lose your authenticator, and you can regenerate them at any time by confirming with your password. You can also sign in with Google instead of a password. SAML and SCIM are available on the Enterprise plan.
What happens if an SDK key leaks?
The damage depends on which key, and the split is deliberate. SDK keys are issued per environment, so a leaked key reaches one environment rather than your whole project. Client SDK keys are public by design and return only the flags you have explicitly marked as client-side visible, along with pre-evaluated values rather than your targeting rules. Server SDK keys can read every flag in the project and belong on your servers only. Rotating a key takes effect immediately and is recorded in the audit log.
Can I see who changed a feature flag?
Yes. Every create, update, and delete across flags, variations, targeting rules, per-environment configuration, environments, segments, SDK keys, and projects is recorded automatically, with no configuration needed. Each entry stores the actor's name and email, a timestamp, the IP address and user agent of the request, and for edits the specific property with its value before and after. Retention runs from 7 days on Solo to 365 days on Enterprise.
How do I report a security vulnerability in Featureflip?
Email security@featureflip.io with enough detail to reproduce the issue: the affected endpoint or SDK, the steps you took, and what you observed. Reports go to a monitored inbox and we read every one. Please give us a chance to ship a fix before publishing, and please do not run tests that degrade the service or touch data belonging to other customers.
Questions we have not answered here
If your team runs a security review and needs detail this page does not cover, get in touch and we will answer it directly. For anything urgent, use the security address above.