We ship product updates weekly. Follow us on 𝕏 for the latest.
Flag changes now take effect immediately in your application.

We previously shipped live flag updates for our server SDKs. With this release, we’re bringing the same real-time behavior to browsers and mobile apps.
Live updates are especially useful when you need to roll back a faulty feature quickly. They also make testing and rollouts much clearer: when you update a flag, you no longer have to wonder when that change will show up in your app.
Under the hood, the SDK connects to Reflag on initialization and subscribes to updates using server-sent events. When a flag changes, the SDK receives the update automatically and applies it without requiring a page reload or app restart.
For React, Vue.js and React Native live flag updates are enabled by default in the newly released SDKs. The browser-sdk keeps live updates disabled by default
We've also consolidated the endpoints that our client SDKs talk to. This means if you were using a Content Security Protocol on your web app, you now only have to whitelist https://front.reflag.com. See the individual changelogs below for details and the updated CSP documentation.
Upgrade to the latest SDK versions to start using live flag updates:
If you’re bootstrapping flags from your backend, make sure to upgrade the node-sdk as well:
We’ve made a number of improvements to the Node SDK:
When you change a flag, the update is now propagated immediately to backend services running our Node SDK. Since version 1.6.0, @reflag/node-sdk opens a persistent connection to our servers and receives flag updates in real time.
This improves debuggability and makes it faster to roll back faulty features.
We’ve also introduced fallback providers. This reliability feature lets the SDK persist the latest successfully fetched raw flag definitions to fallback storage such as a local file, Redis, S3, GCS, or a custom storage like your database.
Reflag servers remain the source of truth. During initialize(), the SDK always tries to fetch a live copy of the flag definitions first, and continues receiving updates from Reflag over time.
If that initial fetch fails, the SDK can load the most recent snapshot from fallback storage instead. This allows new processes to start even in the exceedingly rare event of a Reflag outage.
If Reflag becomes unavailable after the SDK has already been initialized successfully, the SDK continues using the last successfully fetched definitions already held in memory. In other words, fallback providers help new processes start during an outage; they are not needed to keep an already running process alive.
We’ve introduced a new API to make testing easier. You can define base overrides with setFlagOverrides() and then layer additional overrides on top with pushFlagOverrides().
This works especially well in Jest or Vitest, where tests often use nested describe() blocks:
export const flag = function (name: string, enabled: boolean): void {
let remove: (() => void) | undefined;
beforeEach(function () {
remove = reflagClient.pushFlagOverrides({ [name]: enabled });
});
afterEach(function () {
remove?.();
remove = undefined;
});
};
describe("foo", () => {
describe("with new search ranking enabled", () => {
flag("search-ranking-v2", true);
describe("with summaries enabled", () => {
flag("smart-summaries", true);
// ...
});
});
});
It’s now possible to pick the “Changes” display mode in the targeting timeline to better see exactly what changed for each version. This is useful as the targeting rules become complicated.
Happy shipping!
‍
We’ve released a strongly typed TypeScript SDK for interacting with your Reflag account. It provides a simple, maintainable way to integrating Reflag flag management into your backend services.
This initial release focuses on core feature flag operations:
With the SDK, you can automate workflows that previously required manual API integration.
See the Customer Admin Panel example for a practical implementation.
Toggling a feature for a specific user is straight forward:
import { Api } from '@reflag/management-sdk';
const reflag = createAppClient("app-123", {
accessToken: process.env.REFLAG_API_KEY,
});
// enable 'new-checkout' for 'user-1'
const updatedUserFlags = await reflag.updateUserFlags({
envId: 'env-456',
userId: 'user-1',
updates: [{ flagKey: 'new-checkout', specificTargetValue: true }],
});See Common Workflows for more examples
We've renamed our APIs. The APIs were previously called the Public APIÂ and the RESTÂ API. We renamed them so they are now called the Runtime APIÂ and the Management API.
The Runtime API is the one your application talks to at runtime to fetch flags for users.
The Management APIÂ is used to manage your Reflag account, including listing flags, updating targeting etc.
See the APIÂ Access docs for the full picture.
When your team updates feature flag targeting, not every change needs the same level of visibility.
Reflag can notify your team in Slack or Linear when targeting changes. Some updates are worth broadcasting everywhere. Others are minor tweaks that don't need to ping Slack or add another comment in Linear.
And if you work across multiple environments, the right default usually isn't the same for production as it is for staging or testing.
To make that easier to manage, we've added Notification policies in App Settings.

It gives you one place to control how Reflag posts targeting updates to Slack and Linear by default.
When updating targeting these defaults are preselected, but you can always override them before saving the change.
You can find it in Settings → Notification policies. See the docs for full details
Happy shipping!
Reflag was originally built for B2B SaaS companies. Since launch, we’ve had a Company page that lets you:
But not every product has a company or organization-level entity. And even when they do, flag data is often just as important at the individual user level.
When you’re handling a support request or debugging an issue, it’s incredibly helpful to know exactly which features were enabled for a specific user — and when.
To make this easier, we’ve introduced a dedicated User Details page. It mirrors the functionality of the Company page, but scoped to an individual user.

You can access it via Segments → Users, then select the user you want to inspect.
We've launced a new React Native SDK (beta). It's a lightweight React Native wrapper around @reflag/react-sdk that makes it easy to feature-flag in React Native apps.
This release gives you the core parts of Reflag in your mobile apps, supports flag evaluation with hooks, and includes patterns for refreshing flags on app lifecycle events.
Install the package:
$ npm i @reflag/react-native-sdkWrap your app:
import { ReflagProvider } from "@reflag/react-native-sdk";
// ...
<ReflagProvider>{/* app */}</ReflagProvider>
Read a flag:
import { useFlag } from "@reflag/react-native-sdk";
function StartHuddleButton() {
const { isEnabled, track } = useFlag("huddle");
if (!isEnabled) return null;
return <Button onPress={() => track()}>Start Huddle</Button>;
}
See the documentation for detailed instructions on how to get started.
Happy shipping!
We've made it much easier to migrate to Reflag from LaunchDarkly.

See https://reflag.com/migrate/launchdarkly for details on how to get started.
We’ve created a Reflag node for n8n, enabling you to use Reflag in your automated and agentic workflows.
n8n is a workflow automation tool. You can use it to implement multi-step AI agents and integrate with hundreds of apps. Now you can connect Reflag too, with our community node.
The Reflag node supports all the same end-points as our REST API, including the ability to list applications, get details of an app, list flags for an app, as well as get and update flag targets.
This means you can integrate your back-office systems with Reflag's flag targeting. By using the Reflag node, you can provide access to specific flags for a company or user directly from your systems.
To get started, you’ll need to generate an API key, and add it to the Reflag node credentials. For more information, check out the node package on npm.