We ship product updates weekly. Follow us on 𝕏 for the latest.
We’ve just added remote feature configuration to Bucket. A dynamic, flexible approach to configuring feature behavior outside of your app – without needing to re-deploy it.
For example, you can use configs to configure AI models for your customers at runtime. With remote config, you can safely upgrade customers to the latest AI model or you can try different models for different segments of customers. If a new model is causing quality issues, you can easily roll back to a previous version.
You can also use configs to manage things like in-app copy. This means non-engineers can update the application on their own without touching the codebase.
Let’s say you’re using GPT-4o in your application and want the option to easily upgrade all or some customers to the latest version as soon as it arrives. Furthermore, you want to be able to give certain customers access to a competing model, Claude 3.7, to see if it outperforms GPT-4o.
Remote Config is based on JSON and is therefore highly flexible. You can decide which JSON payload to send to your application.
Here’s an AI configuration example:
All customers get gpt-4o
from OpenAI as default except the two customers – Apex and Blaze – which get claude-3-7-sonnet
from Anthropic.
When gpt-4o
gets upgraded to the next version by OpenAI, you can simply go here to update the payload, or you can add a new, small beta segment to test the new OpenAI version, like so:
To get started with Remote Config, you need to first upgrade to the latest version of our SDKs.
In the React SDK you can now use config
when using useFeature
:
const { config } = useFeature("sent-chat-message");
‍
As per our example in the screenshot above, if you’re authenticated as Adrian Borer or any user in the Logix or Hightrix companies, you’ll get this config:
If you want to get user feedback on the models, you use Bucket’s requestFeedback
, like so:
All feedback will be sent to the Feedback tab, right next to Remote Config, as well as to Slack, if you choose to.
To learn more about Remote Config, check out our documentation.
Happy shipping!
By default, when you create a new feature on Bucket, we'll suggest a feature key derived from the name. The format of the key is kebab-case
by default. However, you may prefer to use a different naming convention. In some cases, it's just that you're used to SNAKE_UPPER_CASE
from previous feature flagging providers. In other cases, a specific format might work better for the programming language of your choice.
Now you can define your feature key naming convention when creating a new feature. You can always customize the name of the key, but when picking a naming convention, Bucket will then enforce that new keys adhere to it.
When you create a feature today, the feature becomes available for use in your browser application through Bucket SDKs. That means the feature is retrievable through our public facing API using a publishable key. For most features, this is desirable because it lets you toggle features in your app UI. It also lets you build integrations right in your app.
However, once in a while you're working on something you need to keep secret from everyone. For this use-case, we've made it possible to mark features as secret
on Bucket. Secret features are not retrievable with a publishable key — only with a secret key. That means you can use a feature on your backend and ensure that the feature key is never revealed to any users.
‍
When browsing companies or users, it’s much more fun to see company logos or user avatars, rather than randomly generated avatars.
So, we’ve shipped support for it!
‍
If you send the company logo URL as the avatar
attribute on a company, we’ll display it in the UI. Similarly with avatars for users.
More updates soon!
‍
We’re always trying to make things simpler. As such, we’ve renamed the feature tabs and split them into tabs that each represent a clear use case. We’ve also improved the onboarding instructions per use case.
First, we’ve renamed the “Targeting” tab to “Access”, which is easier to understand.his tab is all about controlling feature access.
Secondly, we’ve split “Analyze” into “Adoption” and “Feedback” to provide both of those use cases with more real estate.Â
Here’s the new feature tabs – simple!
The feedback tab includes a list of the latest feedback and a new satisfaction timeline that lets you easily track feature satisfaction trends over time.Â
The satisfaction timeline gives you a rolling average of satisfaction scores for a feature alongside qualitative feedback. It’s a simple way to visualize overall feature satisfaction, evaluate whether a feature needs an iteration, and then track an iteration’s impact on satisfaction.
You can select different evaluation periods and timing windows to track the impact of feature iterations on satisfaction.
We’ve also added specific instructions and code examples to each tab so they’re relevant to each stage of the release process.Â
When creating a feature, you're usually early in the development process and are only looking to implement a feature flag. That’s why the code example in the Access tab only contains the feature key.Â
When you’ve reached the beta or general availability rollout stage, you’ll likely add adoption tracking and feedback collection.Â
The code example in the Feedback tab looks like this:
Happy shipping!
You can now toggle features access directly on the company pages. This makes it even simpler to grant individual companies access to features in the Bucket UI.
In B2B, customers get feature access based on the subscription plan. However, it’s not unusual for them to be given access to features outside of their set subscription.
You can now grant individual companies access to features by flipping a toggle on the company page.
Another practical use case for toggles is enrolling early adopters into the Beta stage of a new feature.
Feature toggles don’t alter your existing feature targeting rules. They simply add additional companies to the targeting rules, which is useful for granting ad-hoc access without changing the core targeting rules of a feature.
Note: You cannot use feature toggles to disable feature access granted by targeting rules.
Happy toggling!
You can now use our adoption metrics and automated feedback surveys through OpenFeature.
OpenFeature is a small code layer that acts as an intermediary between your code and a feature flagging provider, letting you experiment with different providers with minimal changes to your codebase. Â
OpenFeature recently added the Tracking API, which allows developers to send tracking events to providers whenever a user does something noteworthy.Â
We’ve updated our OpenFeature Node.js SDK and OpenFeature Browser SDK to support this new API directly, making it easier to leverage our adoption metrics and feedback collection features if you use OpenFeature.
Happy shipping!
We’ve added support for deep linking to the Bucket app.
Simply replace the environment name and ID in the URL with “/current/”.Â
For example, https://app.bucket.co/envs/current/features will direct you to the feature tab in Bucket.
This has also allowed us to directly link to the Bucket app in our documentation, making it easier to find the tabs or pages you need.
Happy shipping!Â
We’re into the 4th week of polishing our UI, SDKs, and backend as part of our commitment to making a world-class product.Â
We’re back after taking last week off to put together our roadmap for 2025 at our offsite in Berlin.
Here’s what we polished this week:
SDKVersion
and ServiceName
to feature flag events to make them simpler to debugrequestFeedback
With polish season coming to an end, this everything we've shipped over the past 4 weeks to make Bucket a robust, reliable, and intuitive product.
user
and company
details to Bucket when either bindClient
or getFeature(s)
calls are made. This ensures that up-to-date information is pushed to Bucket so companies can be used immediately. Previously, you had to call updateCompany
and updateUser
manually.enableTracking
option to disable the sending of track
, user
, company
, and flag
events. This is useful when you’re impersonating other users, for example.Happy shipping!
The targeting UI is one of the most important screens in feature management tools, our ambition is to make the world's best targeting UI for B2B SaaS.
In speaking to users, it became clear that almost all B2B targeting rules focus on either specific companies or a segment of companies. Bucket company-level aggregation and segments make this simple, so we doubled down on these common use cases.
We’ve simplified the targeting UI to make it more intuitive. We’ve added three presets:Â
These presets let you set targeting rules for features in the click of a button.
We’ve made defining the “Some” targeting rules simple while optimizing for the most common B2B use cases. You can add segments, individual companies, and individual users by simply clicking an “Add” button.
The whole team can be alerted to targeting rules updates through the Slack integration. A summary of all the targeting rule updates can be shared in the Slack channel of your choice.Â
You can also still create advanced targeting rules when you need them with the "+ Add Rule" button.
Advanced rules let you specify rollout percentages and create targeting rules using company attributes, user attributes, feature targeting, or other contexts.
This is a great example of how Bucket’s focus on B2B lets us create a simpler product without sacrificing functionality.
Happy shipping!