docs: Update hosting strategies page (#9729)

website/docs/feature-flag-tutorials/serverless/implementing-feature-flags-in-aws-lambda.md

@@ -164,7 +164,7 @@ curl https://z5w5lkzlsozutfhaixbjsj27cm0dhnfh.lambda-url.eu-north-1.on.aws
 
 Mastering feature flags in serverless? This guide demonstrated the surprisingly simple use of Unleash SDK. Remember, avoid initializing the SDK multiple times within your serverless function for smooth operation.
 
-Need to scale your AWS Lambda function to thousands of requests per second (RPS)? Consider [Unleash Edge](/understanding-unleash/proxy-hosting), which uses edge computing to scale your Unleash usage. You can scale in any matter you see fit - either hosted entirely in your infrastructure on your own edge services or fully managed by Unleash.
+Need to scale your AWS Lambda function to thousands of requests per second (RPS)? Consider [Unleash Edge](/understanding-unleash/hosting-options#unleash-edge-options), which uses edge computing to scale your Unleash usage. You can scale in any matter you see fit - either hosted entirely in your infrastructure on your own edge services or fully managed by Unleash.
 
 :::note Lambda Latency
 

website/docs/feature-flag-tutorials/use-cases/security-compliance.md

@@ -150,7 +150,7 @@ Let’s say a project owner wants to update a rollout strategy so that a new fea
 
 You could also schedule changes by using the [date and time operators](/reference/activation-strategies#date-and-time-operators) in [strategy constraints](/reference/activation-strategies#constraints). However, when you have change requests configured in the project, we recommend using the schedule feature in change requests, as it is a faster and simpler approach.
 
-For more recommendations, read our section on [change management workflow](/topics/feature-flags/best-practices-using-feature-flags-at-scale#6-implement-flag-approval-workflows-early) from _Using Feature Flags at Scale_.
+For more recommendations, read our section on [change management workflow](/topics/feature-flags/best-practices-using-feature-flags-at-scale#implement-flag-approval-workflows-early) from _Using Feature Flags at Scale_.
 
 Now that we covered change requests as a practical tool for both feature management oversight and good security posture, let’s explore Unleash event logs as an audit logging system for your organization.
 
@@ -191,7 +191,7 @@ Protecting data is critical within any software tool. It’s a security best pra
 
 This is a potential attack surface area that you wouldn’t want to be the root of data breaches or unauthorized access in your system. That’s why Unleash was built in a way where integrating feature flags into your services won’t be a weak link in your organization’s ability to ship software safely.
 
-With Unleash, you can architect your feature flagging solution in a way that all user data stays within your applications. When using server-side SDKs, user data remains within your application and is never shared with the Unleash server regardless of your setup. For client-side SDKs, you can retain all user data within your applications by either [self-hosting Unleash](/understanding-unleash/proxy-hosting#you-host-everything), or [self-hosting Unleash Edge](/understanding-unleash/proxy-hosting#unleash-hosts-the-api-you-host-edge). Read more on the [Unleash architecture here](/understanding-unleash/unleash-overview).
+With Unleash, you can architect your feature flagging solution in a way that all user data stays within your applications. When using server-side SDKs, user data remains within your application and is never shared with the Unleash server regardless of your setup. For client-side SDKs, you can retain all user data within your applications by either [self-hosting Unleash](/understanding-unleash/hosting-options#), or [self-hosting Unleash Edge](/understanding-unleash/hosting-options#unleash-edge-options). Read more on the [Unleash architecture here](/understanding-unleash/unleash-overview).
 
 ### Use Unleash Edge for enterprise-grade data privacy
 

website/docs/reference/change-requests.mdx

@@ -116,7 +116,7 @@ You can preconfigure change request requirements at the environment level. When
 
 You can use environment-level change requests in two ways:
 
-* **As defaults**: Set default approvals per environment, but allow project [Owners](/reference/rbac#projects#predefined-roles) and users with [project update permissions](/reference/rbac#projects) to override the defaults within their projects.
+* **As defaults**: Set default approvals per environment, but allow project [Owners](/reference/rbac#predefined-roles) and users with [project update permissions](/reference/rbac#projects) to override the defaults within their projects.
 * **As enforced requirements**: Set mandatory approvals for a given environment across all projects. To fully enforce this in a project, ensure that the project has no Owner or users with project update permissions—this prevents any change request modifications at the project level.
 
 You can predefine environment-level change requests when creating or editing an environment in **Configure > Environments**.

website/docs/reference/sdks/index.mdx

@@ -170,7 +170,7 @@ Unless the SDK supports [bootstrapping](#bootstrapping), it needs to connect to
 
 ### Bootstrapping
 
-By default, all SDKs reach out to the Unleash server at startup to fetch their flag configuration. Additionally, most of the [server-side SDKs](#server-side-sdk-compatibility-table) and Unleash Edge support bootstrapping, which allows them to get their flag configuration from a file, the environment, or other local resources. These SDKs can function without any network connection.
+By default, all SDKs reach out to the Unleash server at startup to fetch their flag configuration. Additionally, most of the [server-side SDKs](#server-side-sdks) and Unleash Edge support bootstrapping, which allows them to get their flag configuration from a file, the environment, or other local resources. These SDKs can function without any network connection.
 
 Bootstrapping is also supported by the following frontend SDKs:
 

website/docs/reference/terraform.mdx

@@ -14,7 +14,7 @@ description: "Set up and configure your Unleash instance using infastructure as
 
 The [Unleash Terraform provider](https://github.com/Unleash/terraform-provider-unleash) enables you to manage and configure Unleash programmatically, leveraging infrastructure as code (IaC) for automated and scalable configuration.
 
-This provider is designed to help you with the **initial setup and configuration** of an instance. The provider does not support managing feature flags through Terraform. Since most [feature flags are short-lived](/topics/feature-flags/feature-flag-best-practices#3-make-flags-short-lived), we recommend managing them through the Unleash Admin UI.
+This provider is designed to help you with the **initial setup and configuration** of an instance. The provider does not support managing feature flags through Terraform. Since most [feature flags are short-lived](/topics/feature-flags/feature-flag-best-practices#2-make-flags-short-lived), we recommend managing them through the Unleash Admin UI.
 
 For a detailed video tutorial, check out [Managing Unleash through Terraform](https://www.youtube.com/watch?v=B4OIBC1u1ns).
 For more examples of specific resources and data sources, visit the [Terraform registry](https://registry.terraform.io/providers/Unleash/unleash/latest/docs/data-sources/permission).

website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.mdx

@@ -50,7 +50,7 @@ Whenever possible, evaluate your flag in a single place. Centralizing the evalua
 When rolling out complex features, changes often span multiple parts of a system—whether that's modules within a single application or services in a distributed architecture. It might seem convenient to use the same feature flag across all components and evaluate it locally in each one, but this can lead to problems.
 
 As a user request moves through the system, it hits different parts at different times. Even with synchronized flag states, there's a risk that the flag's value changes between evaluations, resulting in inconsistent behavior for the user.
-Particularly in distributed systems, we cannot assume all parts of the system are perfectly synchronized, as networks are unreliable and can experience errors at any time. Most feature flag systems prioritize [availability over consistency](./feature-flag-best-practices#2-prioritize-availability-over-consistency). By only evaluating a feature flag once, we guarantee a consistent experience for our users.
+Particularly in distributed systems, we cannot assume all parts of the system are perfectly synchronized, as networks are unreliable and can experience errors at any time. Most feature flag systems prioritize [availability over consistency](./feature-flag-best-practices#3-prioritize-availability-over-consistency). By only evaluating a feature flag once, we guarantee a consistent experience for our users.
 
 Using the same flag in multiple places fragments the control logic and breaks the single responsibility principle, making code [harder to understand and maintain](https://www.getunleash.io/simplicity).
 
@@ -113,7 +113,7 @@ Our advice: Keep it simple. If you use parent-child structures, avoid overlappin
 
 Both feature flags and configuration settings control an application's behavior. However, it's crucial to distinguish between feature flagging systems and configuration management systems and use each for its intended purpose.
 
-[Feature flags are temporary and dynamic](https://docs.getunleash.io/what-is-a-feature-flag). They give you [runtime control](./feature-flag-best-practices#1-enable-runtime-control) to enable or disable functionality in a live environment—perfect for things like [short-lived experiments](./feature-flag-best-practices#3-make-flags-short-lived), such as A/B testing or gradual rollouts.
+[Feature flags are temporary and dynamic](https://docs.getunleash.io/what-is-a-feature-flag). They give you [runtime control](./feature-flag-best-practices#1-enable-runtime-control) to enable or disable functionality in a live environment—perfect for things like [short-lived experiments](./feature-flag-best-practices#2-make-flags-short-lived), such as A/B testing or gradual rollouts.
 
 Configurations, on the other hand, are usually static and long-lived. They often contain sensitive data like API keys or access credentials, which need to be encrypted and carefully managed. Using feature flags for configuration can create security vulnerabilities and operational issues. Most flag systems don't encrypt values the way configuration management tools do.
 

website/docs/topics/feature-flags/feature-flag-best-practices.mdx

@@ -219,7 +219,7 @@ Keeping the feature flag payload small results in:
 - **Improved system reliability**: Delivering smaller, more manageable payloads minimizes the risk of network timeouts and failures.
 - **Ease of monitoring and debugging**: Smaller payloads are easier to monitor and debug, making issue resolution faster.
 
-For more insights into reducing payload size, visit our [Best practices for using feature flags at scale](/topics/feature-flags/best-practices-using-feature-flags-at-scale#14-avoid-giant-feature-flag-targeting-lists) guide.
+For more insights into reducing payload size, visit our [Best practices for using feature flags at scale](/topics/feature-flags/best-practices-using-feature-flags-at-scale#using-large-targeting-lists) guide.
 
 ## 10. Prioritize consistent user experience
 

website/docs/understanding-unleash/hosting-options.mdx

@@ -0,0 +1,133 @@
+---
+title: Unleash hosting options
+description: "Explore the flexible hosting options for Unleash and Unleash Edge, including cloud-hosted, hybrid, and self-hosted deployments. Compare features, scalability, and support to find the right setup for your team."
+---
+
+Unleash provides flexible hosting options for Unleash and [Unleash Edge](../generated/unleash-edge.md), allowing you to meet specific requirements for scaling, privacy, and infrastructure control. This document covers the main hosting models for the Unleash API server and Unleash Edge. Choosing a hosting model is a key architectural decision.
+
+Before considering hosting options, we recommend that you explore the [Unleash architecture and its key components](./unleash-overview).
+
+
+:::note Availability
+
+The availability of hosting options may depend on your plan. See the [Unleash Pricing page](https://www.getunleash.io/pricing) for details.
+
+:::
+
+## Cloud-hosted
+
+In this setup, Unleash manages the infrastructure for both the Unleash API server and Unleash Edge.
+
+![An architecture diagram of Enterprise Edge](/img/hosting-cloud-hosted.png)
+
+### Unleash Cloud
+This fully-managed solution is designed for high availability, featuring the following key aspects:
+- **Multi-AZ deployments:** Services are deployed across multiple Availability Zones (AZs) within a region. This means that your data and applications are distributed across different physical locations, reducing the risk of downtime due to localized failures.
+- **Hot standby replica:** A continuously synchronized replica database stands ready in a separate AZ to take over if the primary database fails.
+- **Automatic failover:** The system automatically detects AZ failures and fails over to the standby replica with minimal disruption.
+- **Disaster recovery:** Full backups are stored in a separate region. A standby Unleash cluster in the backup region can take over in the rare event of a complete primary region failure.
+- **CDN for static assets:** The Admin UI and static resources are served via a global Content Delivery Network (CDN) for fast loading times worldwide.
+
+### Unleash Enterprise Edge Cloud
+
+[Unleash Enterprise Edge](https://www.getunleash.io/unleash-enterprise-edge), our cloud-hosted Edge offering, provides enterprise-grade security, full observability, and multi-region redundancy. Here are the key aspects of the offering:
+
+- **Multi-AZ deployments:** Edge instances run across at least two AZs within each region.
+- **Multi-region deployment:** Edge is available in multiple global regions. SDKs automatically connect to the nearest available region. Traffic fails over to other regions if one region becomes unavailable.
+- **Resilience:** Edge caches flag configurations locally. SDKs connected to Edge can continue evaluating flags even if the connection to the primary Unleash API server is temporarily lost.
+- **Scalability and performance:** Edge acts as a read-only cache, handling numerous SDK connections. Instead of relying on periodic polling, Edge and the Unleash server use a high-speed streaming protocol to sync flag changes in milliseconds.
+
+[Enterprise Edge](https://www.getunleash.io/unleash-enterprise-edge) is available in the following 11 global data centers across North America, Europe, and Asia, allowing you to achieve low latency, high resilience, and optimal performance:
+- US East (Ohio): `us-east-2`
+- US East (N. Virginia): `us-east-1`
+- US West (Oregon): `us-west-2`
+- Asia Pacific (Mumbai): `ap-south-1`
+- Asia Pacific (Singapore): `ap-southeast-1`
+- Asia Pacific (Sydney): `ap-southeast-2`
+- Asia Pacific (Tokyo): `ap-northeast-1`
+- Europe (Frankfurt): `eu-central-1`
+- Europe (Ireland): `eu-west-1`
+- Europe (London): `eu-west-2`
+- Europe (Paris): `eu-west-3`
+
+
+## Hybrid
+
+In this hybrid model, Unleash hosts the API server and Admin UI, while you host Unleash Edge instances yourself. You run Edge as a container within your own infrastructure, close to your applications. This gives you control over Edge's location and its network environment. Unleash manages the Unleash API, the Admin UI, and the backing database in our AWS setup; the API and the UI run together in a Kubernetes deployment and connect to an Amazon RDS database.
+
+![An architecture diagram of using Edge in a setup where Unleash hosts the API and you host the Edge.](/img/hosting-hybrid.png)
+
+In this setup, you need to configure Edge and the SDKs.
+
+### Configure Edge
+
+Set the `UPSTREAM_URL` environment variable to your Unleash instance URL (e.g., `https://<your-instance>.app.unleash-hosted.com/api`):
+    - Provide the Client API tokens using the `TOKENS` environment variable. This allows Edge to fetch the correct flag configurations on startup.
+    - Run the Edge container. Example using Docker:
+        ```bash
+        docker run -p 3063:3063 \
+        -e UPSTREAM_URL='<UPSTREAM_URL>' \
+        -e TOKENS='<CLIENT_API_TOKEN>' \
+        unleashorg/unleash-edge:latest edge
+        ```
+    - To add configurations for other projects/environments dynamically after startup, you can send an authorized request to Edge using a different Client API token:
+        ```bash
+        curl --location --request GET 'http://<your-edge-host>:3063/api/client/features' \
+        --header 'Authorization: <NEW_CLIENT_API_TOKEN>'
+        ```
+
+### Configure the SDKs
+
+Point your SDKs to your self-hosted Edge instance's URL.
+    - **Server-side SDKs:** Use the `/api/client` endpoint and a Client token. Edge returns the full flag configuration for the token's scope.
+    - **Client-side SDKs:** Use the `/api/frontend` endpoint and a Frontend token. Edge evaluates flags based on the context provided by the SDK and returns only the evaluated feature flags.
+
+
+## Self-hosted
+
+In this model, you host and manage all components: the Unleash API server, the database, the Admin UI, and Unleash Edge instances.
+
+![An architecture diagram of using the Edge in a single-region, self-hosted setup.](/img/hosting-self-hosted.png)
+
+This option offers maximum flexibility and control over your feature management infrastructure but requires the most operational effort.
+
+In addition to [configuring Edge](#configure-edge), you must also set up the Unleash server and its database following our [self-hosting guide](../using-unleash/deploy/getting-started).
+
+
+## Unleash Edge options
+
+### Unleash Enterprise Edge vs Unleash Edge Open-Source
+
+The following table compares the key differences between using the Unleash Enterprise Edge Cloud and Unleash Edge Open-Source.
+
+| Feature                 | Unleash Enterprise Edge Cloud                                                       | Unleash Edge: Open-Source                                                                                    |
+| :---------------------- | :------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------- |
+| **Infrastructure**| Managed entirely by Unleash                                                                  | Managed entirely by you                                                                                     |
+| **Operational effort** | Minimal setup and no ongoing maintenance required from you                           | Requires setup, deployment, scaling, monitoring, and maintenance effort from you                 |
+| **Infrastructure cost** | Included in Unleash Enterprise Edge fee                                                   | Pay for the compute, network, storage, and operational overhead on your infrastructure                 |
+| **Setup and configuration**| Point your SDKs to the provided Unleash Edge URL                                      | Pull Docker image, configure upstream URL and API tokens via environment variables, deploy and manage the containers |
+| **Scalability** | Handled automatically by Unleash                                                            | Monitor load and scale Edge instances manually or via automation      |
+| **High availability** | Managed by Unleash with multi-AZ and multi-region redundancy and failover       | Requires you to design and implement high availability (e.g., multiple instances, load balancers, potentially across AZs) |
+| **Security and updates** | Handled automatically by Unleash                                                            | You manage host and container security, network rules, and apply Edge updates    |
+| **Observability** | Monitor health, replica count, memory usage, CPU, latency, and more directly from Unleash  | You need to set up and manage your own monitoring and logging solutions for Edge  |
+| **Deployment location** | Available in [11 global regions](#unleash-enterprise-edge-cloud) | Deploy within your own infrastructure, VPC, or on-premises, wherever you can run containers |
+| **Latency optimization**| Edge nodes are always up to date due to streaming; SDKs automatically connect SDKs to the nearest node | Deploy Edge instances geographically close to your applications within your network        |
+| **Client-side context processing** | Processed on Unleash-managed Edge infrastructure, but does not reach the central Unleash server or database | Processed entirely within your infrastructure. PII remains within your network boundary |
+| **Support** | Enterprise-grade support with SLAs and uptime guarantees  | No formal SLA |
+
+### Using Unleash without Edge
+
+Using Unleash Edge is optional. You can also access the Unleash API directly using the [Frontend or Client API](./unleash-overview#unleash-apis). This setup comes with the following considerations:
+- **Fair Use Policy:** Sending requests to the Unleash API is subject to limits outlined in the [Fair Use Policy](https://www.getunleash.io/fair-use-policy). While short traffic spikes are accommodated, sustained high traffic might require using Unleash Edge.
+- **Latency:** Although the Unleash architecture is designed for incredibly fast flag evaluations thanks to caching in the SDKs, the central Unleash API server might not be geographically close to all your end users, potentially increasing flag evaluation latency.
+- **Data privacy:** When using the Frontend API to talk to Unleash, any end-user data included in the [Unleash Context](../reference/unleash-context.md) is sent directly to the Unleash server. Evaluate if this meets your privacy requirements. Using Edge avoids sending this context data directly to the central Unleash API server.
+
+## Self-hosted Unleash Proxy
+
+:::note
+
+Unleash Proxy has been deprecated, use [Unleash Edge](../reference/unleash-edge) instead.
+:::
+
+
+If you are currently self-hosting Proxy, see our [Edge migration guide](https://github.com/Unleash/unleash-edge/blob/main/migration-guide.md) for a guide on how to migrate.

website/docs/understanding-unleash/proxy-hosting.mdx

@@ -1,180 +0,0 @@
----
-title: Edge and Proxy hosting strategies
----
-
-import VideoContent from '@site/src/components/VideoContent.jsx'
-
-This document describes the main ways of hosting [Unleash Edge](../generated/unleash-edge.md) (or alternatively [Unleash Proxy](../generated/unleash-proxy.md)) alongside the Unleash API and the tradeoffs between self-hosting compared to using the Frontend API that Unleash hosts for you.
-Whether you're hosting Unleash yourself or have a managed solution will be a key consideration.
-
-
-:::info Warning
-
-Edge is the next-gen replacement of the Unleash proxy and is recommended to be used over the proxy in most cases, with the exception of the scenario where custom strategies are being used as Edge does not support these.
-:::
-
-<VideoContent videoUrls={["https://www.youtube.com/embed/6uIdF-yByWs"]}/>
-
-## Unleash-hosted Frontend API vs self-hosted Edge/Proxy {#unleash-hosted-or-self-hosted}
-
-Which way is right for you will depend on your setup and your needs.
-
-In general, we recommend you use Edge over the [Frontend API](https://docs.getunleash.io/reference/front-end-api), but we do recognize that self-hosting requires some extra work on your part and that not all our customers need it.
-
-If you want Unleash to host the Frontend API for you, you should be aware of the following limitations:
-
--   This is only available to [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing) customers who have signed up for a managed Unleash instance.
--   We allow short spikes in traffic and our adaptive infrastructure will automatically scale to your needs.
--   Please check the [Fair Use Policy](https://www.getunleash.io/fair-use-policy) to see the limits of the Unleash-hosted Frontend API.
--   There's no guarantee that it'll be geographically close to your end users, this means your end users might be getting slower response times on feature flag evaluations.
--   When we host the frontend API, we will also receive whatever end-user data you put in the [Unleash context](../reference/unleash-context.md). This may or may not be an issue depending on your business requirements.
-
-Hosting Edge requires a little more setup than the Unleash-hosted Frontend API does, but it offers a number of benefits over both the frontend API and Proxy:
-
--   You can scale Edge instances horizontally and automatically.
--   There's no request cap or extra charges.
--   Edge can handle multiple sets of API tokens and sync these automatically. Compared to the legacy proxy, it is not necessary to set up single instances per token.
--   A key benefit of Edge is its ability to dynamically update new tokens while running. This greatly simplifies scaling up additional application workloads that leverage new tokens without the need to restart the instance or make large changes to infra, as was the prior requirement with the proxy.
--   You can arrange for Edge to be close to your applications, minimizing response times.
--   You have full control of all your user data. None of the data that Edge receives is ever sent to the Unleash API. This keeps _your_ data in _your_ hands.
--   You can easily add more Edge instances in different regions, as described in the [multi-region](#multi-region) section.
-
-
-
-## Unleash hosts everything
-
-:::note Availability
-
-**Plan**: [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing).
-
-:::
-
-
-Unleash no longer hosts instances of the proxy, but makes the [Frontend API](../reference/front-end-api) available to all [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing) customers. The API is backed by an Amazon RDS database. Your applications can connect to the frontend API from your own cloud or from other hosting solutions.
-
-In order to access the frontend API you'll need:
-- A [Frontend API key](../reference/api-tokens-and-client-keys#frontend-tokens) for the environment you'd like to use.
-- The Frontend API URL. This will be your Unleash instance's URL followed by `/api/frontend`.
-
-This is the simplest, but also most limited (by far) way to use Unleash client SDKs. In this setup, Unleash hosts both the Unleash API and the Unleash frontend API. With Unleash hosting, you'll only need to worry about the Frontend API keys and the URL to access the endpoint.
-
-While this is easy to get started with, it comes with the limitations described in the [section on tradeoffs between self-hosted and Unleash-hosted setups](#unleash-hosted-or-self-hosted).
-
-
-
-## Unleash hosts the API, you host Edge
-
-:::note Availability
-
-**Plan**: [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing).
-
-:::
-
-
-![An architecture diagram of using Edge in a setup where Unleash hosts the API and you host the proxy.](/img/proxy-hosting-unleash-api-customer-proxy-edge.svg)
-
-
-
-You host Edge yourself. It runs in a standalone container alongside your other applications in your cloud or hosting setup. Unleash manages the Unleash API, the admin UI, and the backing database in our AWS setup; the API and the UI run together in a Kubernetes deployment and connect to an Amazon RDS database.
-
-You'll need to configure Edge and the SDKs.
-
-### On Unleash
-
-- Create one or more [client API tokens](../reference/api-tokens-and-client-keys#client-tokens) scoped to the projects/environments you wish to use the Edge instance for.
-- Create frontend tokens for the frontend apps that will retrieve feature flags from Edge.
-
-### On Edge
-
-Edge will fetch feature flags from the specified upstream Unleash instance for every client API key it has been made aware of, either during startup (recommended) or separate endpoint requests. It will then periodically sync features with upstream.
-
-It will then accept frontend or backend tokens from application SDKs.
-
-:::info Warning
-
-Make sure to use the correct token type for your use case:
-
-- Frontend API: Use for frontend-facing apps; Edge returns application-specific context.
-- Client API: Use for backend SDKs; Edge returns the entire flag payload for the scope of the token (project/environment).
-
-:::
-
-#### Start Edge and populate flag cache
-
-This initial command will populate the flag cache on startup using the client token specified in the environment variable:
-
-```docker run -p 3063:3063 -e TOKENS='CLIENT_API_TOKEN' -e UPSTREAM_URL='UPSTREAM_URL' unleashorg/unleash-edge:v8.1 edge```
-
-The following can be used to pass new tokens to Edge for different project/environment scopes:
-
-```curl --location --request GET 'http://0.0.0.0:3063/api/client/features' \ --header 'Content-Type: application/json' \ --header 'Authorization: NEW_TOKEN' \ --data-raw ''```
-
-### On SDKs
-
-- Point frontend/client SDKs to Edge endpoints:
-    - **Backend SDKs**: `/api/client`.
-    - **Frontend SDKs**: `/api/frontend`, `/api/proxy`.
-
-
-## You host everything
-
-:::note Availability
-
-**Plan**: [Open Source](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing).
-
-:::
-
-
-![An architecture diagram of using the proxy in a single-region, self-hosted setup.](/img/proxy-hosting-customer-single-edge.svg)
-
-You host everything yourself. Everything runs where and how you configure it to.
-
-**To configure Edge and the SDKs, follow steps in the [previous section on Unleash hosts the API, you host Edge](#unleash-hosts-the-api-you-host-edge)**
-
-As you might expect, doing everything yourself gives you the most flexibility, but also requires the most effort. However, if you're already hosting Unleash yourself, this shouldn't be any more difficult than the previous section.
-
-As described in the [section on tradeoffs between self-hosted and Unleash-hosted setups](#unleash-hosted-or-self-hosted), running Edge yourself gives you a number of benefits.
-
-
-## Multi-region
-
-![An architecture diagram of using the proxy in a multi-region, self-hosted setup.](/img/proxy-hosting-customer-multi-edge.svg)
-
-You can also use Edge for a multi-region setup. You can run Edge in a different region to the API and still connect to the API. Because Edge runs closer to your applications it still provides you benefits in terms of quicker response times. Everything should be configured as described in the [you host everything section](#you-host-everything) or the [Unleash hosts the API, you host Edge section](#unleash-hosts-the-api-you-host-edge). You can add as many Edge instances in as many extra regions as you want.
-
-
-
-## Legacy: Unleash hosts the API, you host the Proxy
-
-:::info Recommendation
-
-This approach is no longer recommended. You should use [Unleash Edge](../reference/unleash-edge) instead of the Unleash proxy.
-If you are an existing Proxy user, see our [Edge migration guide](https://github.com/Unleash/unleash-edge/blob/main/migration-guide.md) for a guide on how to migrate.
-Please take note of the section covering features Edge does not currently support in the same linked document before planning a migration.
-:::
-
-:::note Availability
-
-**Plan**: [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing).
-
-:::
-
-
-![An architecture diagram of using the proxy in a setup where Unleash hosts the API and you host the proxy.](/img/proxy-hosting-unleash-api-customer-proxy.svg)
-
-You host the proxy yourself. It runs in a standalone container alongside your other applications in your cloud or hosting setup. Unleash manages the Unleash API, the admin UI, and the backing database in our AWS setup: the API and the UI run together in a Kubernetes deployment and connect to an Amazon RDS database.
-
-You'll need to configure the proxy and the proxy client SDKs.
-
-For the proxy, configure:
-
--   The Unleash API url. This is your Unleash instance URL followed by `/api`.
--   A [client API token](../reference/api-tokens-and-client-keys#client-tokens).
--   One or more [proxy client keys](../reference/api-tokens-and-client-keys#proxy-client-keys). Refer to the [configuration section of the proxy document](../reference/unleash-proxy#configuration-options) for more details.
-
-For the proxy client SDK, configure:
-
--   One of the proxy client keys that you configured for the proxy.
--   The proxy's endpoint. This will depend on where and how you're hosting the proxy, but will typically end in `/proxy`.
-
-This setup requires a little more setup on your part than the Unleash-hosted proxy does, but it offers all the benefits described in the [section on tradeoffs between self-hosted and Unleash-hosted setups](#unleash-hosted-or-self-hosted).

website/docs/understanding-unleash/unleash-overview.md

@@ -13,9 +13,9 @@ The Unleash system consists of several key components.
 
 ![A visual overview of an Unleash system as described in the following paragraph.](/img/unleash-architecture-edge.png)
 
-### The Unleash API
+### The Unleash API server
 
-The Unleash API (or Unleash server) is the core service for managing feature flags, configurations, and related concepts. It provides SDKs with all the data needed to work with feature flags and their [activation strategies](/reference/activation-strategies).
+The Unleash API server is the core service for managing feature flags, configurations, and related concepts. It provides SDKs with all the data needed to work with feature flags and their [activation strategies](/reference/activation-strategies).
 
 ### The Unleash Admin UI
 
@@ -56,7 +56,7 @@ The following table outlines where flag evaluation happens with different SDK se
 
 Flag evaluation relies on the [Unleash Context](/reference/unleash-context) and may involve user data. Since server-side SDKs always perform local evaluation, your user data remains within your application and is never shared with the Unleash server.
 
-For client-side SDKs, you can use Unleash Edge for flag evaluation to ensure that user data is not shared with the Unleash server. You have different hosting options for both [Unleash](/understanding-unleash/proxy-hosting#you-host-everything) and [Unleash Edge](/understanding-unleash/proxy-hosting#unleash-hosts-the-api-you-host-edge) allowing you to meet any privacy requirements.
+For client-side SDKs, you can use Unleash Edge for flag evaluation to ensure that user data is not shared with the Unleash server. You have different [hosting options](/understanding-unleash/hosting-options) for both Unleash and Unleash Edge allowing you to meet any privacy requirements.
 
 ### Unleash Edge
 
@@ -84,7 +84,7 @@ The [Admin API](/reference/api/unleash) is an API layer for managing all aspects
 
 ## Get started with Unleash
 
-To integrate Unleash, you first need an [Unleash server](#the-unleash-api). You can choose from:
+To integrate Unleash, you first need an [Unleash server](#the-unleash-api-server). You can choose from:
 - Unleash Enterprise:
   - [Cloud-hosted plans](https://www.getunleash.io/pricing)
   - [Self-hosted plans](https://www.getunleash.io/pricing)

website/docusaurus.config.ts

@@ -836,13 +836,6 @@ class="header-github-link"
                             ],
                             to: '/understanding-unleash/the-anatomy-of-unleash',
                         },
-                        {
-                            from: [
-                                '/tutorials/proxy-hosting',
-                                '/topics/proxy-hosting',
-                            ],
-                            to: '/understanding-unleash/proxy-hosting',
-                        },
                         {
                             from: [
                                 '/tutorials/data-collection',

website/sidebars.ts

@@ -340,7 +340,7 @@ const sidebars: SidebarsConfig = {
                 'understanding-unleash/unleash-overview',
                 'understanding-unleash/the-anatomy-of-unleash',
                 'understanding-unleash/managing-constraints',
-                'understanding-unleash/proxy-hosting',
+                'understanding-unleash/hosting-options',
                 'understanding-unleash/data-collection',
                 {
                     type: 'category',

website/vercel.json

@@ -703,12 +703,17 @@
     },
     {
       "source": "/tutorials/proxy-hosting",
-      "destination": "/understanding-unleash/proxy-hosting",
+      "destination": "/understanding-unleash/hosting-options",
       "permanent": true
     },
     {
       "source": "/topics/proxy-hosting",
-      "destination": "/understanding-unleash/proxy-hosting",
+      "destination": "/understanding-unleash/hosting-options",
+      "permanent": true
+    },
+    {
+      "source": "/understanding-unleash/proxy-hosting",
+      "destination": "/understanding-unleash/hosting-options",
       "permanent": true
     },
     {