Minimum version
You can configure a feature toggle to require a minimum version before being enabled in an environment. The toggle will be enabled once that version (or any later version) is deployed to that environment.
Tenants
If your project uses Tenants, you can configure a feature toggle to be enabled for subsets of your tenants within an environment.
There are many options for configuring a feature toggle for tenants. These are all modeled in Octopus and do not require any custom configuration in application code.
Excluded tenants
You can exclude tenants individually or exclude groups of tenants using tenant tags. Excluded tenants will always override any other rollout configuration, even if the rollout percentage is set to 100%.
Once a feature toggle is configured with an excluded tenant tag, any changes to tenant tag assignments apply immediately to feature toggles (no update to the feature toggle configuration is required).
Included tenants
You can enable feature toggles for individual tenants. These tenants will always be included, even if the tenant rollout percentage is set to 0%.
Tenant rollout
Tenant rollout allows you to enable a toggle for a pseudorandom percentage of all tenants.
The included tenants are determined using a MurmurHash of the tenant ID and a toggle-specific key. This guarantees deterministic evaluation for any given tenant and toggle combination, while ensuring that a different set of tenants is included for each toggle.
You can further restrict the rollout using tenant tags. For example, if you specify Region/Australia, Region/Europe, and Tier/Enterprise, a 50% rollout will only apply to 50% of Enterprise tenants in either Australia or Europe. If you do not specify any tenant tags, a 50% rollout will apply to 50% of all tenants.
As with excluded tenants, any changes to tenant tags apply immediately to feature toggles.
Client rollout
Client rollout allows you to enable a toggle for a random percentage of your application users. The included users are determined using a MurmurHash of the OpenFeature Targeting Key and a toggle-specific key. This guarantees deterministic evaluation for any given user and toggle combination.
To use client rollout, you must configure a targeting key in your OpenFeature client. Refer to the OpenFeature SDK documentation for your development language for details on how to set the targeting key. If you do not set a targeting key, the feature toggle will not be enabled for any users unless the rollout is set to 100%.
You should set the targeting key to a value that uniquely identifies your evaluation subject. For most applications, this will be a user identifier (such as a user ID), but you can use any identifier that suits your needs (for example, team, region, or server instance).
Support for client rollout percentages was added in the following versions of the provider libraries:
If you are not running the required minimum version of these libraries, the rollout percentage will be ignored (and handled as if the value was set to 100%).
Segments
Segments allow you to further refine the client rollout for a toggle based on data that is not modeled in Octopus. Segments are key/value pairs, and are supplied by your application via the OpenFeature evaluation context.
Like tenant targeting, segments are configured per-environment on the feature toggle in Octopus.
Refer to the OpenFeature SDK documentation for your development language for more details on how to set these values.
Common segment examples include:
- Specific users (e.g.
user-id/123456) - Specific accounts (e.g.
account-id/123456) - License types (e.g.
license-type/free) - Geographic regions (e.g.
region/eu) - Rollout rings (e.g.
ring/early-adopter)
A feature toggle evaluation will match on segments if the evaluation context matches at least one segment for each key. If you specify ring/early-adopter, region/eu, and region/au, the rollout will apply only to users in the early-adopter ring who are in either the EU or AU regions. If you do not specify any segments, the rollout will apply to all users.
Some examples:
| Segments | Evaluation Context | Result |
|---|---|---|
user-id/123456 | user-id/123456 | On |
user-id/123456 | user-id/789383 | Off |
ring/early-adopter, region/eu, region/au | ring/early-adopter, region/eu | On |
ring/early-adopter, region/eu, region/au | ring/early-adopter, region/au | On |
ring/early-adopter, region/eu, region/au | license-type/free | Off |
ring/early-adopter, region/eu, region/au | region/au | Off |
Rollout groups
By default, a percentage rollout on one feature toggle will include a different set of tenants or clients than the same percentage rollout on another toggle. This ensures the same tenants or clients are not always the first to receive every new feature.
Rollout groups let you connect rollout evaluation between multiple feature toggles so that the same tenants or clients are included in the rollout across those toggles. This can be useful when you have related features that should roll out to the same audience.
You can assign a rollout group to a feature toggle from the feature toggle page by selecting a group from the rollout group dropdown.
If you have a tenant or client rollout configured, adding, changing, or removing a rollout group on a feature toggle will change which tenants or clients are included in that rollout.
Managing rollout groups
You can manage rollout groups from the rollout groups page. To access this page, open the overflow menu on the feature toggles list page and select Manage Rollout Groups.
From the rollout groups page, you can add, rename, and delete rollout groups.
You cannot delete a rollout group that is assigned to one or more feature toggles. To delete a rollout group, first remove it from all feature toggles that use it.
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Friday, May 29, 2026