Flags and variations
A flag has an immutable key, a name, a description, and an ordered list of JSON values. The index is the variation’s identity. Booleans, numbers, strings, arrays, and objects are all ordinary values.
Open source · your network · HTTP API
Feature flags that stay in your network.
Flaggator is a feature-flag service you deploy beside the applications it controls. A container in your cluster is enough. Projects, environments, flags, targeting, and evaluation go through one HTTP API. You keep the decisions, and a rollout does not come with a license fee.
Your network
Docker or Kubernetes, next to the applications you already run.
Your control
Flags, rules, and credentials stay where you put the service.
No license fee
Open source. Turning a flag on does not start a subscription.
What you model
A project holds flags and environments. Variations belong to the flag. Targeting belongs to one environment, so a flag can be on in dev and off in prod.
Per-environment targeting
Each environment stores whether the flag is on, the off variation, individual targets, ordered rules, a fallthrough, prerequisites, and a config version. A new environment starts with every existing flag disabled.
Rules, then a rollout
The first matching rule wins, and every clause in that rule must match.
A rule can serve one variation or a percentage rollout. Rollouts hash
flag:salt:subject with SHA-256, so the same person stays
in the same bucket.
Prerequisites
A flag can require another flag in the same environment to evaluate to a given variation before its own rules run. Cycles are rejected on write. If a prerequisite fails, the off variation is served.
Credentials and users
Every request carries a bearer. Operators use JWT users with global roles
(reader, writer, protected_writer, admin).
Login can be local password credentials or an external IdP via JWT (JWKS).
Opaque secrets are hashed and shown in plaintext only once, when created.
| Caller | May do |
|---|---|
| User JWT | Day-to-day management, limited by roles. Local login issues an HS256 JWT; an IdP JWT is verified against JWKS. Roles always come from the local user row. Does not evaluate. |
| Management token | Break-glass / bootstrap. Full management and evaluation (must name project and environment when evaluating). Prefer JWT users for ordinary work. |
| SDK token | Bound to one environment. Evaluates flags and reads that environment’s evaluation config. Cannot mutate. |
Writes leave a record
Replacing targeting sends the version the client read. A stale version is a conflict, so two editors cannot silently overwrite each other. The client reads again and retries. Mutations are audited: actor, action, and the before and after documents. The secret itself is never written to the log.
GET /health and POST /v1/auth/login need no
bearer. Health reports that the process is up and does not check the
database.
Evaluation order
The same configuration and the same context always produce the same decision. Time and randomness are not inputs. Order is off, prerequisites, targets, rules, then fallthrough. This example has no prerequisites.
Decision
—
- variation
- —
- reason
- —
- rule
- —
- bucket
- —
1 off
2 target
3 rule
4 fallthrough