Skip to content
FortressFlag Docs

Roles and safety

FortressFlag ships with four roles and a set of production safeguards designed around one idea: moving fast in non-production should be effortless, and changing production should take either the right role or a second person.

The four roles

Section titled “The four roles”
Viewer Developer Admin Owner
See flags and team ✓ ✓ ✓ ✓
Change non-production environments ✓ ✓ ✓
Propose & approve production changes ✓ ✓ ✓
Change production directly ✓ ✓
View SDK keys ✓ ✓ ✓
Mint & revoke SDK keys ✓ ✓
Manage team, projects & environments ✓ ✓
Read & export the audit log ✓ ✓
Billing, usage & organization policy ✓

A few notes the table can’t carry:

  • Viewers and Developers see only the projects they’ve been granted.
  • Nobody grants a role above their own. An Admin can invite Developers, not Owners.
  • The full matrix is published in-app, so what you see in the dashboard always reflects what the server actually enforces.

Production changes: a second pair of eyes

Section titled “Production changes: a second pair of eyes”

Developers can’t write production-class environments directly — but they don’t have to wait for an Admin either. A Developer proposes a change (a toggle, a rules edit), and any second person — another Developer or above — reviews and approves it, which applies it.

The shape of this is deliberate, and worth understanding as a buyer:

  • It’s peer review, not hierarchy review. Two Developers together can change production. The point is that no single person changes it alone from below Admin.
  • Self-approval is refused, full stop — by person, not by role. Even an Admin can’t approve their own proposal.
  • The audit log names both parties on every applied proposal — who proposed, who approved.

Admins and Owners can still write production directly; the proposal path is there so the rest of the team has a safe route in.

Scheduled changes

Section titled “Scheduled changes”

A boolean flag’s state can be scheduled: turn holiday-banner on at 09:00 UTC Friday. The change takes effect at exactly the chosen time for every reader, and scheduling an environment requires the same permission as writing it now — a schedule is just a write with a timestamp, and it’s held to the same bar.

The audit log

Section titled “The audit log”

Every state change lands in an append-only audit log: who, what, when, from where, and the before/after values. Admins and Owners can browse it in-app with filters and export it as CSV — for an incident review, a compliance request, or an auditor. See Export the audit log for the walkthrough.

Where to next

Section titled “Where to next”