Changelog

For flags to be frictionless they need to work well with the tools you already use. That’s why we’re building deep integration between Bucket and Linear, to connect flags with the tool you use to plan and build new features.

Bucket agent for Linear

To start, we’ve partnered with Linear on the launch of Linear for Agents. With the Bucket agent, you can create and manage feature flags and update access rules directly from Linear. 

For example, if you’ve built a “Download CSV” feature and want to create a flag for it, mention @bucket with "create flag" in a comment on Linear. The Bucket agent will then do it for you, creating a feature key on bucket.co with a relevant name.

Want to change who can access that feature? Drop @bucket a note, like 'release this feature' or 'give Acme access to this feature' from within a relevant issue.

Send access change notifications to Linear

To keep your team up to date with which features are enabled, for who, and what stage a feature is in, you can automatically share access changes.

Whenever a feature targeting rule is updated, a new comment is added to the linked Linear issue or project showing what changed.

Get started

To connect Bucket with your Linear account, navigate to the Integrations section for your organization and use the "Connect to Linear" button to initiate the authorization process. For help configuring the integration, check out our docs.

In cooperation with Vercel we’ve launched a native Flags SDK adapter for Bucket.

The Flags SDK is an open-source library that gives developers tools to integrate feature flags in Next.js applications.

You can now use it with Bucket as the provider. The SDK sits between your application and Bucket, giving you a flexible way to control features at runtime without redeploying.

Bucket provides the evaluation logic for flags and the flags you define on Bucket show up in the Vercel toolbar. You can also see flag metadata like descriptions in the Flags Explorer.

We're excited to remove a little friction from using feature management with Next.js apps. Get started by adding the Bucket provider using the @flags-sdk/bucket module. Install it with:

npm install @flags-sdk/bucket

Check out the docs, or find out more about using Bucket with Next.js.

Happy flagging!

Today, we're excited to announce a major upgrade to the Bucket MCP: a fully hosted remote service. So you no longer need to run a local MCP server through the CLI. The server config is now:

{
  "mcpServers": {
    "Bucket": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "https://app.bucket.co/api/mcp?appId=<YOUR APP ID>"
      ]
    }
  }
}

About Bucket MCP

Model Context Protocol (MCP) lets an LLM interact with external data, in this case the Bucket API. With Bucket MCP you can flag features directly from the chat window in your code editor.

To create a new flag, for example, ask the MCP to do it for you: “flag feature X with bucket.”

Bucket MCP will then create a feature key on bucket.co with a relevant name and give you IDE's LLM context to flag the feature in the codebase. You can edit feature access rules, too, with something like “give Acme access to feature X.”

What's New

With our latest update, the remote Bucket MCP brings several key improvements:

• Instant setup: No more local server setup required—just connect and start flagging.
• HTTP streaming: Enhanced real-time communication using the latest streaming tech.
• Secure OAuth: A simple and secure authentication flow.
• Auto updates: The MCP now gets automatic updates and improvements without local maintenance.

For existing CLI users: The mcp command has been repurposed to help you set up the remote connection. It now guides you through the configuration for your chosen editor, be it Cursor, Visual Studio Code, Claude Desktop, or Windsurf, rather than running a local server.

To get started with the remote Bucket MCP in your IDE, check out our updated instructions.

Happy prompting!

Launched in beta a few weeks ago, Remote Config is now Generally Available (GA).

Remote Config is a dynamic and flexible, JSON-based approach to configuring feature behavior outside of your app — without redeployment. For example, you can use configs to configure AI models for your customers at runtime.

Getting started with Remote Config

To get started, you need to first upgrade to the latest version of our SDKs.

For example, in the React SDK, you can use config when using useFeature:

function AISummarizerRemotelyConfigured({copy}: {copy: string}) {
  const { config: { payload } } = useFeature('my-ai-feature');

  return <AISummarizer message={payload.message} provider={payload.provider} />
}

Then you configure the values you want from within the Bucket app.

In the image above, a feature is set up to have three config values. This is an example of configuring  LLM settings for an AI feature. The "gpt-4o" value is the default and served with all requests that do not match any other, more specific values. The "claude-3-7-sonnet" value will be served to users in "Apex" and "Blaze" companies while the "gpt-5" value will be served to the "Adrian Borer" user as well as the "Logix" and "Hightrix" companies.

Remote config can be used for basic feature configuration, multi-variate feature flags, and to support entitlement scenarios. To learn more about Remote Config, go to the documentation.

Happy shipping!

Bucket sends out notifications to Slack whenever a feature targeting rule is updated. These notifications play an important role in making sure the rest of your team understands which features are enabled for which customers and what stage the feature is in.

We just improved the way those notifications work on Bucket. From now on, they’ll only show what changed.

