SDK Connection

An SDK Connection is how you authorize your application to fetch feature flags from GrowthBook. Each connection is scoped to an environment and a language/framework.

Creating an SDK Connection

In the GrowthBook UI, go to Settings in the left sidebar.
Click SDK Connections.
Click Add SDK Connection.
Give it a name (e.g., “Node.js Dev”).
Select the Environment (e.g., development).
Select the Language / Framework (e.g., JavaScript/Node.js).
Click Save. GrowthBook shows you two values:
- apiHost — for self-hosted: http://localhost:3100; for Cloud: https://cdn.growthbook.io.
- clientKey — a string starting with sdk-....
Copy both values. You will use them to initialize the SDK.

import { GrowthBook } from '@growthbook/growthbook';

const gb = new GrowthBook({
  apiHost: 'http://localhost:3100',   // self-hosted SDK API
  clientKey: 'sdk-YOUR_CLIENT_KEY',
});

await gb.init({ timeout: 2000 });

// Check a boolean flag
if (gb.isOn('my-feature')) {
  console.log('Feature is enabled');
}

import { GrowthBook } from '@growthbook/growthbook';

const gb = new GrowthBook({
  apiHost: 'http://localhost:3100',   // self-hosted SDK API
  clientKey: 'sdk-YOUR_CLIENT_KEY',
});

await gb.init({ timeout: 2000 });

// Check a boolean flag
if (gb.isOn('my-feature')) {
  console.log('Feature is enabled');
}

Trade-offs

Option	Benefit	Cost
A separate SDK key per environment	Safer, limits blast radius	More keys to manage
The same SDK key everywhere	Faster to set up	Risk of flags leaking across environments

Common mistakes

Using the same SDK key for both dev and production, so flags are tested against the wrong environment unintentionally
Hardcoding the clientKey in client-side code instead of an environment variable
Not setting a timeout on gb.init(), so the app hangs waiting on the network

💡 Real-world example

Large engineering organizations commonly separate SDK connections per service/microservice, to limit the blast radius if a key leaks.