Why Having Multiple Environment Keys Helps You
Use server, mobile, and client keys to control payload exposure, map flags to the right SDK type, and ship safer rollouts.
Multiple environment keys let you decide exactly which runtime gets which flag data. That means cleaner payloads, safer defaults, and fewer accidental cross-platform leaks.
If your stack includes backend services, mobile apps, and browser clients, one shared key model quickly becomes limiting. Different runtimes have different risk profiles, payload needs, and release workflows. Zenmanage now supports three keys per environment so each runtime can authenticate and receive the right payload type:
- Server key: For backend services and server-side SDKs.
- Mobile key: For mobile SDK delivery.
- Client key: For browser and other client-side SDK delivery.
Why this matters in practice
The biggest operational win is control. You can decide whether a flag should be included in mobile and client payloads without changing how server-side delivery behaves. That gives you a clean split between backend authority and client-facing configuration.
You also avoid over-delivering data. Teams can keep platform-specific logic in platform-specific payloads, which reduces confusion during debugging and rollout verification.
Match key type to SDK type
A simple rule keeps integrations predictable: the SDK runtime should always use the matching key type. Server runtimes use server keys, mobile runtimes use mobile keys, and browser clients use client keys.
# Server runtime example
export ZENMANAGE_SERVER_KEY="tok_your_server_key_here"
# Browser runtime example
export VITE_ZENMANAGE_CLIENT_KEY="tok_your_client_key_here"
When keys are mapped this way, the retrieval API can return payloads that are already filtered for the platform that requested them.
Better rollout safety
Multi-key delivery improves release safety in a few ways:
- Wrong key type usage surfaces quickly during integration testing.
- Client and mobile payload inclusion can be controlled flag by flag.
- Platform-specific payload generation prevents accidental coupling between runtime classes.
- Obfuscated CDN delivery paths reduce sibling-payload guessability.
Migration tips
If you are already using a single environment key today, migrate in stages:
- Rename existing references to server key in backend services.
- Add mobile and client keys to their matching runtime configurations.
- Review flags that should be excluded from mobile or client payloads.
- Validate payload behavior in staging before production rollout.
For implementation details, see the API Reference and the Environments and MACs concept page.
Multiple environment keys are available now. If you are planning a rollout across server, mobile, and client runtimes, this model gives you a safer default architecture without sacrificing developer speed.