We’re constantly striving to make feature flagging as frictionless as possible. To that end, we’ve just released the Bucket MCP in beta.

Model Context Protocol (MCP) lets an LLM interact with external data, in this case the Bucket API.

So with Bucket MCP you can flag features directly from the chat window in your code editor. Whether that’s VS Code, Cursor, Windsurf, Claude—any IDE that has MCP support.

For example, if you’ve built a “Download CSV” feature and want to flag it, you no longer have to go to bucket.co or use the CLI to create a feature key.

Instead, ask the MCP to do it for you: “flag the download button with bucket.”

The Bucket MCP will then create a feature key on bucket.co with a relevant name and provide the context needed so your IDE's LLM will flag the feature in the codebase.

Here’s what it looks like in action:

As shown in the video, you can also use Bucket MCP to grant company segments and individual companies or users access to the feature—straight from the chat window.

To give “Acme” access, for example, you’d ask something like: “give Acme access to the download csv feature” and Bucket will look up the company name and enable the Download CSV feature for it.

To get started, add the Bucket MCP in your IDE. Here are instructions on how to do that.

Happy prompting!

One of the most annoying things about feature flags is the maintenance work of cleaning them up when you’re done with them. 

The code cleanup changes are mostly straightforward, but the task management, the context switching, waiting for tests to complete and code review all makes it a frustrating chore. Especially when you’re itching to get started on the next sweet feature.

Because of the maintenance frustration, most teams don’t clean up flags consistently. Which means you end up carrying around a bunch of useless code that is no longer being used that adds friction and frustrating errors when working on the code base.

Cleaning up feature flags takes time and focus away from building what matters, but avoiding cleaning them up is problematic, too. So we built Bucketbot.

Bucketbot

Bucketbot is a bot for GitHub that automatically cleans up feature flags once features have been rolled out.

After roll out, you can trigger Bucketbot to clean up the feature flag. Bucketbot will look through your code and submit a pull request to your repository on GitHub, cleaning up the flag and removing any code that is no longer needed.

It’s currently in Early Access. Sign up if you want to be included.

Happy zero-maintenance flagging!

The Event log shows the data your application sends to help you see if everything is set up correctly, and we’ve just made it more powerful.

The updated event log shows all events collected –  evaluate, check, user, company and track – and lets you filter by any of them. 

Here’s a quick recap of what the various event types are for:

• Evaluate: this denotes that a feature’s access rules were evaluated against a user/company context.
  
• Check: your application code used the result of this evaluation to make a choice of enabling or disabling the feature for a user.
  
• User: a user has been created or updated.
  
• Company: a company has been created or updated.
  
• Track: a user has interacted with a feature.

Event details

Clicking on an event will open the sidebar which shows more details about the event.

For evaluate and check events, the sidebar shows the context that was used in the evaluation to determine whether or not the user should have access to the feature. If any context is missing to perform the evaluation, the Event log will highlight it.

For all events, you’ll also see which SDK client version was used to send the event.

Happy debugging!

We’ve shipped the Bucket toolbar. As a developer or product manager, it’s useful to toggle features on and off for yourself when testing your own (or team members) features.

The toolbar is built into our browser SDKs and will automatically appear when you visit “localhost” if the Bucket Browser SDK or Bucket React SDK is installed in the website.

For many, it makes sense to enable it in production for internal use. Setting “toolbar” to true will make the toolbar appear:

function App() {
  const user = useAuth();

  return (
    <BucketProvider toolbar={user?.isAdmin}>
      <Routes>
    </BucketProvider>
  )
}

Happy shipping!

We have shipped a command line interface (CLI) that you can use to interact with Bucket. The CLI removes any friction in creating features from the command line and helps you maintain type safety for your features:

› npm i @bucketco/cli --save-dev 
› bucket new "My Feature"

When creating a new feature, the CLI will automatically update your local types to make sure they match those defined in Bucket, saving you from making frustrating typos referencing your feature keys.

The CLI will also generate types for Remote Config based on the payloads configured in Bucket. This helps ensure that the shape of the payload you’ve configured in Bucket matches what you’re working with in the code.

function MyFeature() {

  // The feature key argument passed to the useFeature hook is strongly
  // typed and will give a compile-time error if the key does not exist.
  const { isEnabled, config } = useFeature("my-feature");

  if (!isEnabled) return null;

  // Given the following payload configured in Bucket:
  // {
  //   fontWeight: "bold",
  //   copy: "Sync now!"
  // }
  //
  // The CLI will generate the type:
  // {
  //   fontWeight: string;
  //   copy: string;
  // }
  //
  // Which will give a compile-time error when we refer to
  // the missing "fontBold" property below.
  return (
    <button style={{fontWeight: config.payload.fontBold}}>
      {config.payload.copy}
    </button>
  )
}

Happy shipping!