+
+
+
+### Assertion consumer service URL
+
+Each Flagsmith SAML configuration has its own Assertion Consumer Service (ACS) URL, also known as single sign-on URL. Your identity provider will post SAML messages to this URL when a user logs in using SSO. The ACS URL for any SAML configuration is as follows, replacing `flagsmith.example.com` with your Flagsmith API's domain:
+
+```
+https://flagsmith.example.com/api/v1/auth/saml/YOUR_SAML_CONFIGURATION_NAME/response/
+```
+
+## Attribute mapping
+
+Flagsmith will look for the following SAML attributes, in order, to uniquely identify a SAML user:
+
+- `subject-id`
+- `uid`
+- `NameID`
+
+Flagsmith also maps user attributes from the following claims in the SAML assertion:
+
+| Flagsmith attribute | Identity provider claim names |
+|---------------------|------------------------------------------------------|
+| Email | `mail`, `email` or `emailAddress` |
+| First name | `gn`, `givenName` or the first part of `displayName` |
+| Last name | `sn`, `surname` or the second part of `displayName` |
+| Groups | `groups` |
+
+To add custom attribute mappings, edit your SAML configuration and open the **Attribute Mappings** tab. For example,
+this mapping tells Flagsmith to look for user groups in a claim other than the default `groups` claim:
+
+Additional options when self-hosting Flagsmith
+ + **Frontend URL** should point to the base URL of the Flagsmith dashboard. It is automatically prefilled with the + URL of the dashboard you are currently using. You only need to change this if your users will access the Flagsmith + dashboard using a different URL than the one you are currently using—for example, if you are connecting to Flagsmith + via port forwarding or a VPN that your users do not typically use. + +
+
+
+
+
+
+
+
+
+
+
+
+
+## Governance and Compliance
+
+Ensure your feature flag practices meet compliance requirements and organisational governance standards.
+
+
+
+
+
+ User Management & Permissions
+Control user roles, groups, and fine-grained permissions
+
+
+
+
+ Authentication Management
+Set up authentication methods including SSO, SAML, LDAP, and 2FA
+
+
+
+
+ Enterprise SSO
+Single sign-on integration with SAML, Okta, LDAP, and Microsoft ADFS
+
+
+
+
+
+
+
+
+
+
+
+
+
+## Data Management
+
+Handle data migration, import/export operations, and backup strategies for your Flagsmith data.
+
+
+
+
+
+ Security Controls
+Platform security settings and best practices
+
+
+
+
+ Audit & Compliance
+Track changes and access for compliance auditing
+
+
+
+
+ System Limits
+Understand platform limits and request overrides
+
+
+
+
+
+
+
+
+
+
+## Platform Configuration
+
+Configure environment-specific settings and platform-wide options for your Flagsmith deployment.
+
+
+
+
+
+ Bulk Import & Export
+Mass operations for features, segments, and identities
+
+
+
+
+ Organisation Migration
+Migrate complete organisations between instances
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/docs/administration-and-security/platform-configuration/_category_.json b/docs/docs/administration-and-security/platform-configuration/_category_.json
new file mode 100644
index 000000000000..f4e818037002
--- /dev/null
+++ b/docs/docs/administration-and-security/platform-configuration/_category_.json
@@ -0,0 +1,5 @@
+{
+ "label": "Platform Configuration",
+ "position": 5,
+ "collapsed": true
+}
diff --git a/docs/docs/system-administration/environment-settings.md b/docs/docs/administration-and-security/platform-configuration/environment-settings.md
similarity index 86%
rename from docs/docs/system-administration/environment-settings.md
rename to docs/docs/administration-and-security/platform-configuration/environment-settings.md
index 3b911a1cb6df..7f27d3fab85f 100644
--- a/docs/docs/system-administration/environment-settings.md
+++ b/docs/docs/administration-and-security/platform-configuration/environment-settings.md
@@ -1,5 +1,7 @@
---
title: Environment Settings
+sidebar_label: Environment Settings
+sidebar_position: 10
---
## Use Consistent Hashing
@@ -20,4 +22,4 @@ split operator) when evaluated against the remote API. Evaluations in local eval
## Custom fields
Optional or required custom fields can be defined when creating or updating environments.
-[Learn more](/advanced-use/custom-fields.md)
+[Learn more](/administration-and-security/governance-and-compliance/custom-fields)
diff --git a/docs/docs/system-administration/metrics.md b/docs/docs/administration-and-security/platform-configuration/metrics.md
similarity index 97%
rename from docs/docs/system-administration/metrics.md
rename to docs/docs/administration-and-security/platform-configuration/metrics.md
index 7863a71ba34e..e58a4d14bec0 100644
--- a/docs/docs/system-administration/metrics.md
+++ b/docs/docs/administration-and-security/platform-configuration/metrics.md
@@ -1,5 +1,7 @@
---
title: Metrics
+sidebar_label: Metrics
+sidebar_position: 20
---
## Prometheus
diff --git a/docs/docs/administration-and-security/usage-graph.png b/docs/docs/administration-and-security/usage-graph.png
new file mode 100644
index 000000000000..d02fc58fb144
Binary files /dev/null and b/docs/docs/administration-and-security/usage-graph.png differ
diff --git a/docs/docs/advanced-use/_category_.json b/docs/docs/advanced-use/_category_.json
deleted file mode 100644
index 14a58ca30953..000000000000
--- a/docs/docs/advanced-use/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "Advanced Use",
- "position": 40,
- "collapsed": true
-}
diff --git a/docs/docs/advanced-use/ab-testing.md b/docs/docs/advanced-use/ab-testing.md
deleted file mode 100644
index 8d6052a462ad..000000000000
--- a/docs/docs/advanced-use/ab-testing.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: A/B Testing
----
-
-A/B testing enables you to experiment with design and functionality variants of your application. The data generated
-will allow you to make modifications to your app, safe in the knowledge that it will have a net positive effect.
-
-You can use Flagsmith to perform A/B Tests. Using a combination of
-[Multivariate Flags](/basic-features/managing-features.md#multi-variate-flags) and a 3rd party analytics tool like
-[Amplitude](https://amplitude.com/) or [Mixpanel](https://mixpanel.com/), you can easily perform complex A/B tests that
-will help improve your product.
-
-Running AB tests require two main components: a bucketing engine and an analytics platform. The bucketing engine is used
-to put users into a particular AB testing bucket. These buckets will control the specific user experience that is being
-tested. The analytics platform will receive a stream of event data derived from the behaviour of the user. Combining
-these two concepts allows you to deliver seamless AB test.
-
-We have [integrations](/integrations) with a number of analytics platforms. If we don't integrate with the platform you
-are using, you can still manually send the test data to the downstream platform manually.
-
-## Overview - Testing a new Paypal button
-
-For this example, lets assume we have an app that currently accepts Credit Card payments only. We have a hunch that we
-are losing out on potential customers that would like to pay with Paypal. We're going to test whether adding Paypal to
-the payment options increases our checkout rate.
-
-We have a lot of users on our platform, so we don't want to run this test against our entire user-base. We want 90% of
-our users to be excluded from the test. Then for our test, 5% of our users will see the new Paypal button, and the
-remaining 5% will not see it. So we will have 3 buckets:
-
-1. Excluded (Control) Users
-2. Paypal Test Button Users
-3. Test users that don't see the Paypal Button
-
-Because Flagsmith Flags can contain both boolean states as well as multivariate flag values, we can make use of both. We
-will use the boolean flag state to control whether to run the test. Then, if the flag is `enabled`, check the
-Multivariate value. In this example, we will only show the Paypal button if the value is set to `show`.
-
-## Creating the Test
-
-In order to perform the A/B Test, we need to complete the following steps:
-
-1. Create a new [Multivariate Flag](/basic-features/managing-features.md#multi-variate-flags) that will control which of
- the 3 buckets the user is put into. We'll call this flag `paypal_button_test`. We will provide 3 variate options:
-
- 1. Control - 90% of users
- 2. Paypal Button - 5% of users
- 3. Test users that don't see the Paypal Button - 5% of users
-
-2. In our app, we want to [identify](/basic-features/managing-identities.md) each user before they start the checkout
- process. All Flagsmith Multivariate flags need us to identify the user, so we can bucket them in a reproducible
- manner.
-3. When we get to the checkout page, check the `value` of the `paypal_button_test` flag for that user. If it evaluates
- to `show`, show the Paypal payment button. Otherwise, don't show the button.
-4. Send an event message to the analytics platform, adding the name/value pair of `paypal_button_test` and the value of
- the flag; in this case it would be one of either `control`, `show` or `hide`.
-5. Deploy our app, enable the flag and watch the data come in to your analytics platform.
-
-Here is what creating the Flag would look like.
-
-
-
-## Evaluating the Test
-
-Once the test is set up, and the flag has been enabled, data will start streaming into the analytics platform. We can
-now evaluate the results of the tests based on the behavioral changes that the new button has created.
-
-## Anonymous/Unknown Identities
-
-To do A/B testing you need to use Identities. Without an Identity to key from, it's impossible for the platform to serve
-a consistent experience to your users.
-
-What if you want to run an A/B test in an area of your application where you don't know who your users are? For example
-on the homepage of your website? In this instance, you need to generate _Anonymous Identities_ values for your users. In
-this case we will generate a _GUID_ for each user.
-
-A _GUID_ value is just a random string that has an extremely high likelihood of being unique. There's more info about
-generating GUID values [on Stack Overflow](https://stackoverflow.com/a/2117523).
-
-The general flow would be:
-
-1. A new browser visits your website homepage for the first time.
-2. You see that this is an anonymous user, so you generate a random _GUID_ for that user and assign it to them.
-3. You send that GUID along with an Identify call to Flagsmith. This will then segment that visitor.
-4. You add a cookie to the browser and store the GUID. That way, if the user returns to your page, they will still be in
- the same segment.
-
-These techniques will be slightly different depending on what platform you are developing for, but the general concept
-will remain the same.
diff --git a/docs/docs/advanced-use/change-requests.md b/docs/docs/advanced-use/change-requests.md
deleted file mode 100644
index 1820212672ca..000000000000
--- a/docs/docs/advanced-use/change-requests.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# Change Requests
-
-:::tip
-
-Change requests are part of our Scale-Up and Enterprise plans.
-
-:::
-
-## Overview
-
-You can use Change Requests to add workflow control to the changing of Flag values. Change Requests allow a user to
-propose a change to a flag value, and then require that change is approved by a number of other team members.
-
-You can use Change Requests to ensure that, for example, a change to a flag in Production has to be approved by another
-team member. They work in a similar way to Pull Requests in git.
-
-## Setting up Change Requests
-
-Change Requests are configured at the Environment level. To enable Change Requests, go to the Environment Settings Page,
-Enable the Change Request setting, and select how many approvals you would like for each Change Request to be applied.
-
-## Creating a Change Request
-
-:::info
-
-Any user that has permission to _Update_ a Feature within the Environment can create a Change Request
-
-:::
-
-Once an Environment is configured with Change Requests enabled, attempting to change a flag value will prompt you to
-create a new Change Request.
-
-You will need to provide:
-
-- The title of the Change Request
-- Optionally a description of the reason for the Change Request
-- Assigness - specify either individual users or members of a group. These users will receive an email alerting them of the Change Request
-
-## Approving a Change Request
-
-:::info
-
-Any user that has permission to write to the Environment containing the Change Request can approve it.
-
-:::
-
-Change Requests awaiting approval are listed in the Change Request area.
-
-Clicking on a Change Request brings up the details of the request, and the current and new Flag values.
-
-## Publishing a Change Request
-
-When the required number of approvals have been made, you will be able to publish the Change Request.
-
-The Change Request will immediately come into effect once the Publish Change button is clicked.
diff --git a/docs/docs/advanced-use/custom-fields.md b/docs/docs/advanced-use/custom-fields.md
deleted file mode 100644
index 4176fc085a25..000000000000
--- a/docs/docs/advanced-use/custom-fields.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Custom Fields
----
-
-:::info
-
-Custom fields are available on [Enterprise plans](/version-comparison.md#enterprise-benefits).
-
-Custom fields were introduced in Flagsmith [2.116.0](https://github.com/Flagsmith/flagsmith/releases/tag/v2.116.0).
-
-:::
-
-As your usage of feature flags grows, it helps to store additional information alongside different Flagsmith entities.
-For example, you might want to:
-
-- Relate every flag to a ticket in your issue tracker so that everyone knows what a flag does and what state of
- development it is in.
-- Add a link from Flagsmith segments to the corresponding segments in your analytics platform.
-- Add a detailed description to your Flagsmith environments.
-
-You can define **custom fields** that are shown when creating or modifying
-[**flags**](/basic-features/managing-features.md), [**segments**](/basic-features/segments.md) or
-[**environments**](/basic-features#environments). Custom fields are defined per
-[organisation](/basic-features#organisations).
-
-The following screenshot shows a custom field named "Ticket URL" that is displayed to Flagsmith users when editing or
-creating a feature:
-
-
-
-## Permissions
-
-Defining custom fields requires administrator permissions for a given project.
-
-Updating the values of custom fields requires edit permissions for the given entity.
-
-## Defining custom fields
-
-Custom fields can be defined in **Organisation Settings > Custom Fields**.
-
-Custom fields have the following properties:
-
-- **Name**: the visible name of the field as it will be presented to users.
-- **Description**: a short description of what the field is for. It is only shown when editing custom field definitions.
-- **Type**: validates this field's data when saving to be one of the following types:
- - **String**: A single line of text.
- - **Multi-line string**: One or more lines of text.
- - **Integer**: Whole numbers without a decimal point.
- - **Boolean**: A binary choice between true or false.
- - **URL**: An absolute URL with an explicit scheme as defined by Python's
- [urlparse](https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlparse) function. For example,
- `https://flagsmith.com` is considered valid but `/example/foo` is not.
-- **Entities**: Which Flagsmith entities to display these fields for during creation or editing. The following options
- are allowed:
- - Features
- - Segments
- - Environments
-- **Required**: Lets you choose whether a field is required for each entity it is associated with. For example, you
- could make a ticket URL required for features but optional for segments.
-
-## Modifying existing fields
-
-Field data types are only validated when saving. Modifying existing field data types will not delete or modify existing
-data.
-
-Changing an optional field into a required field will prevent you from creating or updating the relevant entities
-without providing a value for that field.
-
-Deleting custom fields will also delete all data associated with that field.
-
-## Consuming custom fields
-
-Custom fields are mainly intended to be read by humans visiting the Flagsmith dashboard, typically for traceability or
-accountability purposes.
-
-Custom field values associated with features belong to the features themselves, and not an environment's feature state;
-you cannot override custom field values in different environments, segments or identities. They are not returned to
-applications that consume flags.
-
-Custom field values are added directly to the `metadata` field of the entity they are defined in, which can be read
-using the [Flagsmith Admin API](/clients/rest#private-admin-api-endpoints). For example, to fetch a feature's custom
-fields, use the
-[endpoint to fetch a feature by ID](https://api.flagsmith.com/api/v1/docs/#/api/api_v1_projects_features_read):
-
-```shell
-curl "https://api.flagsmith.com/api/v1/projects/YOUR_PROJECT_ID/features/YOUR_FEATURE_ID/" \
- -H "Authorization: Api-Key YOUR_API_KEY"
-```
-
-This returns information about the feature itself, including `metadata` which contains the custom field values:
-
-```json
-{
- ...
- "metadata": [
- {
- "id": 123,
- "model_field": 128,
- "field_value": "https://example.com/FOO-123"
- },
- {
- "id": 124,
- "model_field": 129,
- "field_value": "Example Team"
- }
- ]
-}
-```
-
-To fetch the field definitions themselves, use the
-[endpoint to fetch metadata model fields](https://api.flagsmith.com/api/v1/docs/#/api/api_v1_organisations_metadata-model-fields_list).
-For example:
-
-```shell
-curl "https://api.flagsmith.com/api/v1/organisations/YOUR_ORGANISATION_ID/metadata-model-fields/ \
- -H "Authorization: Api-Key YOUR_API_KEY"
-```
-
-This returns the definition of each custom field:
-
-```json
-{
- "count": 2,
- "next": null,
- "previous": null,
- "results": [
- {
- "id": 178,
- "name": "Ticket URL",
- "type": "url",
- "description": "URL to ticket in our issue tracker",
- "organisation": 15467
- },
- {
- "id": 179,
- "name": "Product code",
- "type": "int",
- "description": "Product code associated with this feature",
- "organisation": 15467
- }
- ]
-}
-```
diff --git a/docs/docs/advanced-use/edge-proxy.md b/docs/docs/advanced-use/edge-proxy.md
deleted file mode 100644
index d67108555527..000000000000
--- a/docs/docs/advanced-use/edge-proxy.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: Edge Proxy
----
-
-The Flagsmith Edge Proxy is a service that you host yourself, that allows you to run an instance of the Flagsmith Engine
-close to your servers. If you are running Flagsmith within a server-side environment and you want to have very low
-latency flags, you have two options:
-
-1. Run the Edge Proxy within in your own infrastructure and connect to it from your server-side SDKs
-2. Run your server-side SDKs in [Local Evaluation Mode](/clients#local-evaluation).
-
-The main benefit to running the Edge Proxy is that you reduce your polling requests against the Flagsmith API itself.
-
-The main benefit to running server side SDKs in [Local Evaluation Mode](/clients#local-evaluation) is that you get the
-lowest possible latency.
-
-## How does it work
-
-:::info
-
-The Edge Proxy has the same [caveats as running our SDK in Local Evaluation mode.](/clients/#local-evaluation).
-
-:::
-
-You can think of the Edge Proxy as a copy of our Python Server Side SDK, running in
-[Local Evaluation Mode](/clients#local-evaluation), with an API interface that is compatible with the Flagsmith SDK API.
-
-The Edge Proxy runs as a lightweight Docker container. It connects to the Flagsmith API (either powered by us at
-api.flagsmith.com or self hosted by you) to get Environment Flags and Segment rules. You can then point the Flagsmith
-SDKs to your Edge Proxy; it implements all the current SDK endpoints. This means you can serve a very large number of
-requests close to your infrastructure and users, at very low latency. Check out the [architecture below](#architecture).
-
-The Proxy also acts as a local cache, allowing you to make requests to the Proxy without hitting the core API.
-
-## Performance
-
-The Edge Proxy can currently serve ~2,000 requests per second (RPS) at a mean latency of ~7ms on an M1 MacBook Pro with
-a simple set of flags. Working with more complex Environments with many Segment rules will bring this RPS number down.
-
-It is stateless and hence close to perfectly scalable being deployed behind a load balancer.
-
-## Managing Traits
-
-There is one caveat with the Edge Proxy. Because it is entirely stateless, it is not able to persist Trait data into any
-sort of datastore. This means that you _have_ to provide the full complement of Traits when requesting the Flags for a
-particular Identity. Our SDKs all provide relevant methods to achieve this. An example using `curl` would read as
-follows:
-
-```bash
-curl -X "POST" "http://localhost:8000/api/v1/identities/?identifier=do_it_all_in_one_go_identity" \
- -H 'X-Environment-Key: n9fbf9h3v4fFgH3U3ngWhb' \
- -H 'Content-Type: application/json; charset=utf-8' \
- -d $'{
- "traits": [
- {
- "trait_value": 123.5,
- "trait_key": "my_trait_key"
- },
- {
- "trait_value": true,
- "trait_key": "my_other_key"
- }
- ],
- "identifier": "do_it_all_in_one_go_identity"
-}'
-```
-
-Note that the Edge Proxy will currently _not_ send the Trait data back to the Core API.
-
-## Deployment and Configuration
-
-Please see the [hosting documentation](/deployment/hosting/locally-edge-proxy).
-
-## Architecture
-
-The standard Flagsmith architecture:
-
-
-
-With the proxy added to the mix:
-
-
diff --git a/docs/docs/advanced-use/flag-analytics.md b/docs/docs/advanced-use/flag-analytics.md
deleted file mode 100644
index 06d9176f728e..000000000000
--- a/docs/docs/advanced-use/flag-analytics.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Flag Analytics
----
-
-## Overview
-
-Flag Analytics allow you to track how often individual Flags are evaluated within the Flagsmith SDK.
-
-To view Analytics for a particular flag, browse to the relevant environment and click on a single flag to edit that
-flag.
-
-
-
-Flag Analytics can be really useful when removing flags from Flagsmith. More often than not, flags can be removed from
-your codebase and platform once they have been rolled out and everyone is comfortable with them running in production.
-
-Once you have removed the evaluation code from your code base, its nice to be sure that all references to that flag have
-been removed, and that removing the flag itself from Flagsmith will not cause any unforeseen issues. Flag Analytics help
-with this.
-
-Flag Analytics can also be helpful when identifying integration issues. Occasionally errors can creep into your code
-that cause multiple needless evaluations of a flag. Again, these analytics can help isolate these situations.
-
-## Enabling Flag Analytics?
-
-:::info
-
-The Flag Analytics data will be visible in the Dashboard between 30 minutes and 1 hour after it has been collected.
-
-:::
-
-Flag analytics are disabled by default in our SDKs. You need to explicitly enable it when you initialize the Flagsmith
-client. Please refer to the corresponding SDK documentation for more details. For the Javascript family SDKs please
-refer to [Initialisation options](https://docs.flagsmith.com/clients/javascript#initialisation-options).
-
-## How does it work?
-
-Every time a flag is evaluated within the SDK (generally a call to a method like
-`flagsmith.hasFeature("myCoolFeature")`), the SDK keeps a track of the flag name along with an evaluation count.
-
-Every `n` seconds (currently set to 10 seconds in the JS SDK) the SDK sends a message to the Flagsmith API with the list
-of flags that have been evaluated and their count. If no flags have been evaluated in that time window, no message is
-sent.
diff --git a/docs/docs/advanced-use/flag-management.md b/docs/docs/advanced-use/flag-management.md
deleted file mode 100644
index e8da7a97ae76..000000000000
--- a/docs/docs/advanced-use/flag-management.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Flag Management
-
-Managing larger numbers of flags is made easier using some of the tools built into Flagsmith.
-
-## Tagging
-
-You can create tags within Flagsmith and tag Flags in order to organise them. Tags can also be used to filter the list
-of Flags in the event that you have a large number.
-
-:::info Protected Tags
-
-Tags with the following names will prevent users from being able to delete tagged Flags via the dashboard:
-
-- `protected`
-- `donotdelete`
-- `permanent`
-
-:::
-
-## Server-side only Flags
-
-When creating a flag, you can optionally define it as "Server-Side Only". Enabling this option for the flag will prevent
-it from being returned to Client-side SDKs.
-
-## Hide disabled Flags from SDKs
-
-To prevent letting your users know about your upcoming features and to cut down on payload, enabling this will prevent
-the API from returning any flags that are disabled.
-
-You can set this at both the Project and Environment level.
-
-## Flag Archiving
-
-You can also archive Flags within Flagsmith. Archived flags will continue to be sent to your SDKs when you get the flags
-for your Environment, but by default they are hidden from the main list of flags.
-
-You can set a Flag as Archived from the Flag settings tab.
-
-Archived flags are often used when you have customers running older versions of your mobile app. You may well have
-finished with a flag, but you can't remove it as there are still some older versions of your app out there that depend
-on that flag. Archiving the flag helps to keep your main list of flags under control.
-
-## Case Sensitive Flags
-
-By default, Flagsmith stores flags with lower case characters in order to minimise human error. If you want to store
-flags in a case-sensitive manner you can do this as a Project-wide setting from the Project Settings page.
-
-:::tip
-
-We don't recommend making your Flags case sensitive. This can lead to bugs related to case sensitivity and flags not
-being found at runtime.
-
-:::
-
-## Feature Name Regular Expressions
-
-You can enforce feature name String formatting by way of a regular expression in the Project Settings area. If you want
-flags to always be lower case, or camel case, or whatever your preference, you can set it here.
-
-## Flag Owners
-
-You can specify members of your team as owners of individual Flags. This helps in larger teams when you need to identify
-who is responsible for a particular flag.
-
-## Flag Defaults
-
-By default, when you create a feature with a value and enabled state it acts as a default for your other Environments.
-In the Project Settings page, you have the option of enabling the setting 'Prevent flag defaults' to prevent this
-behaviour. When this setting is enabled the user is not able to provide defaults when creating the feature. The feature
-will be created with an empty value and will be turned off in all environments. Users are then required to modify the
-state / value of the feature in each environment individually.
-
-## Comparing Flags
-
-You can compare Flags both across Environments and for individual Flags.
-
-### Environment Comparison
-
-Use the "Compare" menu item to get an overview of how flag values differ between any two Environments:
-
-### Flag Comparison
-
-You can also view the values of a single Flag against all the Environments within the Project:
diff --git a/docs/docs/advanced-use/real-time-flags.md b/docs/docs/advanced-use/real-time-flags.md
deleted file mode 100644
index 7bc5ec84cdd6..000000000000
--- a/docs/docs/advanced-use/real-time-flags.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Real-time flag updates
-sidebar_label: Real-time Flags
----
-
-When an application fetches its current feature flags, it usually caches the flags for a certain amount of time to make
-[efficient use](/guides-and-examples/efficient-api-usage) of the Flagsmith API and network resources. In some cases, you
-may want an application to be notified about feature flag updates without needing to repeatedly call the Flagsmith API.
-You can achieve this by subscribing to real-time flag updates.
-
-## Prerequisites
-
-Real-time flag updates require an Enterprise subscription.
-
-If you are self-hosting Flagsmith, real-time flag updates require
-[additional infrastructure](/deployment/hosting/real-time).
-
-## Setup
-
-To enable real-time flag updates for your Flagsmith project:
-
-1. Log in to the Flagsmith dashboard as a user with project administrator permissions.
-2. Navigate to **Project Settings > SDK Settings**.
-3. Enable **Real-time updates**.
-
-Applications using a supported Flagsmith SDK do not subscribe to real-time flag updates by default. Refer to your SDK's
-documentation for subscribing to real-time flag updates.
-
-## How it works
-
-The following sequence diagram shows how a typical application would use real-time flag updates.
-[Billable API requests](/billing) are highlighted in yellow.
-
-```mermaid
-sequenceDiagram
- rect rgb(255,245,173)
- Application->>Flagsmith: Fetch initial flags
- Flagsmith->>Application: #nbsp
- end
- Application->>Flagsmith: Connect to update stream
- Flagsmith->>Application: #nbsp
- Flagsmith Administrator->>Flagsmith: Update flag state
- Flagsmith->>Flagsmith Administrator: #nbsp
- Flagsmith-->>Application: Flag update event
- rect rgb(255,245,173)
- Application->>Flagsmith: Fetch latest flags
- Flagsmith->>Application: #nbsp
- end
- Application-->Application: Store latest update timestamp
-```
-
-Your application subscribes to real-time flag updates by opening a long-lived
-[server-sent events (SSE)](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) connection to Flagsmith,
-which is specific to its current environment.
-
-When the environment is updated in some way, either via the Flagsmith dashboard or the
-[Admin API](/clients/rest#private-admin-api-endpoints), all clients connected to that environment's real-time stream
-will receive a message containing the latest update's timestamp. If your application's latest flags are older than the
-received timestamp, it requests the latest flags from Flagsmith. When your application receives the latest flags, you
-must propagate the latest flag state throughout your application as necessary.
-
-## Limitations
-
-Real-time flag update events only contain a timestamp indicating when any flag in the environment was last updated.
-Applications must still call the Flagsmith API to get the actual flags for their current environment or user.
-
-Only changes made to environments or projects result in flag update events. For example, the following operations will
-cause updates to be sent:
-
-- Manually toggling a flag on or off, or changing its value.
-- A [scheduled Change Request](/advanced-use/scheduled-flags) for a feature goes live.
-- Creating or updating segment overrides for a feature.
-- Changing a segment definition.
-
-Identity-level operations _will not_ cause updates to be sent:
-
-- Updating an identity's traits.
-- Creating or updating an identity override.
-
-The following SDK clients support subscribing to real-time flag updates:
-
-- JavaScript
-- Android
-- iOS
-- Flutter
-- Python
-- Ruby
-
-## Implementation details
-
-The event source URL used by Flagsmith SDKs is:
-
-```
-https://realtime.flagsmith.com/sse/environments/ENVIRONMENT_ID/stream
-```
-
-Each real-time flag event message is a JSON object containing a Unix epoch timestamp of the environment's last update:
-
-```json
-{
- "updated_at": 3133690620000
-}
-```
-
-You can test real-time flag updates by using cURL to connect to the event source URL:
-
-```
-curl -H 'Accept: text/event-stream' -N -i https://realtime.flagsmith.com/sse/environments/ENVIRONMENT_ID/stream
-```
diff --git a/docs/docs/advanced-use/scheduled-flags.md b/docs/docs/advanced-use/scheduled-flags.md
deleted file mode 100644
index 1fff9714945d..000000000000
--- a/docs/docs/advanced-use/scheduled-flags.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Scheduled Flags
-
-:::tip
-
-Scheduled Flags are part of our Scale-Up and Enterprise plans.
-
-:::
-
-## Overview
-
-You can use Scheduled Flags to queue up changes to Flags to be modified automatically in a future point in time.
-
-You can create a Scheduled Flag change in 1 of two ways:
-
-- As part of a Change Request.
-- If you are not enforcing Change Requests, you can schedule the Flag change when modifying a Flag.
-
-## Creating a Scheduled Flag change as part of a Change Request
-
-Once an Environment is configured with Change Requests enabled, attempting to change a flag value will prompt you to
-create a new Change Request.
-
-You will need to provide:
-
-- The title of the Change Request
-- Optionally a description of the reason for the Change Request
-- The Date and Time that you want the flag change to take effect
-
-## Creating a stand-alone Scheduled Flag change
-
-If the Environment you are working with does not have Change Requests enabled, you can create a Scheduled Flag Change
-directly when editing the Flag.
-
-## Scheduled Flags and Change Requests
-
-Scheduled Flags pending go live will appear in the Change Request area.
-
-Once the Schedule of the flag has passed the Scheduled Flag will move to the "Closed" list.
diff --git a/docs/docs/advanced-use/transient-traits.md b/docs/docs/advanced-use/transient-traits.md
deleted file mode 100644
index 7c13e2378e75..000000000000
--- a/docs/docs/advanced-use/transient-traits.md
+++ /dev/null
@@ -1,587 +0,0 @@
----
-title: Transient Traits and Identities
----
-
-import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
-
-By default, Flagsmith [stores all Traits](/basic-features/managing-identities#identity-and-trait-storage) associated
-with an Identity to evaluate flags. This default behavior works for most use cases. However, there are scenarios where
-you may want more control over which Traits or Identities are stored. Using the Flagsmith API and SDKs, you can mark
-Traits and Identities as transient — meaning they are used for flag evaluation but are not stored.
-
-## Overview and Use Cases
-
-Transient Identities and Traits are particularly useful when you need to run flag evaluations without storing specific
-data in Flagsmith. Below are common scenarios where transient Traits or Identities come in handy.
-
-### Skipping Personal Identifiable Information (PII)
-
-You can mark sensitive Traits, such as `email`, `phoneNumber`, or `locality`, as transient to enable segmentation
-without storing the actual data. For example, you may want to target users based on email domains while avoiding the
-storage of email addresses.
-
-Considering you have a Segment condition where `"email"` ends with `"example.com"`. To get flags for this Segment:
-
-```javascript
-flagsmith.updateContext({
- identity: {
- identifier: 'test-user-with-transient-email',
- traits: {
- email: { value: 'alice@example.com', transient: true },
- },
- },
-});
-```
-
-After making the SDK call, if you check the Identities tab, you'll see the `test-user-with-transient-email` Identity
-without the `email` Trait being stored.
-
-### Anonymous Identities
-
-If you choose to provide a blank (`""`) or null identifier, Flagsmith will automatically treat the Identity as
-transient. In this case, an auto-generated identifier is returned, based on a hash of the provided Traits. This ensures
-consistent flag evaluations without persisting the Identity in the Flagsmith dashboard.
-
-If no Traits and a null/blank identifier provided, a random UUIDv4 identifier is generated and used for flag evaluation.
-
-```javascript
-flagsmith.init({
- evaluationContext: {
- identity: {
- identifier: null,
- traits: { paymentPreference: 'cash' },
- },
- },
-});
-let identifierToUseLater = flagsmith.getContext().identity.identifier;
-```
-
-This approach is useful for scenarios such as A/B testing in e-commerce, where you want to include users who haven't
-registered or logged in.
-
-:::info
-
-Transient identifiers generated by Flagsmith API are consistent across flag evaluations, meaning the same identifier
-will be returned for identical sets of Traits.
-
-To generate truly unique identifiers, include additional unique Trait values.
-
-:::
-
-### Ephemeral Contexts
-
-In some cases, you may need to temporarily override certain Traits for a session or device without overwriting the
-stored value. For example, imagine you’ve persisted the `screenOrientation` Trait as `landscape` for a user:
-
-```javascript
-flagsmith.init({
- evaluationContext: {
- identity: {
- identifier: 'my-user',
- traits: { screenOrientation: 'landscape' },
- },
- },
-});
-```
-
-If you want to switch the `screenOrientation` to `portrait` for a specific session without overwriting the existing
-value, you can mark the Trait as transient:
-
-```javascript
-flagsmith.setTrait('screenOrientation', { value: 'portrait', transient: true });
-```
-
-Until you set another Trait value, the `screenOrientation` used for flag evaluations will be `portrait` in this specific
-SDK instance. The `landscape` value will remain stored in Flagsmith for other evaluations.
-
-## Usage
-
-### Server-side SDKs
-
-
+
+
+
+ Environment Settings
+Configure environment-level options and configurations
+
+
+
+
+ Platform Metrics
+System monitoring and performance metrics
+
+
+
+
+ API Usage & Monitoring
+Track and analyse API usage and billing
+
-
-
-
-Flagsmith SaaS
- -Creating an identity override requires the following information: - -* Client-side API key of the environment to create the override in -* Identifier to create the override for -* Name of the feature to create the override for -* Desired feature state - -To create an identity override, use the -[Update Edge Identity Feature State endpoint](https://api.flagsmith.com/api/v1/docs/#/operations-api-api_v1_environments_edge-identities_list). -For example, the following request would enable the feature named `custom_background_colour` with a value of `blue` -for the identity `my_user_id`: - -``` -curl --request PUT \ - --url https://api.flagsmith.com/api/v1/environments/environments/YOUR_ENVIRONMENT_API_KEY/edge-identities-featurestates \ - --header 'Accept: application/json' \ - --header 'Authorization: Token YOUR_ADMIN_API_KEY' \ - --header 'Content-Type: application/json' \ - --data '{"enabled":true,"feature":"custom_background_colour","feature_state_value":"blue", "identifier":"my_user_id"}' -``` - -This will create the override if it doesn't exist, or update it if it does (upsert). - -
-
-
-
-### Update a segment's rules
-
-```python
-import os
-
-from requests import Session
-
-API_URL = os.environ.get("API_URL", "https://api.flagsmith.com/api/v1") # update this if self-hosting
-PROJECT_ID = os.environ["PROJECT_ID"] # obtain this from the URL on your dashboard
-TOKEN = os.environ["API_TOKEN"] # obtain this from the account page in your dashboard
-SEGMENT_ID = os.environ.get("SEGMENT_ID") # obtain this from the URL on your dashboard when viewing a segment
-
-SEGMENT_RULES_DEFINITION = {
- "rules": [
- {
- "type": "ALL",
- "rules": [
- {
- "type": "ANY",
- "conditions": [ # add as many conditions here to build up a segment
- {
- "property": "my_trait", # specify a trait key that you want to match on, e.g. organisationId
- "operator": "EQUAL", # specify the operator you want to use (one of EQUAL, NOT_EQUAL, GREATER_THAN, LESS_THAN, GREATER_THAN_INCLUSIVE, LESS_THAN_INCLUSIVE, CONTAINS, NOT_CONTAINS, REGEX, PERCENTAGE_SPLIT, IS_SET, IS_NOT_SET)
- "value": "my-value" # the value to match against, e.g. 103
- }
- ]
- }
- ]
- }
- ]
-}
-
-session = Session()
-session.headers.update({"Authorization": f"Token {TOKEN}"})
-
-update_segment_url = f"{API_URL}/projects/{PROJECT_ID}/segments/{SEGMENT_ID}/"
-session.patch(update_segment_url, json=SEGMENT_RULES_DEFINITION)
-```
-
-### Iterate over Identities
-
-Sometimes it can be useful to iterate over your Identities to check things like Segment overrides.
-
-```python
-import os
-
-import requests
-
-TOKEN = os.environ.get("API_TOKEN") # obtained from Account section in dashboard
-ENV_KEY = os.environ.get("ENV_KEY") # obtained from Environment settings in dashboard
-BASE_URL = "https://api.flagsmith.com/api/v1" # update this if self hosting
-IDENTITIES_PAGE_URL = f"{BASE_URL}/environments/{ENV_KEY}/edge-identities/?page_size=20"
-
-session = requests.Session()
-session.headers.update(
- {"Authorization": f"Token {TOKEN}", "Content-Type": "application/json"}
-)
-
-# get the existing feature state id based on the feature name
-page_of_identities = session.get(f"{IDENTITIES_PAGE_URL}")
-print(page_of_identities.json())
-
-for identity in page_of_identities.json()['results']:
- print(str(identity))
- IDENTITY_UUID = identity['identity_uuid']
- IDENTITY_URL = f"{BASE_URL}/environments/{ENV_KEY}/edge-identities/{IDENTITY_UUID}/edge-featurestates/all/"
- identity_data = session.get(f"{IDENTITY_URL}")
- print(identity_data.json())
-```
-
-### Delete an Edge Identity
-
-```python
-import os
-
-import requests
-
-TOKEN = os.environ.get("API_TOKEN") # obtained from Account section in dashboard
-ENV_KEY = os.environ.get("ENV_KEY") # obtained from Environment settings in dashboard
-IDENTITY_UUDI = os.environ["IDENTITY_UUDI"] # must (currently) be obtained by inspecting the request to /api/v1/environments/{ENV_KEY}/edge-identities/{IDENTITY_UUDI} in the network console
-BASE_URL = "https://edge.api.flagsmith.com/api/v1" # update this if self hosting
-
-session = requests.Session()
-session.headers.update(
- {"Authorization": f"Token {TOKEN}", "Content-Type": "application/json"}
-)
-
-# delete the existing edge identity based on the uuid
-delete_edge_identity_url = f"{BASE_URL}/environments/{ENV_KEY}/edge-identities/{IDENTITY_UUDI}/"
-delete_edge_identity_response = session.delete(delete_edge_identity_url)
-assert delete_edge_identity_response.status_code == 204
-
-```
-
-### Delete an Identity
-
-```python
-import os
-
-import requests
-
-TOKEN = os.environ.get("API_TOKEN") # obtained from Account section in dashboard
-ENV_KEY = os.environ.get("ENV_KEY") # obtained from Environment settings in dashboard
-IDENTITY_ID = os.environ["IDENTITY_ID"] # obtain this from the URL on your dashboard when viewing an identity
-BASE_URL = "https://api.flagsmith.com/api/v1" # update this if self hosting
-
-session = requests.Session()
-session.headers.update(
- {"Authorization": f"Token {TOKEN}", "Content-Type": "application/json"}
-)
-
-# delete the existing identity based on the identity id
-delete_identity_url = f"{BASE_URL}/environments/{ENV_KEY}/identities/{IDENTITY_ID}/"
-delete_identity_response = session.delete(delete_identity_url)
-assert delete_identity_response.status_code == 204
-```
-
-### Bulk Uploading Identities and Traits
-
-You can achieve this with a `POST` to the `bulk-identities` endpoint:
-
-```bash
-curl -i -X POST "https://edge.api.flagsmith.com/api/v1/bulk-identities" \
- -H "X-Environment-Key: ${FLAGSMITH_ENVIRONMENT_KEY}" \
- -H 'Content-Type: application/json' \
- -d $'{
- "data": [
- {
- "identifier": "my_identifier_1",
- "traits": [
- {
- "trait_key": "my_key_name",
- "trait_value": "set from POST /bulk-identities"
- }
- ]
- },
- {
- "identifier": "my_identifier_2",
- "traits": [
- {
- "trait_key": "some_other_key_name",
- "trait_value": "if this identity does not exist, it will be created by this request"
- }
- ]
- },
- {
- "identifier": "my_identifier_3",
- "traits": [
- {
- "trait_key": "this_trait_will_be_deleted",
- "trait_value": null
- }
- ]
- }
- ]
- }'
-```
diff --git a/docs/docs/deployment-self-hosting/_category_.json b/docs/docs/deployment-self-hosting/_category_.json
new file mode 100644
index 000000000000..bf89feb3f166
--- /dev/null
+++ b/docs/docs/deployment-self-hosting/_category_.json
@@ -0,0 +1,5 @@
+{
+ "label": "Deployment and Self-hosting",
+ "collapsed": true,
+ "position": 10
+}
\ No newline at end of file
diff --git a/docs/docs/deployment-self-hosting/administration-and-maintenance/_category_.json b/docs/docs/deployment-self-hosting/administration-and-maintenance/_category_.json
new file mode 100644
index 000000000000..495de3e0bac7
--- /dev/null
+++ b/docs/docs/deployment-self-hosting/administration-and-maintenance/_category_.json
@@ -0,0 +1,5 @@
+{
+ "label": "Administration and Maintenance",
+ "position": 7,
+ "collapsed": true
+}
diff --git a/docs/docs/deployment-self-hosting/administration-and-maintenance/troubleshooting.md b/docs/docs/deployment-self-hosting/administration-and-maintenance/troubleshooting.md
new file mode 100644
index 000000000000..24edd88af33a
--- /dev/null
+++ b/docs/docs/deployment-self-hosting/administration-and-maintenance/troubleshooting.md
@@ -0,0 +1,21 @@
+---
+title: Troubleshooting
+sidebar_label: Troubleshooting
+sidebar_position: 90
+---
+
+Here are some common issues encountered when trying to set up Flagsmith in a self-hosted environment.
+
+## Health Checks
+
+If you are using health checks, make sure to use `/health` as the health-check endpoint for both the API and the frontend.
+
+## API and Database Connectivity
+
+The most common cause of issues when setting things up in AWS with an RDS database is missing Security Group permissions between the API application and the RDS database. You need to ensure that the attached security groups for ECS/Fargate/EC2 allow access to the RDS database. [AWS provide more detail about this here](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-task-connect-rds-database/) and [here](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html).
+
+Make sure you have a `DATABASE_URL` environment variable set within the API application.
+
+## Frontend > API DNS Setup
+
+If you are running the API and the frontend as separate applications, you need to make sure that the frontend is pointing to the API. Check the [Frontend environment variables](/deployment-self-hosting/core-configuration/environment-variables#frontend-environment-variables), particularly `API_URL`.
diff --git a/docs/docs/deployment-self-hosting/administration-and-maintenance/upgrades-and-rollbacks.md b/docs/docs/deployment-self-hosting/administration-and-maintenance/upgrades-and-rollbacks.md
new file mode 100644
index 000000000000..e8eeecefcd94
--- /dev/null
+++ b/docs/docs/deployment-self-hosting/administration-and-maintenance/upgrades-and-rollbacks.md
@@ -0,0 +1,82 @@
+---
+sidebar_label: Upgrades and Rollbacks
+title: Upgrades and Rollbacks
+sidebar_position: 2
+---
+
+# Rolling Back to a Previous Version of Flagsmith
+
+:::warning
+
+These steps may result in data loss in the scenario where new models or fields have been added to the database. We recommend taking a full backup of the database before completing the rollback.
+
+:::
+
+This page covers the process of rolling back to a previous version of Flagsmith. If you need to roll back to a previous version, you will need to ensure that the database is also rolled back to the correct state. In order to do this, you will need to unapply all the migrations that happened between the version that you want to roll back to and the one that you are rolling back from. The following steps explain how to do that.
+
+## Steps for v2.151.0 and Later
+
+1. Identify the date and time that you deployed the version that you want to roll back to.
+
+:::tip
+
+If you are unsure about when you completed the previous deployment, you can use the `django_migrations` table as a guide. If you query the table using the following query, you should see the migrations that have been applied (in descending order), grouped in batches corresponding to each deployment.
+
+```sql
+SELECT *
+FROM django_migrations
+ORDER BY applied DESC
+```
+
+:::
+
+2. Run the rollback command inside a Flagsmith API container running the _current_ version of Flagsmith:
+
+```bash
+python manage.py rollbackmigrationsafter "Self-hosted and private cloud
- -Creating an identity override in non-SaaS environments requires additional information compared to Flagsmith SaaS: - -* Internal ID of the feature to override -* Internal ID of the target identity -* ID of the identity feature state to update, if an override already exists - -Make sure you have [JSON View](#json) enabled. - -To obtain the feature's internal ID, open the feature in the Flagsmith dashboard, and expand the "JSON Data: Feature" -section. The feature's internal ID is the `id` field of this JSON object. - -To obtain the internal IDs of the target identity, browse to the target identity from the Identities section in the -Flagsmith dashboard. The identity's internal ID is displayed in the URL, which is `1234` in this example: - -``` -https://flagsmith.example.com/project/5/environment/AbCxYz/users/my_identifier/1234 -``` - -To obtain the ID of the identity feature state, from the same page on the Flagsmith dashboard, expand the "JSON -Data: Identity Feature States" section. If you don't see this section, you can create an identity override for this -feature and identity combination by calling the -[Create Identity Feature State](https://api.flagsmith.com/api/v1/docs/#/api/api_v1_environments_featurestates_create) -endpoint. For example, this request would set the feature with ID `10` to enabled, with a value of `"blue"`: - -``` -curl --request POST 'https://flagsmith.example.com/api/v1/environments/AbCXyZ/identities/1234/featurestates/' \ - --header 'Accept: application/json' \ - --header 'Authorization: Token YOUR_ADMIN_API_KEY' - --data '{"enabled":true,"feature":10,"feature_state_value":"blue"}' -``` - -If you do have an identity feature state already, its ID is the `id` field of the object having the -same internal feature ID you had previously found. In this example, if your internal feature ID was `10`, the -identity feature state ID would be `200`: - -```json -[ - { - // highlight-next-line - "id": 200, - "feature_state_value": null, - "multivariate_feature_state_values": [], - "identity": { - "id": 1234, - "identifier": "my_user_id" - }, - "enabled": true, - "feature": 10 - }, - { - "id": 300, - "feature_state_value": null, - "multivariate_feature_state_values": [], - "identity": { - "id": 1234, - "identifier": "my_user_id" - }, - "enabled": false, - "feature": 20 - } -] -``` - -To update this identity override, call the -[Update Identity Feature State](https://api.flagsmith.com/api/v1/docs/#/api/api_v1_environments_featurestates_update) -endpoint. For example, this request would enable the feature with internal ID `10` for the identity with internal ID -`1234`, assuming there was previously an override with an ID of `200`: - -``` -curl --request PUT 'https://flagsmith.example.com/api/v1/environments/AbCXyZ/identities/1234/featurestates/200' \ - --header 'Accept: application/json' \ - --header 'Authorization: Token YOUR_ADMIN_API_KEY' - --data '{"enabled":true,"feature":10}' -``` - -GET\_[FLAGS|IDENTITIES]\_ENDPOINT_CACHE_SECONDS | Number of seconds to cache the response to `GET /api/v1/flags` | `60` | `0` |
-| GET\_[FLAGS|IDENTITIES]\_ENDPOINT_CACHE_BACKEND | Python path to the django cache backend chosen. See documentation [here](https://docs.djangoproject.com/en/4.2/topics/cache/). | `django.core.cache.backends.memcached.PyMemcacheCache` | `django.core.cache.backends.dummy.DummyCache` |
-| GET\_[FLAGS|IDENTITIES]\_ENDPOINT_CACHE_LOCATION | The location for the cache. See documentation [here](https://docs.djangoproject.com/en/4.2/topics/cache/). | `127.0.0.1:11211` | `get_flags_endpoint_cache` |
-
-An example configuration to cache both flags and identities requests for 30 seconds in a memcached instance hosted at
-`memcached-container`:
-
-```
-GET_FLAGS_ENDPOINT_CACHE_SECONDS: 30
-GET_FLAGS_ENDPOINT_CACHE_BACKEND: django.core.cache.backends.memcached.PyMemcacheCache
-GET_FLAGS_ENDPOINT_CACHE_LOCATION: memcached-container:11211
-GET_IDENTITIES_ENDPOINT_CACHE_SECONDS: 30
-GET_IDENTITIES_ENDPOINT_CACHE_BACKEND: django.core.cache.backends.memcached.PyMemcacheCache
-GET_IDENTITIES_ENDPOINT_CACHE_LOCATION: memcached-container:11211
-```
-
-### Environment authentication caching
-
-On each request using the X-Environment-Key header, the flagsmith application retrieves the environment to perform the
-relevant caching. This can be configured using environment variables to create a shared cache with a longer timeout. The
-cache will be cleared automatically by certain actions in the platform when the environment changes.
-
-| Environment Variable | Description | Example value | Default |
-| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------ | --------------------------------------------- |
-| `ENVIRONMENT_CACHE_SECONDS` | Number of seconds to cache the environment for | `60` | `86400` ( = 24h) |
-| `ENVIRONMENT_CACHE_BACKEND` | Python path to the django cache backend chosen. See documentation [here](https://docs.djangoproject.com/en/4.2/topics/cache/). | `django.core.cache.backends.memcached.PyMemcacheCache` | `django.core.cache.backends.dummy.DummyCache` |
-| `ENVIRONMENT_CACHE_LOCATION` | The location for the cache. See documentation [here](https://docs.djangoproject.com/en/4.2/topics/cache/). | `127.0.0.1:11211` | `environment-objects` |
-
-
-### Environment document caching
-
-When configuring the environment document caching, there are 2 options: persistent or expiring. The expiring cache
-will expire after a configurable period. The benefit of this option is that it can be used with all cache
-backends, including those without a centralised storage mechanism. Bear in mind that this will mean, however, that
-changes will take up to the configured timeout to be reflected in your Flagsmith clients. The persistent cache instead
-makes use of an automated process to rebuild the cache whenever a change is made.
-
-:::warning
-
-Persistent cache should only be used with cache backends that offer a centralised cache. It should not be used with
-e.g. LocMemCache.
-
-:::
-
-:::info
-
-When using a persistent cache, a change can take a few seconds to update the cache. This can also be optimised by
-increasing the performance of your task processor.
-
-:::
-
-
-| Environment Variable | Description | Example value | Default |
-| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------- |
-| `CACHE_ENVIRONMENT_DOCUMENT_MODE` | The caching mode. One of `PERSISTENT` or `EXPIRING`. Note that although the default is `EXPIRING` there is no caching by default due to the default value of `CACHE_ENVIRONMENT_DOCUMENT_SECONDS` | `PERSISTENT` | `EXPIRING` |
-| `CACHE_ENVIRONMENT_DOCUMENT_SECONDS` | Number of seconds to cache the environment for (only relevant when `CACHE_ENVIRONMENT_DOCUMENT_MODE=EXPIRING`) | `60` | `0` ( = don't cache) |
-| `CACHE_ENVIRONMENT_DOCUMENT_BACKEND` | Python path to the django cache backend chosen. See documentation [here](https://docs.djangoproject.com/en/4.2/topics/cache/). | `django.core.cache.backends.memcached.PyMemcacheCache` | `django.core.cache.backends.db.DatabaseCache` |
-| `CACHE_ENVIRONMENT_DOCUMENT_LOCATION` | The location for the cache. See documentation [here](https://docs.djangoproject.com/en/4.2/topics/cache/). | `127.0.0.1:11211` | `environment-documents` |
-| `CACHE_ENVIRONMENT_DOCUMENT_OPTIONS` | JSON object representing any additional options required by the specific cache backend. See [here](https://docs.djangoproject.com/en/4.2/topics/cache/#cache-arguments) for further information. | `{"PASSWORD": "securepassword"}` | {} |
-
-
-
-#### Example 1. Expiring local memory cache with 60 second timeout
-
-The following environment variables provide an example for specifying a cache local to each API instance that
-expires after 60 seconds. This can be useful in deployments with just a few environments, where there is flexibility
-on how long a change to the flags should take to propagate to the clients.
-
-```
-CACHE_ENVIRONMENT_DOCUMENT_SECONDS: "60"
-CACHE_ENVIRONMENT_DOCUMENT_BACKEND: "django.core.cache.backends.locmem.LocMemCache"
-```
-
-#### Example 2. Persistent redis cache
-
-The following environment variables provide an example for specifying a cache, stored in redis, that is automatically
-updated whenever a flag is changed.
-
-```
-CACHE_ENVIRONMENT_DOCUMENT_MODE: "PERSISTENT"
-CACHE_ENVIRONMENT_DOCUMENT_BACKEND: "django_redis.cache.RedisCache"
-CACHE_ENVIRONMENT_DOCUMENT_LOCATION: "redis://127.0.0.1:6379/1"
-CACHE_ENVIRONMENT_DOCUMENT_OPTIONS: "{\"PASSWORD\": \"myredispassword\"}"
-```
-
-## Unified Front End and Back End Build
-
-You can run Flagsmith as a single application/docker container using our unified builds. These are available on
-[Docker Hub](https://hub.docker.com/repository/docker/flagsmith/flagsmith) but you can also run the front end as part of
-the Django Application. Steps to do this:
-
-```bash
-# Update packages and build django.
-cd frontend
-npm install
-npm run bundledjango
-
-# Copy additional assets with Django
-cd ../api
-python manage.py collectstatic
-
-# Boot the server
-python manage.py runserver
-```
-
-### How it works
-
-Webpack compiles a front end build, sourcing `api/app/templates/index.html`. It places the compiled JS and CSS assets to
-`api/static` then copies the annotated `index.html` page to `api/app/templates/webpack/index.html`.
-
-The Django `collectstatic` command then copies all the additional static assets that Django needs, including
-`api/app/templates/webpack/index.html`, into `api/static`.
-
-## Rolling back to a previous version of Flagsmith
-
-:::warning
-
-These steps may result in data loss in the scenario where new models or fields have been added to the database. We
-recommend taking a full backup of the database before completing the rollback.
-
-:::
-
-If you need to roll back to a previous version of Flagsmith you will need to ensure that the database is also rolled
-back to the correct state. In order to do this, you will need to unapply all the migrations that happened in between the
-version that you want to roll back to, and the one that you are rolling back from. The following steps explain how to do
-that.
-
-1. Identify the date and time that you deployed the version that you want to roll back to.
-
-:::tip
-
-If you are unsure on when you completed the previous deployment, then you can use the `django_migrations` table as a
-guide. If you query the table, using the following query then you should see the migrations that have been applied (in
-descending order), grouped in batches corresponding to each deployment.
-
-```sql
-SELECT *
-FROM django_migrations
-ORDER BY applied DESC
-```
-
-:::
-
-2. Run the following command inside a Flagsmith API container running the _current_ version of Flagsmith
-
-```bash
-python manage.py rollbackmigrationsafter "
-
-
-Docker CLI
-``` -docker run \ - -v ./config.json:/app/config.json \ - -p 8000:8000 \ - flagsmith/edge-proxy:latest -``` -
-
-
-## Configuration
-
-The Edge Proxy can be configured with any combination of:
-
-- Environment variables.
-- A JSON configuration file, by default located at `/app/config.json` in the Edge Proxy container.
-
-Environment variables take priority over their corresponding options defined in the configuration file.
-
-Environment variable names are case-insensitive, and are processed using
-[Pydantic](https://docs.pydantic.dev/2.7/concepts/pydantic_settings/#environment-variable-names).
-
-### Example configuration
-
-Docker Compose
-```yaml title="compose.yaml" -services: - edge_proxy: - image: flagsmith/edge-proxy:latest - volumes: - - type: bind - source: ./config.json - target: /app/config.json - ports: - - '8000:8000' -``` -
-
-
-
-Configuration file
- -```json title="/app/config.json" -{ - "environment_key_pairs": [ - { - "server_side_key": "ser.your_server_side_key_1", - "client_side_key": "your_client_side_key_1" - } - ], - "api_poll_frequency_seconds": 5, - "logging": { - "log_level": "DEBUG", - "log_format": "json" - } -} -``` - -
-
-
-
-### Basic settings
-
-#### `environment_key_pairs`
-
-Specifies which environments to poll environment documents for. Each environment requires a server-side key and its
-corresponding client-side key.
-
-```json
-"environment_key_pairs": [{
- "server_side_key": "ser.your_server_side_key",
- "client_side_key": "your_client_side_environment_key"
-}]
-```
-
-#### `api_url`
-
-If you are self-hosting Flagsmith, set this to your API URL:
-
-```json
-"api_url": "https://flagsmith.example.com/api/v1"
-```
-
-#### `api_poll_frequency_seconds`
-
-How often to poll the Flagsmith API for changes, in seconds. Defaults to 10.
-
-```json
-"api_poll_frequency_seconds": 30
-```
-
-#### `api_poll_timeout_seconds`
-
-The request timeout when trying to retrieve new changes, in seconds. Defaults to 5.
-
-```json
-"api_poll_timeout_seconds": 1
-```
-
-#### `allow_origins`
-
-Set a value for the `Access-Control-Allow-Origin` header. Defaults to `*`.
-
-```json
-"allow_origins": "https://www.example.com"
-```
-
-### Endpoint caches
-
-#### `endpoint_caches`
-
-Enables a LRU cache per endpoint.
-
-Optionally, specify the LRU cache size with `cache_max_size`. Defaults to 128.
-
-```json
-"endpoint_caches": {
- "flags": {
- "use_cache": false
- },
- "identities": {
- "use_cache": true,
- "cache_max_size": 1000,
- }
-}
-```
-
-### Server settings
-
-#### `server.proxy_headers`
-
-When set to `true`, the Edge Proxy will use the `X-Forwarded-For` and `X-Forwarded-Proto` HTTP headers to determine
-client IP addresses. This is useful if the Edge Proxy is running behind a reverse proxy, and you want the
-[access logs](#logging.override) to show the real IP addresses of your clients.
-
-By default, only the loopback address is trusted. This can be changed with the [`FORWARDED_ALLOW_IPS` environment
-variable](#environment-variables).
-
-```json
-"server": {
- "proxy_headers": true
-}
-```
-
-```
-SERVER_PROXY_HEADERS=true
-```
-
-### Logging
-
-#### `logging.log_level`
-
-Choose a logging level from `"CRITICAL"`, `"ERROR"`, `"WARNING"`, `"INFO"`, `"DEBUG"`. Defaults to `"INFO"`.
-
-```json
-"logging": {"log_level": "DEBUG"}
-```
-
-#### `logging.log_format`
-
-Choose a logging format between `"generic"` and `"json"`. Defaults to `"generic"`.
-
-```json
-"logging": {"log_format": "json"}
-```
-
-#### `logging.log_event_field_name`
-
-Set a name used for human-readable log entry field when logging events in JSON. Defaults to `"message"`.
-
-```json
-"logging": {"log_event_field_name": "event"}
-```
-
-#### `logging.colour`
-
-Added in [2.13.0](https://github.com/Flagsmith/edge-proxy/releases/tag/v2.13.0).
-
-Set to `false` to disable coloured output. Useful when outputting the log to a file.
-
-#### `logging.override`
-
-Added in [2.13.0](https://github.com/Flagsmith/edge-proxy/releases/tag/v2.13.0).
-
-Accepts
-[Python-compatible logging settings](https://docs.python.org/3/library/logging.config.html#configuration-dictionary-schema)
-in JSON format. You're able to define custom formatters, handlers and logger configurations. For example, to log
-everything a file, one can set up own file handler and assign it to the root logger:
-
-```json
-"logging": {
- "override": {
- "handlers": {
- "file": {
- "level": "INFO",
- "class": "logging.FileHandler",
- "filename": "edge-proxy.log",
- "formatter": "json"
- }
- },
- "loggers": {
- "": {
- "handlers": ["file"],
- "level": "INFO",
- "propagate": true
- }
- }
- }
-}
-```
-
-Or, log access logs to file in generic format while logging everything else to stdout in JSON:
-
-```json
-"logging": {
- "override": {
- "handlers": {
- "file": {
- "level": "INFO",
- "class": "logging.FileHandler",
- "filename": "edge-proxy.log",
- "formatter": "generic"
- }
- },
- "loggers": {
- "": {
- "handlers": ["default"],
- "level": "INFO"
- },
- "uvicorn.access": {
- "handlers": ["file"],
- "level": "INFO",
- "propagate": false
- }
- }
- }
-}
-```
-
-When adding logger configurations, you can use the `"default"` handler which writes to stdout and uses formatter
-specified by the [`"logging.log_format"`](#logginglog_format) setting.
-
-### Health checks
-
-The Edge Proxy exposes two health check endpoints:
-
-* `/proxy/health/liveness`: Always responds with a 200 status code. Use this health check to determine if the Edge
- Proxy is alive and able to respond to requests.
-* `/proxy/health/readiness`: Responds with a 200 status if the Edge Proxy was able to fetch all its configured
- environment documents within a configurable grace period. This allows the Edge Proxy to continue reporting as healthy
- even if the Flagsmith API is temporarily unavailable. This health check is also available at `/proxy/health`.
-
-You should point your orchestration health checks to these endpoints.
-
-#### `health_check.environment_update_grace_period_seconds`
-
-Default: `30`.
-
-The number of seconds to allow per environment key pair before the environment data stored by the Edge Proxy is
-considered stale.
-
-When set to `null`, cached environment documents are never considered stale, and health checks will succeed if all
-environments were successfully fetched at some point since the Edge Proxy started.
-
-The effective grace period depends on how many environments the Edge Proxy is configured to serve. It can be calculated
-using the following pseudo-Python code:
-
-```python
-total_grace_period_seconds = api_poll_frequency + (environment_update_grace_period_seconds * len(environment_key_pairs))
-if last_updated_all_environments_at < datetime.now() - timedelta(seconds=total_grace_period_seconds):
- # Data is stale
- return 500
-# Data is not stale
-return 200
-```
-
-### Environment variables
-
-Some Edge Proxy settings can only be set using environment variables:
-
-- `WEB_CONCURRENCY` The number of [Uvicorn](https://www.uvicorn.org/) workers. Defaults to `1`, which is
- [recommended when running multiple Edge Proxy containers behind a load balancer](https://fastapi.tiangolo.com/deployment/docker/#one-load-balancer-multiple-worker-containers).
- If running on a single node, set this [based on your number of CPU cores and threads](https://docs.gunicorn.org/en/latest/design.html#how-many-workers).
-- `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, `NO_PROXY`: These variables let you configure an HTTP proxy that the
- Edge Proxy should use for all its outgoing HTTP requests.
- [Learn more](https://www.python-httpx.org/environment_variables)
-- `FORWARDED_ALLOW_IPS`: Which IPs to trust for determining client IP addresses when using the `proxy_headers` option.
- For more details, see the [Uvicorn documentation](https://www.uvicorn.org/settings/#http).
diff --git a/docs/docs/deployment/hosting/locally-frontend.md b/docs/docs/deployment/hosting/locally-frontend.md
deleted file mode 100644
index ca060b1fe25e..000000000000
--- a/docs/docs/deployment/hosting/locally-frontend.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-sidebar_label: Frontend
-title: Flagsmith Frontend
-sidebar_position: 20
----
-
-## Getting Started
-
-These instructions will get you a copy of the project front end up and running on your local machine for development and
-testing purposes. See running in production for notes on how to deploy the project on a live system.
-
-## Prerequisites
-
-What things you need to install the software and how to install them. Installing nvm and their bash script will ensure
-developers are on the same NodeJS version.
-
-| Location | Suggested Version |
-| ----------------------------------------------------------------------- | :---------------: |
-| NodeJS | >= 22.0.0 |
-| npm | >= 8.0.0 |
-| nvm | >= 0.39.0 |
-| nvm zshrc setup | n/a |
-
-## Installing
-
-```bash
-cd frontend
-npm i
-```
-
-## Running the Front End
-
-### Development
-
-Hot reloading for client / server
-
-```bash
-cd frontend
-npm run dev
-```
-
-### Production
-
-You can deploy this application on [Heroku](https://www.heroku.com/) and [Dokku](http://dokku.viewdocs.io/dokku/)
-without making any changes, other than the API URL in '/frontend/env/project_prod.js'
-
-Bundles, minifies and cache busts the project to a build folder and runs node in production. This can be used as part of
-your deployment script.
-
-```bash
-cd frontend
-npm run bundle
-npm start
-```
-
-## Environment Variables
-
-Variables that differ per environment are exported globally to `window.Project in` 'frontend/common/project.js', this
-file gets replaced by a project.js located in 'frontend/env' by webpack based on what is set to the "ENV" environment
-variable (e.g. ENV=prod).
-
-You can override each variable individually or add more by editing 'frontend/bin/env.js'.
-
-Current variables used between 'frontend/environment.js' and 'frontend/common/project.js':
-
-- `FLAGSMITH_API_URL`: The API to hit for requests. E.g. `https://edge.api.flagsmith.com/api/v1/`
-- `FLAGSMITH_ON_FLAGSMITH_API_KEY`: The flagsmith environment key we use to manage features -
- [Flagsmith runs on Flagsmith](/deployment#running-flagsmith-on-flagsmith).
-- `FLAGSMITH_ON_FLAGSMITH_API_URL`: The API URL which the flagsmith client should communicate with. Flagsmith runs on
- flagsmith. E.g. `https://edge.api.flagsmith.com/api/v1/`. If you are self hosting and using your own Flagsmith
- instance to manage its own features, you would generally point this to the same domain name as your own Flagsmith
- instance.
-- `DISABLE_ANALYTICS_FEATURES`: Disables any in-app analytics-related features: API Usage charts, flag analytics. E.g.
- `DISABLE_ANALYTICS_FEATURES=1`.
-- `ENABLE_FLAG_EVALUATION_ANALYTICS`: Determines if the flagsmith sdk should send usage analytics, if you want to enable
- Flag Analytics, set this. E.g. `ENABLE_FLAG_EVALUATION_ANALYTICS=1`.
-- `PROXY_API_URL`: Proxies the API via this application. Set this to the hostname of the API being proxied. Proxies
- `/api/v1/` through to `PROXY_API_URL`. If you are using this, any setting to `FLAGSMITH_API_URL` will be ignored and
- the browser will use the front end node server to send API requests. Do not prepend `api/v1/` - it will be added
- automatically.
-- `GOOGLE_ANALYTICS_API_KEY`: Google Analytics key to track API usage.
-- `CRISP_WEBSITE_ID`: Crisp Chat widget Website key.
-- `FIRST_PROMOTER_ID`: First Promoter ID for checkout affiliates.
-- `ALLOW_SIGNUPS`: **DEPRECATED** in favour of `PREVENT_SIGNUP` in the API. Determines whether to prevent manual signups without
- invites. Set it to any value to allow signups.
-- `PREVENT_SIGNUP`: **DEPRECATED** in favour of `PREVENT_SIGNUP` in the API. Determines whether to prevent manual signups. Set it to any value to prevent hide signup pages.
-- `PREVENT_FORGOT_PASSWORD`: Determines whether to prevent forgot password functionality, useful for LDAP/SAML. Set it
- to any value to prevent forgot password functionality.
-- `PREVENT_EMAIL_PASSWORD`: Disables email address signup, login and change email functionality.
-- `ENABLE_MAINTENANCE_MODE`: Puts the site into maintenance mode. Set it to any value to enable maintenance.
-- `AMPLITUDE_API_KEY`: The Amplitude key to use for behaviour tracking.
-- `REO_API_KEY`: The Reo key to use for behaviour tracking.
-- `SENTRY_API_KEY`: Sentry key for error reporting.
-- `ALBACROSS_CLIENT_ID`: Albacross client ID key for behaviour tracking.
-- `BASE_URL`: Used for specifying a base url path that's ignored during routing if serving from a subdirectory.
-- `USE_SECURE_COOKIES`: Enable / disable the use of secure cookies. If deploying the FE in a private network without a
- domain / SSL cert, disable secure cookies to ensure that session token is persisted. Default: true.
-- `COOKIE_SAME_SITE`: Define the value of the samesite attribute for the session token cookie set by the frontend.
- Further reading on this value is available [here](https://web.dev/articles/samesite-cookies-explained). Default:
- 'none'.
-
-### GitHub Integration Environment Variables
-
-- `GITHUB_APP_URL`: You can obtain the URL of your GitHub App in the 'About' section -> 'public link' and append
- '/installations/select_target' to it. E.g. `https://github.com/apps/my-github-app/installations/select_target`
-
-## E2E testing
-
-This project uses [Test Cafe](https://testcafe.io/) for automated end to end testing with Chromedriver.
-
-```bash
-npm test
-```
-
-## Built With
-
-- React
-- Webpack
-- Node
-
-## Running locally against your own Flagsmith API instance
-
-We use Flagsmith to manage features we rollout, if you are using your own Flagsmith environment (i.e. by editing
-project_x.js-> flagsmith) then you will need to have a replica of our flags.
-
-A list of the flags and remote config we're currently using in production can be
-[found here](/deployment#current-flagsmith-feature-flags).
diff --git a/docs/docs/deployment/hosting/openshift.md b/docs/docs/deployment/hosting/openshift.md
deleted file mode 100644
index ae47e6f77a2f..000000000000
--- a/docs/docs/deployment/hosting/openshift.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: OpenShift
-description: Getting Started with Flagsmith on OpenShift
-sidebar_label: OpenShift
-sidebar_position: 60
----
-
-:::tip
-
-Support for our OpenShift Operator is only available with an [Enterprise plan](https://flagsmith.com/pricing/).
-
-:::
-
-Flagsmith runs on the OpenShift platform via our [Helm charts](kubernetes.md).
diff --git a/docs/docs/deployment/hosting/real-time/benchmark.js b/docs/docs/deployment/hosting/real-time/benchmark.js
deleted file mode 100644
index 67acc6139c36..000000000000
--- a/docs/docs/deployment/hosting/real-time/benchmark.js
+++ /dev/null
@@ -1,47 +0,0 @@
-// Stress test for the Flagsmith SSE service
-// https://docs.flagsmith.com/deployment/hosting/real-time
-
-import { sleep } from 'k6';
-import http from 'k6/http';
-
-export const options = {
- discardResponseBodies: true,
- scenarios: {
- // Gradually ramp up to 20k concurrent subscribers for the same environment
- subscribe: {
- exec: 'subscribers',
- executor: 'ramping-vus',
- stages: [{ duration: '1m', target: 10000 }],
- },
- // Publish an update to the same environment every 10s
- publish: {
- duration: '1m',
- exec: 'publish',
- executor: 'constant-vus',
- vus: 1,
- },
- },
-};
-
-const env = 'load_test';
-export function subscribers() {
- http.get(`http://localhost:8088/sse/environments/${env}/queue-change`, '', {
- headers: {
- Accept: 'event/stream',
- },
- timeout: '3m',
- });
-}
-
-export function publish() {
- const body = JSON.stringify({
- updated_at: new Date().toISOString(),
- });
- http.post(`http://localhost:8088/sse/environments/${env}/queue-change`, body, {
- headers: {
- 'Content-Type': 'application/json',
- Authorization: 'Token ' + __ENV.SSE_AUTHENTICATION_TOKEN,
- },
- });
- sleep(10);
-}
diff --git a/docs/docs/deployment/hosting/real-time/deployment.md b/docs/docs/deployment/hosting/real-time/deployment.md
deleted file mode 100644
index f117573903ee..000000000000
--- a/docs/docs/deployment/hosting/real-time/deployment.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-title: Deployment guide
-sidebar_label: Deployment
-sidebar_position: 30
----
-
-## Redis
-
-First, deploy a Redis-compatible store, such as [Valkey](https://valkey.io/). Many managed options for Redis-compatible
-stores are offered by different cloud providers. Some examples:
-
-- [Amazon ElastiCache (AWS)](https://aws.amazon.com/elasticache/features/)
-- [Memorystore for Valkey (GCP)](https://cloud.google.com/memorystore/docs/valkey/product-overview)
-- [Azure cache for Redis](https://azure.microsoft.com/en-us/products/cache)
-
-Clustering Redis is recommended for high availability, but not required. All
-[current Redis versions](https://redis.io/docs/latest/operate/rs/installing-upgrading/product-lifecycle/) are supported.
-
-### Authentication
-
-By default, the SSE service will try to connect to Redis without a username or password. If needed, these can be set
-with the `REDIS_USERNAME` and `REDIS_PASSWORD` environment variables.
-
-## SSE service
-
-Run the `flagsmith/sse` image, setting these environment variables:
-
-| Variable name | Description | Default |
-|---------------------------------|---------------------------------------------------------------------------------------------------------------------------------|--------------|
-| `SSE_AUTHENTICATION_TOKEN` | Shared secret for authentication on the `/queue-change` endpoint | **Required** |
-| `REDIS_HOST` | Hostname of the Redis load balancer | `localhost` |
-| `REDIS_PORT` | Port number to use when connecting to Redis | 6379 |
-| `REDIS_USERNAME` | Username to use when connecting to Redis | None |
-| `REDIS_PASSWORD` | Password to use when connecting to Redis | None |
-| `REDIS_SCAN_COUNT` | Number of Redis keys to [`SCAN`](https://redis.io/docs/latest/commands/scan/) at once when updating the in-memory cache | 500 |
-| `CACHE_UPDATE_INTERVAL_SECONDS` | How long (in seconds) to wait between each `SCAN` to update the in-memory cache | 1 |
-| `USE_CLUSTER_MODE` | Whether to connect to Redis with [Cluster Mode](https://redis.io/docs/latest/operate/oss_and_stack/management/scaling/) enabled | `False` |
-| `REDIS_USE_SSL` | Whether to connect to Redis using TLS | `False` |
-| `MAX_STREAM_AGE` | How long (in seconds) to keep SSE connections alive for. If negative, connections are kept open indefinitely | 30 |
-| `STREAM_DELAY` | How long (in seconds) to wait before checking the internal cache for updates | 1 |
-
-The SSE service will expose its endpoints to `0.0.0.0:8000`.
-
-## API and task processor
-
-The Flagsmith API and task processor need to know about the SSE service. On both the API and task processor, set these
-environment variables:
-
-- `SSE_SERVER_BASE_URL` points to the SSE service load balancer. For example: `http://my-sse-service:8000`
-- `SSE_AUTHENTICATION_TOKEN` can be set to any non-empty string, as long as the SSE service and task processor share the
- same value.
-
-## Flagsmith configuration
-
-Make sure the Flagsmith projects you are updating have real-time updates enabled. If not, no tasks will be queued when
-its environments are updated.
-
-Lastly, client applications should set their Flagsmith SDK's realtime endpoint URL to the load balancer for the SSE
-service.
-
-## Example: Helm chart
-
-The [Flagsmith Helm chart](https://github.com/Flagsmith/flagsmith-charts) can be used to deploy the SSE service when
-`sse.enabled`is `true`. A minimal example is shown below.
-
-```yaml title="values.yaml"
-sse:
- enabled: true
- image:
- repository: flagsmith/sse
- tag: 4.0.0
- imagePullPolicy: ""
- imagePullSecrets: []
- extraEnv:
- REDIS_HOST: your_redis.example.com
- REDIS_PORT: 6379
- REDIS_USE_SSL: false # set to true if connecting to Redis over TLS
- USE_CLUSTER_MODE: false # set to true if connecting to a Redis cluster, not a single node
- extraEnvFromSecret:
- REDIS_PASSWORD: # Optional, if your Redis requires authentication
- secretName: my_redis_secret
- secretKey: my_redis_password
-```
-
-## Example: Docker Compose
-
-The following Docker Compose file defines a simple Flagsmith deployment. The highlighted lines are required to support
-real-time flag updates.
-
-```yaml title="compose.yaml"
-services:
- # highlight-start
- valkey:
- image: valkey/valkey:latest
- # highlight-end
-
- # highlight-start
- sse:
- image: flagsmith/sse:3.3.0
- environment:
- SSE_AUTHENTICATION_TOKEN: changeme
- REDIS_HOST: valkey
- depends_on:
- - valkey
- # highlight-end
-
- flagsmith:
- # highlight-start
- image: flagsmith/flagsmith-private-cloud:latest
- # highlight-end
- environment:
- # highlight-start
- SSE_AUTHENTICATION_TOKEN: changeme
- SSE_SERVER_BASE_URL: 'http://sse:8000'
- # highlight-end
- DATABASE_URL: postgresql://postgres:password@postgres:5432/flagsmith
- USE_POSTGRES_FOR_ANALYTICS: 'true'
- ENVIRONMENT: production
- DJANGO_ALLOWED_HOSTS: '*'
- ALLOW_ADMIN_INITIATION_VIA_CLI: 'true'
- FLAGSMITH_DOMAIN: 'localhost:8000'
- DJANGO_SECRET_KEY: secret
- ENABLE_ADMIN_ACCESS_USER_PASS: 'true'
- TASK_RUN_METHOD: TASK_PROCESSOR
- ports:
- - '8000:8000'
- depends_on:
- - postgres
-
- # The flagsmith_processor service is only needed if TASK_RUN_METHOD set to TASK_PROCESSOR
- # in the application environment
- flagsmith_processor:
- image: flagsmith/flagsmith:latest
- environment:
- # highlight-start
- SSE_AUTHENTICATION_TOKEN: changeme
- SSE_SERVER_BASE_URL: 'http://sse:8000'
- # highlight-end
- DATABASE_URL: postgresql://postgres:password@postgres:5432/flagsmith
- USE_POSTGRES_FOR_ANALYTICS: 'true'
- depends_on:
- - flagsmith
- command: run-task-processor
-
- postgres:
- image: postgres:15.5-alpine
- environment:
- POSTGRES_PASSWORD: password
- POSTGRES_DB: flagsmith
- container_name: flagsmith_postgres
- volumes:
- - pgdata:/var/lib/postgresql/data
-
-volumes:
- pgdata:
-```
diff --git a/docs/docs/deployment/hosting/real-time/index.md b/docs/docs/deployment/hosting/real-time/index.md
deleted file mode 100644
index 69ef57dcc5b0..000000000000
--- a/docs/docs/deployment/hosting/real-time/index.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Self-hosting real-time updates
-sidebar_label: Real-time flags
-sidebar_position: 30
----
-
-If you are self-hosting Flagsmith, using [real-time flag updates](/advanced-use/real-time-flags.md) requires you to
-deploy additional infrastructure. Start here for an overview of how this infrastructure delivers this capability in your
-self-hosted Flagsmith.
-
-You might also be interested in:
-
-- [How to deploy the infrastructure for real-time flag updates](deployment)
-- [How to operate a real-time flag updates system](operations)
-
-## Prerequisites
-
-Real-time flag updates require an Enterprise subscription.
-
-We assume you already have the [Flagsmith API](/deployment/hosting/locally-api.md) running on your infrastructure.
-
-Real-time flag updates are only delivered for Flagsmith projects that have the "Real-time Updates"
-(`enable_realtime_updates`) setting enabled. This option can be found in **Project Settings** > **SDK Settings**.
-
-## Infrastructure
-
-The **real-time flag updates system** is supported by additional infrastructure that your existing Flagsmith deployment
-integrates with:
-
-- **Server-sent events (SSE) service containers**, running the private
- [`flagsmith/sse`](https://hub.docker.com/repository/docker/flagsmith/sse) Docker image. These serve the real-time
- endpoint that Flagsmith clients can connect to, and receive updates from the
- [task processor](/deployment/configuration/task-processor).
-- A Redis-compatible key-value store that the [task processor](/deployment/configuration/task-processor.md) and SSE
- service can connect to.
-
-This diagram shows how all the components initiate connections to each other:
-
-```mermaid
-graph LR
- api[Task processor]
- sse[SSE service]
- redis[Redis]
- client1[Client]
- client2[Client]
-
- api -->|Publish| sse
- sse -->|Fetch| redis
- client1 -->|Connect| sse
- client2 -->|Connect| sse
-```
-
-## How it works
-
-Real-time flags use a fully distributed and horizontally scalable architecture. Any SSE service instance can respond to
-any client's request. All components can be scaled out or in as needed. Stateful or sticky sessions are not used.
-
-The following sequence diagram shows how a Flagsmith client application connects to the real-time updates stream and
-receives messages when the environment is updated.
-
-```mermaid
-sequenceDiagram
- loop Every second, background
- SSE service->>Redis: Fetch update timestamps for all environments
- SSE service-->SSE service: Update in-memory cache
- end
- Client->>SSE service: Subscribe to environment updates
- SSE service->>Client: Send latest update timestamp
- loop Every second, per subscriber
- SSE service-->SSE service: Read latest update from in-memory cache
- SSE service->>Client: Send latest update timestamp, if changed
- Client-->Client: Store latest update timestamp
- end
- Task processor->>SSE service: Notify environment updated
- SSE service->>Redis: Store latest update timestamp
-```
-
-### SSE service
-
-The **server-sent events (SSE)** service provides the real-time API endpoints that Flagsmith clients connect to. Clients
-connect to any service instance and hold an HTTP connection open for as long as they want to receive updates over SSE.
-
-This service also accepts HTTP requests from the Flagsmith task processor to get notified of environment updates. Redis
-is used as the storage layer to distribute these updates to clients.
-
-[HTTP/2 is recommended](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)
-for client connections, especially if the clients are web browsers.
-
-### Redis
-
-Redis stores a key for each environment containing a timestamp of when it was last updated. SSE service instances will
-periodically fetch all environment's keys and cache them in memory. This cache is used to publish update notifications
-to connected clients.
-
-If Redis or its stored data are unavailable, clients will not be able to receive updates.
-
-## How to use it
-
-Refer to the [deployment guide](deployment) for instructions on setting up the required infrastructure.
-
-The `flagsmith/sse` service provides the following HTTP endpoints:
-
-| Method | Route | Called by | Description | Authentication |
-| ------ | ---------------------------------------------- | ------------------- | -------------------------------------------------------------- | -------------------------------- |
-| GET | `/sse/environments/{environment}/stream` | Client applications | Subscribe to an SSE stream for the given environment. | None |
-| POST | `/sse/environments/{environment}/queue-change` | Task processor | Notify the SSE service that the given environment was updated. | `Token SSE_AUTHENTICATION_TOKEN` |
-
-The stream protocol is described in the
-[documentation for real-time flag updates](/advanced-use/real-time-flags#implementation-details).
diff --git a/docs/docs/deployment/hosting/real-time/operations.md b/docs/docs/deployment/hosting/real-time/operations.md
deleted file mode 100644
index 13eca56d2248..000000000000
--- a/docs/docs/deployment/hosting/real-time/operations.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Operations
-sidebar_label: Operations
-sidebar_position: 30
----
-
-The Flagsmith API is always the primary source of flag data for client applications. Real-time flag updates, as the name
-implies, are only a messaging channel for notifying client applications of any updates. These updates are control
-messages, which do not have any flag data.
-
-This document describes how to operate the real-time updates system for scale and reliability.
-
-## Operational goals
-
-The real-time updates system optimises for the following goals, listed from most to least important:
-
-- Delivery reliability. All subscribers receive all their updates.
-- Operational reliability. In normal circumstances, any part of the system can be replaced at any time while maintaining
- availability overall. Handle unexpected traffic and chaotic events gracefully and without involving humans.
-- Deployment flexibility. Introduce as few dependencies as possible to minimise security and policy risks. Support
- deploying to as many environments as possible, in the cloud or on-premises.
-- Scalability. Handle concurrent subscribers in the order of 100.000s with horizontal scaling.
-- Speed. Deliver updates as quickly as possible.
-
-## Scaling factors
-
-The performance of the real-time updates system will depend mainly on:
-
-- The latency and reliability of your clients' TCP connections
-- How many clients are subscribed at the same time to each SSE instance
-- How many clients are being notified by any environment updates
-- How often environments with active subscribers are updated
-
-## Availability
-
-At least one SSE service instance and one Redis node are required for real-time updates to work. The SSE service will
-reject subscriptions from client applications if Redis is unavailable.
-
-Both Redis and the SSE service can be scaled horizontally to handle more concurrent subscribers and for reliability.
-
-## Message deliverability
-
-Clients that use SSE can only receive data and not send data. As such, they cannot acknowledge they have received an
-update from the SSE service. Deliverability will be limited by the reliability of your clients' TCP connections. This is
-a constraint of the current real-time implementation of all Flagsmith SDKs, which do not have a way to acknowledge
-received messages.
-
-When a client subscribes to real-time updates for an environment, the SSE service will immediately return the latest
-update timestamp. This increases reliability in the event of reconnections and undetectable delivery failures.
-
-The SSE service sends a keep-alive message to each subscriber every 15 seconds if nothing was sent. This is to prevent
-load balancers, NAT gateways or other proxies from closing otherwise inactive connections.
-
-## Latency
-
-The goal is to minimise **end-to-end latency**, which is the time taken between the Flagsmith API acknowledging an
-environment update, and a client getting notified of this update over SSE. Ignoring network delays, this will mainly
-depend on:
-
-- How often the [task processor](https://docs.flagsmith.com/deployment/configuration/task-processor) is polling the API
- for new tasks (by default 2 seconds)
-- How long the "environment updated" tasks take to execute (varies on task processor and database load)
-- How fast Redis can acknowledge the update (usually milliseconds)
-- How fast the relevant SSE service instances can pull from Redis (by default every second)
-- How often the SSE service checks the in-memory cache for updates for each subscriber (by default every second)
-- Network delay between SSE service instances and client applications
-
-## Storage
-
-Redis stores a timestamp of when each environment was last updated, in a single key.
-This key is named `sse:updated_at_json`.
-
-Each timestamp is stored for up to 5 minutes.
-
-## Security
-
-Subscribing to real-time updates via the SSE service does not require authentication. The SSE service allows all CORS
-requests on all endpoints.
-
-The task processor authenticates with the SSE service when publishing an update by using a shared secret. This secret is
-configured using the `SSE_AUTHENTICATION_TOKEN` environment variable. For example:
-
-```
-curl -X POST -H "Authorization: Token $SSE_AUTHENTICATION_TOKEN" -H "Content-Type: application/json" -d' {"updated_at":"2023-01-12T18:06:42.028060"}' http://localhost:8088/sse/environments/abcxyz/queue-change
-```
-
-## Monitoring
-
-Make sure you are [monitoring the task processor](/deployment/configuration/task-processor#monitoring), as the SSE
-service depends on it.
-
-The SSE service exposes a health check endpoint at `/health`, which can be used for liveness and readiness checks. It
-responds with 200 if the SSE service can accept incoming connections and is connected to Redis by sending it a
-[`PING` command](https://redis.io/docs/latest/commands/ping/).
-
-## Metrics
-
-The SSE service does not expose any metrics.
-
-
-
-## Benchmarking
-
-The SSE service is constrained by:
-
-- The number of open HTTP connections it can keep open at the same time (memory, sockets)
-- The number of subscribers that will receive a message after an update (CPU and network)
-
-An 11-core M3 MacBook Pro with 18 GB of memory can support at least 10.000 concurrent subscribers with simultaneous
-publishing at ~1 second latency, constrained by the number of open sockets. This was tested with a
-[k6 script](benchmark.js) that opens many subscriptions to one environment on the SSE service while pushing updates to
-that environment.
-
-You can monitor the load test while it's running by connecting to the SSE service as another subscriber:
-
-```
-$ curl -H "Accept:text/event-stream" -N -i http://localhost:8088/sse/environments/load_test/stream
-HTTP/1.1 200 OK
-Cache-Control: no-cache
-Connection: keep-alive
-Content-Type: text/event-stream
-Date: Mon, 09 Dec 2024 16:20:00 GMT
-Transfer-Encoding: chunked
-
-event: environment_updated
-data: {"updated_at": 1735229888.76}
-retry: 15000
-
-event: environment_updated
-data: {"updated_at": 1735229899.44}
-retry: 15000
-```
-
-The `queue-change` endpoint can achieve at least 20.000 requests per second on the same hardware.
-
-If you want to benchmark Redis itself, you can use its
-[first-party benchmarking tools](https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/benchmarks/).
diff --git a/docs/docs/deployment/index.md b/docs/docs/deployment/index.md
deleted file mode 100644
index 1e1fb2e5dee9..000000000000
--- a/docs/docs/deployment/index.md
+++ /dev/null
@@ -1,745 +0,0 @@
----
-title: Deployment
-sidebar_position: 1
----
-
-## Flagsmith SaaS Platform
-
-If you would rather skip the hosting and jump straight to integrating Flagsmith with your own application, you can use
-[https://flagsmith.com/](https://flagsmith.com/) right now. We have
-[paid plans with pricing to suit both startups and enterprise customers alike](https://flagsmith.com/pricing).
-
-## Terraform Templates
-
-We have a number of example deployments across different providers and orchestration frameworks in our
-[Terraform Examples](https://github.com/Flagsmith/terraform-examples) repository.
-
-## One Click Installers
-
-[](https://cloud.digitalocean.com/apps/new?repo=https://github.com/flagsmith/flagsmith/tree/main)
-
-[](https://render.com/deploy?repo=https://github.com/flagsmith/flagsmith/tree/main)
-
-[](https://railway.app/template/36mGw8?referralCode=DGxv1S)
-
-
-
-We're big fans of [Fly.io](https://Fly.io)! You can deploy to fly.io really easily:
-
-```bash
-git clone git@github.com:Flagsmith/flagsmith.git
-cd flagsmith
-flyctl postgres create --name flagsmith-flyio-db
-flyctl apps create flagsmith-flyio
-flyctl postgres attach --postgres-app flagsmith-flyio-db
-flyctl deploy
-```
-
-Fly.io has a global application namespace, and so you may need to change the name of the application defined in
-[`fly.toml`](https://github.com/Flagsmith/flagsmith/blob/main/fly.toml) as well as the commands above.
-
-### Caprover
-
-You can also deploy to a [Caprover Server](https://caprover.com/) with
-[One Click Apps](https://caprover.com/docs/one-click-apps.html).
-
-## Self Hosting Overview
-
-You will need to run through the following steps to get set up:
-
-1. Create a Postgres database to store the Flagsmith data.
-2. Deploy the API and set up DNS for it. If you are using health-checks, make sure to use `/health` as the health-check
- endpoint.
-3. Visit `http://Environment variables
- -```ruby -ENVIRONMENT_KEY_PAIRS='[{"server_side_key":"ser.your_server_side_key_1","client_side_key":"your_client_side_key_1"}]' -API_POLL_FREQUENCY_SECONDS=5 -LOGGING='{"log_level":"DEBUG","log_format":"json"}' -``` - -getTrait(key:string)=> string|number|boolean | Once used with an identified user you can get the value of any trait that is set for them e.g. `flagsmith.getTrait("accepted_cookie_policy")` |
| getAllTraits()=> Record<string,string|number|boolean> | Once used with an identified user you can get a key value pair of all traits that are set for them e.g. `flagsmith.getTraits()` |
| getState()=>IState | Retrieves the current state of flagsmith, useful in NextJS / isomorphic applications. `flagsmith.getState()` |
-| setState(state: IState)=>void | Set the current state of flagsmith, [useful in NextJS / isomorphic applications.](/clients/next-ssr#comparing-ssr-and-client-side-flagsmith-usage) e.g. `flagsmith.setState({identity: 'mary@mycompany.com'})`. |
+| setState(state: IState)=>void | Set the current state of flagsmith, [useful in NextJS / isomorphic applications.](/integrating-with-flagsmith/sdks/client-side-sdks/nextjs-and-ssr) e.g. `flagsmith.setState({identity: 'mary@mycompany.com'})`. |
| setTrait(key:string, value:string|number|boolean)=> Promise<IFlags> | Once used with an identified user you can set the value of any trait relevant to them e.g. `flagsmith.setTrait("accepted_cookie_policy", true)` |
| setTraits(values:Record\)=\> Promise<IFlags> | Set multiple traits e.g. `flagsmith.setTraits({foo:"bar",numericProp:1,boolProp:true})`. Setting a value of null for a trait will remove that trait. |
| incrementTrait(key:string, value:number)=> Promise<IFlags> | You can also increment/decrement a particular trait them e.g. `flagsmith.incrementTrait("click_count", 1)` |
diff --git a/docs/docs/clients/client-side/nextjs-and-ssr.md b/docs/docs/integrating-with-flagsmith/sdks/client-side-sdks/nextjs-and-ssr.md
similarity index 91%
rename from docs/docs/clients/client-side/nextjs-and-ssr.md
rename to docs/docs/integrating-with-flagsmith/sdks/client-side-sdks/nextjs-and-ssr.md
index cb17580c0917..b096cfeb8e02 100644
--- a/docs/docs/clients/client-side/nextjs-and-ssr.md
+++ b/docs/docs/integrating-with-flagsmith/sdks/client-side-sdks/nextjs-and-ssr.md
@@ -2,7 +2,6 @@
title: Flagsmith React SDK
sidebar_label: Next.js and SSR
description: Manage your Feature Flags and Remote Config with NextJS and SSR.
-slug: /clients/next-ssr
---
The JavaScript Library contains a bundled isomorphic library, allowing you to fetch flags in the server and hydrate your
@@ -34,15 +33,15 @@ settings page.
## Comparing SSR and client-side Flagsmith usage
-The SDK is initialised and used in the same way as the [JavaScript](/clients/javascript) and [React](/clients/react)
+The SDK is initialised and used in the same way as the [JavaScript](/integrating-with-flagsmith/sdks/client-side-sdks/javascript) and [React](/integrating-with-flagsmith/sdks/client-side-sdks/react)
SDK. The main difference is that Flagsmith should be imported from `flagsmith/isomorphic`.
The main flow with Next.js and any JavaScript-based SSR can be as follows:
1. Fetch the flags on the server, optionally passing an identity to
- [`flagsmith.init({})`](/clients/javascript#initialisation-options)
-2. Pass the resulting state to the client with [`flagsmith.getState()`](/clients/javascript#available-functions)
-3. Initialise flagsmith on the client with [`flagsmith.setState(state)`](/clients/javascript#available-functions)
+ [`flagsmith.init({})`](/integrating-with-flagsmith/sdks/client-side-sdks/javascript#initialisation-options)
+2. Pass the resulting state to the client with [`flagsmith.getState()`](/integrating-with-flagsmith/sdks/client-side-sdks/javascript#available-functions)
+3. Initialise flagsmith on the client with [`flagsmith.setState(state)`](/integrating-with-flagsmith/sdks/client-side-sdks/javascript#available-functions)
### Example: Initialising the SDK with Next.js
@@ -154,7 +153,7 @@ export function MyComponent() {
}
```
-From this point on, the SDK usage is the same as the [React SDK Guide](/clients/react)
+From this point on, the SDK usage is the same as the [React SDK Guide](/integrating-with-flagsmith/sdks/client-side-sdks/react)
### Example: Flagsmith with Next.js middleware
@@ -223,4 +222,4 @@ Step 3: Optionally force the client to fetch a fresh set of flags
flagsmith.getFlags();
```
-From that point the SDK usage is the same as the [JavaScript SDK Guide](/clients/javascript)
+From that point the SDK usage is the same as the [JavaScript SDK Guide](/integrating-with-flagsmith/sdks/client-side-sdks/javascript)
diff --git a/docs/docs/clients/client-side/react.md b/docs/docs/integrating-with-flagsmith/sdks/client-side-sdks/react.md
similarity index 92%
rename from docs/docs/clients/client-side/react.md
rename to docs/docs/integrating-with-flagsmith/sdks/client-side-sdks/react.md
index 8238e835c8fd..10a73d0e7139 100644
--- a/docs/docs/clients/client-side/react.md
+++ b/docs/docs/integrating-with-flagsmith/sdks/client-side-sdks/react.md
@@ -2,7 +2,6 @@
title: Flagsmith React SDK
sidebar_label: React and React Native
description: Manage your Feature Flags and Remote Config with React and React Native Hooks.
-slug: /clients/react
---
This library includes React/React Native Hooks allowing you to query individual features and flags that limit
@@ -28,7 +27,7 @@ npm i flagsmith --save
The React Native SDK shares the exact same implementation of Flagsmith, however, requires an implementation of
AsyncStorage to be provided (e.g. @react-native-community/async-storage) in order to utilise analytics and caching. See
-[here](/clients/javascript#initialisation-options).
+[here](/integrating-with-flagsmith/sdks/client-side-sdks/javascript#initialisation-options).
:::
@@ -60,12 +59,12 @@ export function AppRoot() {
```
Providing options to the Flagsmith provider will initialise the client, the API reference for these options can be found
-[here](/clients/javascript#initialisation-options).
+[here](/integrating-with-flagsmith/sdks/client-side-sdks/javascript#initialisation-options).
:::tip Initialising before rendering the FlagsmithProvider
If you wish to initialise the Flagsmith client before React rendering (e.g. in redux, or SSR) you can do so by calling
-[flagsmith.init](/clients/javascript#example-initialising-the-sdk) and provide no options property to the
+[flagsmith.init](/integrating-with-flagsmith/sdks/client-side-sdks/javascript#example-initialising-the-sdk) and provide no options property to the
FlagsmithProvider component.
:::
@@ -104,7 +103,7 @@ You can find the exact definitions of these types
| ------------------------ | :------------------------------------------------------------------------------------------------------------: | -------: | ------------: |
| `flagsmith: IFlagsmith` | Defines the flagsmith instance that the provider will use. | **YES** | null |
| `options?: ` IInitConfig | Initialisation options to use. If you don't provide this you will have to call flagsmith.init elsewhere. | | null |
-| `serverState?: IState` | Used to pass an initial state, in most cases as a result of SSR flagsmith.getState(). See [Next.js and SSR](/) | | null |
+| `serverState?: IState` | Used to pass an initial state, in most cases as a result of SSR flagsmith.getState(). See [Next.js and SSR](/integrating-with-flagsmith/sdks/client-side-sdks/nextjs-and-ssr) | | null |
### Step 3: Using useFlagsmith to access the Flagsmith instance
diff --git a/docs/docs/clients/index.md b/docs/docs/integrating-with-flagsmith/sdks/index.md
similarity index 86%
rename from docs/docs/clients/index.md
rename to docs/docs/integrating-with-flagsmith/sdks/index.md
index bd5f5877216c..7cc38276a2b4 100644
--- a/docs/docs/clients/index.md
+++ b/docs/docs/integrating-with-flagsmith/sdks/index.md
@@ -1,11 +1,12 @@
---
description: Manage your Feature Flags and Remote Config in your REST APIs.
sidebar_position: 1
+sidebar_label: SDKs
---
# SDKs Overview
-Flagsmith ships with SDKs for a bunch of different programming languages. We also have a [REST API](rest.md) that you
+Flagsmith ships with SDKs for a bunch of different programming languages. We also have a [REST API](/integrating-with-flagsmith/flagsmith-api-overview) that you
can use if you want to consume the API directly.
Our SDKs are split into two different groups. These SDKs have different methods of operation due to the differences in
@@ -26,28 +27,28 @@ depending on the SDK you are using.
Client-side SDKs run in web browsers or on mobile devices. These runtimes execute within _untrusted environments_.
Anyone using the Javascript SDK in a web browser, for example, can find the Client-side SDK, create a new Identity, look
at their flags and
-[potentially write Traits to the Identity](/system-administration/security#preventing-client-sdks-from-setting-traits).
+[potentially write Traits to the Identity](/administration-and-security/governance-and-compliance/security#preventing-client-sdks-from-setting-traits).
Client-side SDKs are also limited to the
-[types of data that they have access to](/guides-and-examples/integration-approaches#segment-and-targeting-rules-are-not-leaked-to-the-client).
+[types of data that they have access to](/best-practices/integration-approaches#segment-and-targeting-rules-are-not-leaked-to-the-client).
Client-side Environment keys are designed to be shared publicly, for example in your HTML/JS code that is sent to a web
browser.
-Client-side SDKs hit our [Edge API](../advanced-use/edge-api.md) directly to retrieve their flags.
+Client-side SDKs hit our [Edge API](/deployment-self-hosting/edge-proxy) directly to retrieve their flags.
Read more about our Client-side SDKs for your language/platform:
-- [Javascript](/clients/javascript)
-- [Android/Kotlin](/clients/android)
-- [Flutter](/clients/flutter)
-- [iOS/Swift](/clients/ios)
-- [React & React Native](/clients/react)
-- [Next.js, Svelte and SSR](/clients/next-ssr)
+- [Javascript](/integrating-with-flagsmith/sdks/client-side-sdks/javascript)
+- [Android/Kotlin](/integrating-with-flagsmith/sdks/client-side-sdks/android)
+- [iOS/Swift](/integrating-with-flagsmith/sdks/client-side-sdks/ios)
+- [React](/integrating-with-flagsmith/sdks/client-side-sdks/react)
+- [Next.js and SSR](/integrating-with-flagsmith/sdks/client-side-sdks/nextjs-and-ssr)
+- [Flutter](/integrating-with-flagsmith/sdks/client-side-sdks/flutter)
## Server-side SDKs
-[Server-side SDKs](/clients/server-side) run within _trusted environments_ - typically the server infrastructure that
+[Server-side SDKs](/integrating-with-flagsmith/sdks/server-side) run within _trusted environments_ - typically the server infrastructure that
you have control over. Because of this, you should not share your Server-side Environment keys publicly; they should be
treated as secret.
@@ -82,7 +83,7 @@ the Flag Engine, and the engine runs within your server environment within the F
You have to configure the SDK to run in Local Evaluation mode. See the
-[SDK configuration options](/clients/server-side#configuring-the-sdk) for details on how to do that in your particular language.
+[SDK configuration options](/integrating-with-flagsmith/sdks/server-side#configuring-the-sdk) for details on how to do that in your particular language.
When the SDK is initialised in Local Evaluation mode, it grabs the entire set of details about the Environment from the
Flagsmith API. For a given Environment, this includes:
@@ -96,7 +97,7 @@ within your server infrastructure.
:::info
-**[Edge API](advanced-use/edge-api.md) only**: When using identity overrides in local evaluation:
+**[Edge API](/deployment-self-hosting/edge-proxy) only**: When using identity overrides in local evaluation:
- Keep overrides count under 500.
- Make sure your environment settings enable it.
@@ -162,7 +163,7 @@ for the relevant language platform for details.
network request.
If this approach does not work for you (generally for reasons of latency or overly chatty networking) you should
-consider Local Evaluation mode (explained below) or the [Edge Proxy](/advanced-use/edge-proxy).
+consider Local Evaluation mode (explained below) or the [Edge Proxy](/deployment-self-hosting/edge-proxy).
### Local Evaluation Network Model
@@ -298,7 +299,7 @@ situations:
- If you want to work with Flagsmith programatically, for example when creating and deleting Environments as part of a
CI/CD process.
-- When using the [Terraform Provider](/integrations/terraform).
+- When using the [Terraform Provider](/third-party-integrations/ci-cd/terraform).
These keys are secret and should not be shared.
@@ -340,7 +341,7 @@ When running in Local Evaluation mode, our SDKs expect to be run as long-lived p
Lambda either break this contract or make it much more complicated. As a result, we do not recommend running our SDKs in
Local Evaluation mode on top of platforms like Lambda where you do not have complete control over process lifetimes.
-Our [Edge Proxy](/advanced-use/edge-proxy/) is a good candidate if you need to run local evaluation mode alongside
+Our [Edge Proxy](/deployment-self-hosting/edge-proxy) is a good candidate if you need to run local evaluation mode alongside
serverless platforms.
:::
@@ -353,10 +354,10 @@ are all computed locally.
- Identities and their Traits are **not** read from or written to the Flagsmith API, and so are not persisted in the
datastore. This means that you have to provide the full complement of Traits when requesting the Flags for a
particular Identity. Our SDKs all provide relevant methods to achieve this.
-- [Analytics-based Integrations](/integrations#analytics-platforms) do not run.
- [Flag Analytics](/advanced-use/flag-analytics) do still work, if enabled within the
- [SDK setup](/clients/server-side#configuring-the-sdk).
-- **[Edge API](advanced-use/edge-api.md) only**: Currently, Flagsmith SDKs support up to ~500 identity overrides, depending on flag value sizes and segment count, when used with
+- [Analytics-based Integrations](/third-party-integrations#analytics-platforms) do not run.
+- [Flag Analytics](/managing-flags/flag-analytics) do still work, if enabled within the
+ [SDK setup](/integrating-with-flagsmith/sdks/server-side#configuring-the-sdk).
+- **[Edge API](/deployment-self-hosting/edge-proxy) only**: Currently, Flagsmith SDKs support up to ~500 identity overrides, depending on flag value sizes and segment count, when used with
Edge API. If you store more than 1MB of environment document data, you will need to query the Edge API endpoint directly and use
pagination:
diff --git a/docs/docs/clients/server-side.mdx b/docs/docs/integrating-with-flagsmith/sdks/server-side.mdx
similarity index 97%
rename from docs/docs/clients/server-side.mdx
rename to docs/docs/integrating-with-flagsmith/sdks/server-side.mdx
index f5c6f3c1d2d7..a70cb49c3f62 100644
--- a/docs/docs/clients/server-side.mdx
+++ b/docs/docs/integrating-with-flagsmith/sdks/server-side.mdx
@@ -1,7 +1,7 @@
---
description: Manage your Feature Flags and Remote Config in your Server Side Applications.
sidebar_label: Server Side
-sidebar_position: 2
+sidebar_position: 30
---
import CodeBlock from '@theme/CodeBlock';
@@ -21,7 +21,7 @@ import {
:::tip
Server Side SDKs can run in 2 different modes: Local Evaluation and Remote Evaluation. We recommend
-[reading up about the differences](/clients#server-side-sdks) first before integrating the SDKS into your applications.
+[reading up about the differences](/integrating-with-flagsmith/integration-overview) first before integrating the SDKS into your applications.
:::
@@ -574,25 +574,25 @@ secret_button_feature_value = Flagsmith.Client.get_feature_value(flags, "secret_
+