SDK Overview

GrowthBook SDKs are lightweight libraries that let you use feature flags and run experiments in your application. They handle feature evaluation and assignment logic.

​

What SDKs Do

The SDK has two main responsibilities:

1. Fetch features from the API: The SDK downloads your feature definitions from GrowthBook and caches them for fast access.
2. Evaluate features: Using attributes you provide (like user ID, country, or subscription plan), the SDK evaluates your targeting rules and returns the appropriate feature values. This evaluation happens wherever the SDK runs—in the browser, on your server, or at the edge.

​

Running Experiments

To measure experiment results, the SDK needs to log which variation was assigned. This is done through a tracking callback—a function you provide that sends assignment data via your event tracking system (like Segment, Mixpanel, or GA4). Without a tracking callback, the SDK will still assign variations and your features will work, but you won’t be able to analyze experiment results in GrowthBook. All SDKs use the same assignment logic, so the same attributes always produce the same variation regardless of which SDK you use. Each SDK has documentation on setting up tracking callbacks, and many offer pre-built integrations with popular analytics tools.

​

Choosing the Right SDK

The main differences between SDK types are where they run and what problems they solve best.

​

Client SDKs

Where they run: In the browser or mobile device Best for: UI changes, visual experiments, and frontend feature flags Trade-offs:

• Easy integration with frontend frameworks
• Feature rules are visible to users (see remote evaluation if you need to keep rules private)
• Can show a brief flicker while experiments load asynchronously (see our recommended anti-flicker techniques)

Common use cases: Rolling out a new dashboard design, testing button colors, showing features based on user plan SDKs: JavaScript, React, Vue, Swift, Kotlin, Flutter, React Native

​

Server SDKs

Where they run: On your backend infrastructure Best for: Backend logic, API responses, or when you need to keep targeting rules private Trade-offs:

• Keeps feature logic and rules private
• No visual flicker
• Requires infrastructure to run (not just a script tag)
• Need to pass evaluation results to the frontend if UI changes are required
• May need to extract attributes from cookies, headers, or tokens

Common use cases: Testing a new recommendation algorithm, rolling out API changes, experimenting with pricing tiers, ML model rollouts SDKs: Node.js, Python, Ruby, PHP, Java, Go, C#, Elixir

​

Edge SDKs

Where they run: On edge platforms/CDNs (Cloudflare Workers, Fastly Compute, Lambda@Edge) Best for: Eliminating flicker for visual experiments or doing redirects before your application server handles the request Trade-offs:

• Eliminates flicker for visual experiments and redirects
• Can inject feature data into HTML for the frontend to use
• More complex setup and integration
• Resource constraints (CPU/memory limits)

Common use cases: A/B testing landing pages without flicker, geo-based redirects, paywall experiments SDKs: Cloudflare Workers, Fastly Compute, Lambda@Edge

​

Getting Started

Choose your SDK below to see installation and setup instructions:

​

Client

​

Server

​

Edge

---

🛠️ Want to build your own SDK?
Follow our guide to integrate GrowthBook into any platform.