Can I use one SDK key for every environment?
Last updated:
No, and the key is not a credential you could reuse even if you wanted to. It is the selector: whichever environment issued the key is the configuration your process receives. Point staging at the production key and staging reads production flag states, which means a rollout you start in staging is a rollout in production.
People reach for a shared key to cut down on config sprawl. It reads like an authentication token, and one token for one service sounds tidier than four.
It is not an authentication token. The key answers a different question: which environment’s configuration should this process receive? Every environment issues its own, and that is the entire mechanism by which a flag can be on in development and off in production.
What sharing one actually does
Give staging the production key and staging is now reading production. Toggle a flag to test something and you have toggled it for real users. The dashboard will show exactly what you did, in the production environment, because that is where the change landed.
The reverse fails more quietly. A production deploy carrying a development key reads development’s configuration, and every flag you enabled locally months ago is suddenly live.
The shape that works
One key per environment, supplied the same way you supply a database URL:
FEATUREFLIP_SDK_KEY=sdk_server_dev_a1b2c3d4
# production secretsFEATUREFLIP_SDK_KEY=sdk_server_prod_z9y8x7w6Keep them out of source control. They belong in environment variables or a secrets manager, alongside everything else that differs per deploy.
Server and client keys are also separate
Within a single environment there are two kinds. A server key stays on your infrastructure and can see every flag in the project, while a client key ships to browsers and only ever receives the flags you have marked client-side visible. They are not interchangeable, and the prefix tells you which one you are holding:
sdk_server_... backend only, sees everythingsdk_client_... safe to ship, sees opted-in flags onlyShipping a server key to a browser is the mistake with real consequences, because it exposes every flag and every targeting rule in the project.
If a key leaks
Regenerate it from the dashboard. Only that environment is affected, which is the point of keeping them separate, and you update one deploy config rather than all of them.
Environment isolation and key handling are documented in Environments.
Related questions
Why does my flag work in dev but not production?
Flags are configured per environment, so enabling one in development changes nothing elsewhere. Rules and rollout percentages are per environment too.
Why can't my browser SDK see a feature flag?
A flag has to be marked client-side visible before a client SDK key can receive it. Server keys see every flag, client keys see only the opted-in ones.
Why is my feature flag returning the default value?
Six reasons a Featureflip flag falls back to the default you passed, ordered by how often each one is the real cause, with the check for each.
Still stuck?
The docs cover every SDK, and the free Solo plan is enough to reproduce most of these locally.