Server-side testing

Also called: server-side experimentation

Last updated:

Server-side testing is any test or rollout whose variation is chosen in your own backend, before the response reaches the user. A server SDK holds the flag configuration in memory and evaluates locally, so the decision costs a sub-millisecond lookup and no extra network call. The rule that produced it never leaves your infrastructure, which is why anything a user should not be able to read or influence belongs on this side.

What a server key can see

A server key, prefixed sdk_server_, reads every flag in the project. It must never reach a browser. That access is what lets a backend-only flag gate an unshipped API, a schema migration, or a pricing rule while both its name and its payload stay private. The SDK overview sets the two key types out side by side.

What this changes about a test

The assignment is made once, in a place you control, on data you already hold. Nothing flashes the wrong variation while a client bootstraps, because the response arrives already decided. Attributes that never reach the browser can drive the rule, which covers most of the interesting ones, from an account's contract value to an internal risk tier. The trade-off shows up when a change affects only rendering, because deciding it still costs a request, so teams commonly evaluate on the server and pass the result down to the client rather than deciding it twice.

Want the full picture? Read the concept guide: SDK overview →

Try it in your own app

Free Solo plan covers 10 flags and 2 environments. No credit card, no demo call — sign up and ship.