Feature flags from the terminal. Deploy dark, roll out by percentage, roll back in one command.
Available today
The terminal, your code and the audit log all talk to one API. Nothing you do in one is hidden from the others.
| FLAG | STATE | ROLLOUT | CHANGED |
|---|---|---|---|
| checkout-v2 | locked | 50% | 2h ago |
| new-pricing | off | — | 2h ago |
| dark-mode | on | 100% | 1d ago |
| new-checkout | on | 25% | 3m ago |
Create, roll out, lock and roll back from the terminal. Every command is one API call, and every call is audited.
JavaScript and Python. In-memory evaluation, no network call per check, the same bucket for the same user in both.
| WHEN | ACTION | CHANGE |
|---|---|---|
| 21s ago | rollback | 30% → 50% |
| 30s ago | rollout | 50% → 30% |
| 10m ago | unlock | checkout-v2 |
| 10m ago | lock | CVE-2026-1234 |
Who changed what, and what it was before. Lock a flag with a reason and nobody moves it until an admin says so.
No redeploy, no hotfix branch, no 3am revert. The vulnerable code stays deployed but dormant.
$ flagrship status new-checkoutnew-checkout ON 100% production changed 4m ago by ci@$ flagrship rollback new-checkout✓ Rolled back new-checkout in production — ON 25%$ flagrship log new-checkout --limit 221s ago rollback 100% → 25% nisarg@4m ago rollout 25% → 100% ci@Users hash into 100 buckets. Raising the number moves the threshold, never the user, so nobody flickers between cohorts.
Rollback is an undo. It restores the state before the last change and logs itself, so a second rollback undoes the first.
Six rules the API enforces so you do not have to remember them at 3am.
The audit row is written in the same transaction as the change. There is no such thing as an unlogged mutation.
An admin locks a flag with a reason. Every mutation returns 409 with that reason until it is unlocked.
MurmurHash3 over flagKey:userId. Node and Python pass one shared conformance file, so a user never flips between services.
Bucketing runs inside the SDK. The API has no endpoint that accepts a user ID, so there is nothing to leak.
Every config has an ETag. Unchanged polls return 304 with an empty body. Config crosses the wire once, then only when you change it.
If Flagrship is unreachable the SDK keeps its last config or your in-code defaults. It never throws on the boot path.
A real key to a real organization on the live API. Read-only, no signup. Every line below runs right now.
$ npm install -g @flagrship/cli$ flagrship init --key sk_read_9aY_NggYCzbqQe-tekXzbmojkqZfAr9J✓ Saved production key to .flagrship.json$ flagrship listKEY STATE NAME CHANGEDcheckout-v2 ON 50% LOCKED Checkout v2 2h agonew-pricing OFF New Pricing Page 2h agodark-mode ON 100% Dark Mode 2h agonew-checkout ON 25% New Checkout 2h ago$ flagrship log new-checkout$ flagrship rollout new-checkout 100error: this key has scope "read"; rollout needs "write".The last CLI line is a scoped key doing its job. Want one that can flip flags?
Ask for a beta keyNo MAU meter. Your bill does not grow because your product did.
For side projects and small teams. Permanent, not a trial.
For teams that ship every day and want to know who flipped what.
For compliance requirements and a named person to call.
Install the CLI, create a flag, add three lines to your app. Five minutes, no dashboard signup.