Feature Flags — Abrova Flags

Feature flags (toggles) let you enable or disable features without deploying new code — decoupling deployment from release so you control who sees what, and when.

What are Feature Flags?

Feature flags (also called feature toggles) let you enable or disable features in your application without deploying new code. They decouple deployment from release, giving you full control over who sees what — and when.

What it will cost.

100,000 flag evaluations are free every month. Usage above that will cost from your prepaid wallet; the price is set at launch. See Pricing.

Flag Types#

Every flag has a value type: boolean, string, number or json. The SDKs have one getter per type, and each getter takes the default to use when the flag cannot be served.

Boolean Flags

Simple on/off toggles. The most common type — perfect for feature rollouts, kill switches, and A/B testing.

typescript

if (flags.isEnabled('dark_mode')) {
  // Show dark mode
}

Multivariate Flags

Return different values based on weighted variants. Use for A/B/n testing, configuration, and dynamic content.

typescript

const flow = flags.getString('checkout_flow', 'control');
// Returns: 'control', 'variant_a', or 'variant_b'

The examples above use a client SDK. On a server you pass the user with every call: flags.getString('checkout_flow', { userId: 'user-123' }, 'control').

Client SDKs and Server SDKs#

Client SDKs

Flutter, React Native, Android, iOS, Next.js client

Use the public API key only
Abrova Flags evaluates for the current user; the app gets values
Targeting rules never reach the device
Values are cached for offline use

Server SDKs

Node.js, Next.js server

Use the API key and the server secret
Download the rules and evaluate locally
You pass the user context with every call
No network call per evaluation

Pick the SDK for your platform: Flutter, React Native, Android, iOS, Next.js, Node.js.

Using a Flag#

1Initialise the SDKGive it your API key and, if you use them, the environment. Client SDKs start from the values cached on the device.
2Say who the user isClient SDKs: call identify(userId, attributes) after sign-in. Server SDKs: pass userId and attributes with each call. Signed-out users are covered by an anonymous id the client SDK keeps for you.
3Read the flag with a defaultUse isEnabled or a typed getter. The default is returned before the first values arrive, when the flag does not exist, or when it has another type.
4Change it from the dashboardClient SDKs pick up changes on start, when the user changes, and when the app comes back to the foreground. Server SDKs refresh every 30 seconds.

Common Use Cases#

Gradual Rollouts

Release features to 5% of users, then 25%, then 100%. If something breaks, instantly roll back to 0%.

Kill Switches

Wrap risky features in a flag so you can disable them instantly without redeploying.

A/B Testing

Use multivariate flags to test different versions of a feature and measure which performs better.

Beta Programs

Target specific user segments (like beta testers) with new features before general release.

Scheduled Launches

Schedule a flag to enable at a specific date/time for product launches and promotions.

Environment-Specific Config

Enable a feature in staging but keep it disabled in production until ready.

Flag Lifecycle#

1. Create

Define a flag in the dashboard with a unique key, targeting rules, and rollout percentage.

2. Integrate

Add the flag check in your code using the SDK. Deploy your code — the flag stays off.

3. Enable

Toggle the flag on from the dashboard. Users start seeing the feature based on your rules.

4. Clean Up

Once the feature is stable, remove the flag check from your code and delete the flag.

Tip.

Always clean up stale flags. Feature flags are meant to be temporary — once a feature is fully rolled out, remove the flag from your code to reduce complexity.

Upgrading from 0.1.x#

All six SDKs are at 0.2.0, and it is a breaking release. Client apps receive evaluated values only.

Client apps must upgrade

A 0.1.x client SDK stops receiving flag updates

Typed getters replace getValue

Use getBoolean (getBool in Flutter), getString, getNumber and getJson, each with a default. getDetail replaces evaluate and adds a reason

identify replaces setUserAttributes

identify(userId, attributes) and setAttributes replace the whole set of attributes. They no longer merge

Signed-out users are bucketed

Client SDKs keep an anonymous id, so a 10% rollout reaches about 10% of signed-out users instead of all of them

Server context field renamed

In the Node.js and Next.js server SDKs, userAttributes is now attributes

Next.js imports moved

The server SDK is imported from @abrova/flags-nextjs/server and the browser code from @abrova/flags-nextjs/client

Dependencies and segments apply everywhere

SDK 0.1.x ignored flag dependencies. With 0.2.0 every evaluation checks them

Users are bucketed again once

Rollouts and variant splits use a new bucketing method, so a user may land in a different rollout group or variant after the upgrade

Each SDK page ends with the exact list of calls to rename.