Skip to main content

Unleash hosting options

Unleash provides flexible hosting options for Unleash and Unleash Edge, 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.

Availability

The availability of hosting options may depend on your plan. See the Unleash Pricing page 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

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, 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 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.

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:
    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:
    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.

This option offers maximum flexibility and control over your feature management infrastructure but requires the most operational effort.

In addition to configuring Edge, you must also set up the Unleash server and its database following our self-hosting guide.

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.

FeatureUnleash Enterprise Edge CloudUnleash Edge: Open-Source
InfrastructureManaged entirely by UnleashManaged entirely by you
Operational effortMinimal setup and no ongoing maintenance required from youRequires setup, deployment, scaling, monitoring, and maintenance effort from you
Infrastructure costIncluded in Unleash Enterprise Edge feePay for the compute, network, storage, and operational overhead on your infrastructure
Setup and configurationPoint your SDKs to the provided Unleash Edge URLPull Docker image, configure upstream URL and API tokens via environment variables, deploy and manage the containers
ScalabilityHandled automatically by UnleashMonitor load and scale Edge instances manually or via automation
High availabilityManaged by Unleash with multi-AZ and multi-region redundancy and failoverRequires you to design and implement high availability (e.g., multiple instances, load balancers, potentially across AZs)
Security and updatesHandled automatically by UnleashYou manage host and container security, network rules, and apply Edge updates
ObservabilityMonitor health, replica count, memory usage, CPU, latency, and more directly from UnleashYou need to set up and manage your own monitoring and logging solutions for Edge
DeploymentAvailable in 11 global regionsDeploy within your own infrastructure, VPC, or on-premises, wherever you can run containers
LatencyConfiguration changes are pushed instantly to Enterprise Edge, ensuring it's always up to date; no polling required—changes propagate in real timeRelies on polling at a configured interval to check for updates; this introduces a delay between when changes are made and when they take effect
Client-side contextProcessed on Unleash-managed Edge infrastructure, but does not reach the central Unleash server or databaseProcessed entirely within your infrastructure
SupportEnterprise-grade support with SLAs and uptime guaranteesNo 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. 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. 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 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 instead.

If you are currently self-hosting Proxy, see our Edge migration guide for a guide on how to migrate.