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.
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.
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.
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.
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.
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 | Available in 11 global regions | Deploy within your own infrastructure, VPC, or on-premises, wherever you can run containers |
Latency | Configuration changes are pushed instantly to Enterprise Edge, ensuring it's always up to date; no polling required—changes propagate in real time | Relies 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 context | Processed on Unleash-managed Edge infrastructure, but does not reach the central Unleash server or database | Processed entirely within your infrastructure |
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. 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
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.