4.0 Protect
Keep every credential and rollback path scoped.
Runtime keys, browser client keys, management automation keys, console sessions, roles, and kill switches each live in their own lane.
Practice
Safety comes from visible boundaries, not from one powerful key.
Scoped runtime keys
Server runtime keys bind to one project environment and only carry runtime scopes such as evaluation and snapshots.
Client exposure checks
Browser keys are publishable, origin-scoped, and can evaluate only flags explicitly exposed for that environment.
Audited control
Management writes, key changes, targeting updates, and kill-switch actions leave readable activity behind.
Product proof
Different jobs get different keys.
FeatureGate separates server runtime evaluation, browser-exposed evaluation, management automation, and human console sessions so one boundary does not quietly become all-powerful.
- Server runtime keys read one environment
- Browser keys see only exposed flags
- Automation keys use management scopes
- Kill switches record a rollback action
What changes
The habit behind the feature.
Protect the hot path
Applications should read only the flag data they need to serve traffic. Human and automation management belong behind different credentials.
Make rollback obvious
A kill switch forces a configured boolean flag off in one environment, records the action, and lets the SDK observe the change through the normal runtime sync path.
Prefer readable audit history
Change notes and activity entries should explain why a release moved, who changed it, and which project or flag was touched.
Go deeper