Environments and projects

Two axes organize everything in FortressFlag: projects split your flags by codebase or product, and environments split each flag’s value by deployment stage. Your dev app build reads new-checkout from the dev environment; your shipped app reads it from production. Same flag, independent values.

Environments are yours to define

Every organization starts with three seeded environments — dev, staging, and production — and you can create, rename, and delete your own, up to 12. A QA environment, a per-region pair, a canary — whatever matches how you deploy.

Managing environments (creating, renaming, reclassifying, deleting) is an Admin-and-above action. You can’t delete an environment while live SDK keys still authenticate against it — an environment your apps are still reading isn’t deletable out from under them.

The production class — not the name

What makes an environment “production” isn’t its name — it’s the production class, a checkbox an Admin sets. The class is what drives the safeguards:

• Writing flags there takes a higher role. Developers toggle non-production environments freely all day; a production-class environment accepts direct writes only from Admins and Owners. (Developers can still propose production changes for a teammate to approve — see Roles and safety.)
• The dashboard styles it loudly, so nobody edits production thinking it’s staging.

Because it’s a class and not a name, you can have several production-class environments — say, production-eu and production-us — and each gets the same safeguards. And marking an environment production-class is itself an audited, Admin-level act, because it changes who may write there.

Projects

Flags, segments’ targets, and SDK keys live inside a project. One organization can hold many — one per app, one per team, however you slice your work. Each project has its own flag list, its own archive, and its own SDK keys.

Project access is an allowlist

Admins and Owners see every project. Viewers and Developers see only the projects they’ve been granted — access is a per-member allowlist, managed by Admins.

One detail worth knowing so it never surprises you: a project a member hasn’t been granted answers as if it doesn’t exist — a not-found, not a “no access” error. A member can’t enumerate project names they weren’t given. If a teammate says a project is missing, check their access grants before anything else.

Where to next

• Roles and safety — who can do what, and the production safeguards
• Keys — SDK keys are scoped to one project + environment
• Invite your team — grants are set right on the invitation