Boolean Flags and Rollout Functionality

Today we’re happy to announce the release of v1.24.0 of Flipt including a few major features including:

• A new boolean flag type that can be used in combination with flag rollouts allowing you to enable a flag over a percentage of your user base and more
• A new, more straightforward set of evaluation API routes that you can also enable/disable authentication separate from the existing ‘management’ APIs
• The ability to add user email addresses to an allowlist when setting up OIDC authentication
• Improved performance and efficiency in flag evaluation with cache enabled
• New Amazon S3 filesystem backend support to serve your flags directly from an S3 bucket

Boolean Flag Type and Rollouts

Previously, Flipt was designed with only a single flag ‘type’ in mind, a flag which can be enabled/disabled and optionally have variants that can be returned during evaluation time. While this worked well for many use cases, we recognized the need for more flexibility. With the introduction of the new boolean flag type, you can now enable a flag over a percentage of your user base more easily. This allows for better experimentation and targeted rollouts.

The variant flag type is still the default flag type, allowing you to use flags in the same way as before. The new boolean flag type adds an extra layer of versatility. Boolean flags work hand in hand with a new abstraction that we call 'rollouts' or 'rollout rules'.

Rollouts work similarly to rules used during evaluation of a variant flag in that the first rule that matches ‘wins’, however there are a few key differences:

1. Rollouts are only allowed for boolean flag types and allow you to return a different value for a flag’s enabled property.
2. There are currently two types of rollouts: threshold and segment. Segment rollouts work just like previous rules in that you specify a segment that you want the rule to match. Thresholds, in contrast, are used to return a different result to a percentage of requests.
3. Rollouts allow you to specify the value to return for a boolean flag, either true or false.

It’s perhaps easier to show an example of the problem that boolean flags and rollouts were added to solve, by showing how you would have had to configure Flipt pre-v1.24.0 without rollout support and then how you would do the same now.

Imagine the following scenario:

You have a feature in your application that you want to roll out in stages to all users. Before the release of v1.24.0 of Flipt, you would have had to:

1. Create a flag with true and false variants, or on/ off or similar
2. Manually handle these variants in your application code, converting them to booleans, since variants can only be strings.
3. Configure a segment with constraints that matches the segment you want to target (ie: all-users)
4. Create an evaluation rule which returns the true variant to X% of requests, and the false to the remaining percentage.

As you can see , managing rollouts with boolean flags in Flipt used to be quite complex. However, with the release of v1.24.0, the process has become much simpler and more intuitive.

Now, to achieve the same rollout scenario, you can follow these steps:

1. Create a boolean type flag. This flag will represent the feature you want to roll out.
2. Configure a threshold-based rollout, specifying the percentage of requests that should receive the flag enabled. The remaining percentage will receive the flag disabled.
3. Thats it! 🎉 You can now use the flag in your application code as a boolean value.

Not only are boolean flags easier to setup for this scenario, they are also easier to update in place in the UI. You can now simply drag the slider or manually input the percentage in the rollout input box and click update to increase or decrease the percentage over time!

Evaluation API Routes and Security Configuration

While designing and implementing boolean flags, we also took the time to see how we could make evaluation more intuitive to support both flag types. We decided to create a new set of evaluation API routes, separate from the existing /api/v1 prefix that can work with both variant and boolean flags.

Several users have previously asked how to separate the ‘management’ API (created/edit/delete flags and other resources) from the ‘evaluation’ API as they serve two distinct audiences. Normally the ‘management’ API is used by team members to setup Flipt resources and should not be exposed publicly. Depending on a team’s application architecture however, they may need to evaluate flags from ‘untrusted’ and unauthenticated requests, such as when using feature flags directly from a browser based application.

Before this release, our only answer was to suggest putting Flipt behind a reverse proxy such as Caddy or Nginx and configuring access rules there. While we still think reverse proxies are a good idea for handling things such as request routing, rate limiting, and more, v1.24.0 of Flipt now separates the ‘management’ and ‘evaluation’ APIs completely and allows the operator to enable or disable authentication for each independently. We think that this new set of evaluation APIs and authentication configuration will allow Flipt to work for a larger variety of applications and use cases than before.

Checkout the new evaluation API documentation as well as all of our updated clients which now also support these new endpoints!

We also added the ability to configure allowed_emails when setting up OIDC Authentication for Flipt. This addition was driven by a user request to be able to configure specific users within their organization to have access to Flipt when configuring authentication with Google.

Note: in order for this feature to work properly, make sure you specify the email scope when configuring your OIDC setup for Flipt.

Improved Performance, S3 Backend and more

Finally, we've merged two amazing user-contributed PRs which made significant improvements to flag evaluation performance and efficiency as well as added support for serving flag state straight from an S3 bucket!

Faster Evaluation

With cache enabled, the evaluation of variant flags has become even quicker as we now cache potential constraints that would match a request at the storage layer, meaning they can be used across different entityIds.

From the PR:

after some investigation we found the main cause of delays in evaluation requests were the rules query, in our case running Flipt with a PostgreSQL DB on AWS RDS we were getting up to 1s of delays, with this fix it reduced to a few milliseconds

We consistently aim to keep Flipt fast for our users, and thus your users so we very much appreciate any contributions that help improve performance!

Flag State Not Just for Git Anymore

Last but certainly not least, Flipt now supports the use of Amazon S3 as a filesystem backend to serve your flags directly from an S3 bucket or set of buckets.

In v1.23.0 of Flipt we released a new set of experimental features allowing our users to manage their Flipt state. We strongly believe that feature flags should be treated like any other application configuration in our your infrastructure, which means you should also be able to use industry best practices such as managing configuration via CI/CD pipelines with GitOps. We also recognize however that every organization is different and so we’re delighted to now support Amazon’s S3 as an alternative filesystem backend!

This was another amazing user contribution. Here’s the reasoning for the feature straight from the PR:

In an AWS environment, this would allow deploying a readonly container and not require communication to a git repository outside of the deployment environment.

This feature opens up the door for us to implement other object stores such as Azure Blob Store and Google Cloud Storage as well, so please open an issue if you’d like us to support those backends as well!

That’s a Wrap

This release is our most feature packed yet! We’re delighted to add functionality that makes Flipt better for all of our users, and love the community contributions we’ve gotten so far this summer.

As always, feel free to reach out on Twitter (X?), Discord, or open a GitHub issue for any functionality that you’d like to see implemented. We’d also love to answer any questions or just chat about software delivery in general.

Checkout the full changelog, and give the latest release a look and let us know what you think!