Changelog

We’ve added Cursor rule and custom slash command templates to our docs, so you can get the coding agent to create a new flag and wrap the code it creates with it.

Cursor recently added the ability to create custom Slash commands, which are reusable prompts for common requests. You can create one to flag your code, using /flag in the Agent input and selecting the command from the dropdown menu.

Better yet, add a Cursor project rule to flag your code. Rules provide persistent, reusable context at the prompt level. Project rules are stored in `.cursor/rules`, are version-controlled, and scoped to your codebase.

To get started, check out the templates in our docs.

We’ve added support for Customer Requests to our Reflag agent for Linear. Now you can give customers early access when their request is shipped.

Reflag agent for Linear enables you to create and manage feature flags and update access rules directly from Linear.

We now include Customer Requests in the context we give to the Reflag agent, so it’s able to act on it. For example, on a Linear issue, you can add a comment saying:

@reflag flag this feature and release it to the customers that requested it.

Reflag agent will create a feature flag for you, and set the access rules to include the requesting customers. Don’t worry, we take care of matching customers on Linear to the companies you have in Reflag.

This addition makes Linear customer requests actionable, saving you from having to create a flag yourself, as well as lookup and add the customers you want to give early-access to.

To get started with Reflag agent for Linear, check out the integration page or read the docs to begin using it.

We shipped support for API keys so you can use the Reflag CLI within CI/CD pipelines and with coding agents.

Available in Settings under SDK & API keys, the page lists SDK keys (known before as "Environment Keys") that you can use when configuring our SDKs in your product. This page also includes the ability to create API keys, which allow access to the Reflag REST API.

API keys currently support 3 scopes: read-only, create flag, and update flag targeting. They enable you to run the Reflag CLI where auth is needed in automated environments, like CI/CD pipelines and background coding agents.

The keys used to be available in a few different places within Reflag web app, so we took the opportunity to consolidate them in one spot.

Check out our docs article for full details on how to use Reflag with CI/CD pipelines, as well as our API access docs, too.

We’ve added support for server-side rendering with bootstrapped flags for faster initial page load times.

With getFlagsForBootstrap() in the Node SDK and ReflagBootstrappedProvider in the React SDK, you can evaluate flags on the server and pass them to your client-side applications.

This eliminates the loading delay that users experience when flags are fetched on the client. With bootstrapped flags, they’re evaluated server-side and immediately available when your app loads.

How it works

On your server, use getFlagsForBootstrap() to get serializable flag data:

const client = new ReflagClient();
await client.initialize();

const { context, flags } = client.getFlagsForBootstrap({
  user: { id: "john_doe", name: "John Doe" },
  company: { id: "acme_inc", name: "Acme, Inc." },
  other: { location: "US", platform: "web" },
});

Then on the client, use ReflagBootstrappedProvider instead of the regular ReflagProvider:

function App({ bootstrappedFlags }) {
  return (
    <ReflagBootstrappedProvider
      publishableKey="your-key"
      flags={bootstrappedFlags}
    >
      <YourApp />
    </ReflagBootstrappedProvider>
  );
}

Your flags are now immediately available without any loading state:

function FeatureComponent() {
  const { isEnabled } = useFlag("new-feature");
  return isEnabled ? <NewFeature /> : <OldFeature />;
}

Beyond faster initial page loads, bootstrapped flags can help with SEO as search engines see the correct content immediately as well as improved UX with no loading flicker when features conditionally render. It also works with static generation to evaluate flags at build time for static sites.

The method returns raw flag data without wrapper functions, making it JSON serializable for easy server-to-client transfer. You can also use it with a bound client for simpler APIs:

const boundClient = client.bindClient({
  user: { id: "john_doe" },
  company: { id: "acme_inc" },
});

const bootstrappedFlags = boundClient.getFlagsForBootstrap();

For more details, check out the updated Node SDK docs and React SDK docs.

Flag ownership is important for accountability and internal communication, and it’s now easily managed in Reflag.

Flag ownership helps address questions like: Who’s responsible for moving this out of Beta? Or, who will clean up and archive the flag once rolled out?

So now you can set an owner for each flag on Reflag, and the new “My flags” view makes it easy to find the flags you own.

You can also find flag owners using the search bar, too:

‍

When Linear first shipped support for agents on Linear, we were a launch partner. Linear have high standards for how interactions should work, but the details were left up to ourselves. Recently, Linear shipped their Agent Interaction SDK which codified the interaction patterns that emerged during the initial agent implementation phase.

The Agent Interaction SDK comes with much better support inside Linear for working with agents. We've implemented it, and now using Reflag agent in Linear is a super smooth experience:

The Linear team added a way to show that the agent is working, and it also now keeps a history of what the agent did.

Implementation-wise, we previously needed to keep a bunch of state on our side to ensure that the agent had full context for follow-up messages. That's now handled by Linear, too, making our implementation much simpler to maintain.

To learn more, check out our integration page on Linear, or read the docs.

Remote config allows you to change app behavior without having to re-deploy. For example, you can use configs to provide some accounts with a stable LLM model while others get a newer, experimental one.

We’ve added advanced targeting rules to configs. Just like on the Access tab, you can now target based on advanced filters, like company or user attributes, feature access, and other context. 

Here’s an example remote config: All accounts get the 1st variant, GPT-4o, except those who get variant 2, GPT-5.

We also polished the UI and, in response to feedback, revised some of the terms to make it more intuitive to work with.

Happy shipping! 

Release a feature, then jump over to the new Monitor tab to view exposure, adoption, and feedback in real-time.

Use the Monitor tab to catch issues and iterate faster. A live chart displays feature exposure and use over the last hour, which updates in real-time - handy for monitoring usage after you set a flag to GA. Or you can review historic data from the last week, month, quarter, or 6 months. 

Then click through to lists of companies who have seen or tried a feature, so you know who is best to reach out to for feedback.

We surface all recent feedback on the Monitor tab, too, including satisfaction scores and feedback text alongside the user’s name and account.

The Monitor tab replaces STARS with a simplified view that combines the prior Adopted and Feedback tabs into a single page, alongside new metrics like Exposed.

For more details, check out the documentation or select a feature under Features to try out the Monitor tab for yourself.

We’ve added a new company filter option: before/after date.

The filter options can be used with any date attribute, including First seen and Last seen company attributes, as well as First track and Last track feature metrics.

For example, you can create a segment to give feature access to all companies that were first seen after a particular date. This is useful if you need to roll out a new product experience to new users, while phasing out the old one for existing users.

We’ve shipped some subtle but important simplifications to the Access tab for feature flags. Here’s what has changed:

• Moved stage picker into the sidebar - So it’s out of the way of the main area for access control.
• Added stage picker to confirmation dialog - We found that after making access changes that involved moving the feature to the next stage of its lifecycle, we’d sometimes forget to update the stage. Because of that, the stage picker now appears in the confirmation dialog once you’re ready to save the access changes you’ve made.
• Showing access history in targeting - We’ve had flag access version history for a while, but it was hidden away. To make it more accessible, we’re now listing the version history below the targeting area on the Access tab.