The LaunchDarkly relay proxy is a microservice that establishes a connection to the LaunchDarkly streaming API, then proxies that stream connection to multiple clients.
The relay proxy lets a number of servers connect to a local stream instead of making a large number of outbound connections to
The relay proxy can be configured to proxy multiple environment streams, even across multiple projects.
In most cases, the relay proxy is unnecessary. However, there are some specific scenarios where we recommend deploying the proxy to improve performance and reliability:
PHP-- PHP has a shared-nothing architecture that prevents the normal LaunchDarkly streaming API connection from being re-used across requests. While we do have a supported deployment mode for PHP that does not require the relay proxy, we strongly recommend using the proxy in daemon mode (see below) if you are using PHP in a high-throughput setting. This will offload the task of receiving feature flag updates to the relay proxy.
Reducing outbound connections to LaunchDarkly-- at scale (thousands or tens of thousands of servers), the number of outbound persistent connections to LaunchDarkly's streaming API can be problematic for some proxies and firewalls. With the relay proxy in place in proxy mode, your servers can connect directly to hosts within your own datacenter instead of connecting directly to LaunchDarkly's streaming API. On an appropriately spec'd machine, each relay proxy can handle tens of thousands of concurrent connections, so the number of outbound connections to the LaunchDarkly streaming API can be reduced dramatically.
Reducing redundant update traffic to Redis-- if you are using Redis as a shared persistence option for feature flags, and have a large number of servers (thousands or tens of thousands) connected to LaunchDarkly, each server will attempt to update Redis when a flag update happens. This pattern is safe but inefficient. By deploying the relay proxy in daemon mode, and setting your LaunchDarkly SDKs to daemon mode, you can delegate flag updates to a small number of relay proxy instances and reduce the number of redundant update calls to Redis.
The relay proxy can run in two different modes-- proxy mode, and daemon mode.
The LaunchDarkly relay (LDR) is typically deployed in relay proxy mode. In this mode, several LDR instances are deployed in a high-availability configuration behind a load balancer. LDR nodes do not need to communicate with each other, and there is no master or cluster. This makes it easy to scale LDR horizontally by deploying more nodes behind the load balancer.
Relay proxy mode
Optionally, you can configure our SDKs to communicate directly to the Redis store. If you go this route, there is no need to put a load balancer in front of LDR-- we call this daemon mode. This is the preferred way to use LaunchDarkly with PHP (as there's no way to maintain persistent stream connections in PHP).
The relay proxy may also be configured to proxy flag evaluation for mobile, client-side, and unofficial SDKs. Instructions for configuring feature flag evaluation endpoints can be found in our GitHub repository.
Go's standard HTTP library provides a built-in HTTPS proxy. If the HTTPS_PROXY environment variable is present then the SDK will proxy all network requests through the URL provided.
How to set the HTTPS_PROXY environment variable on Mac/Linux systems:
How to set the HTTPS_PROXY environment variable on Windows systems:
We have done extensive load tests on the relay proxy in AWS / EC2. We have also collected a substantial amount of data based on real-world customer use. We've documented our recommendations for deploying and operating the relay proxy at scale in our GitHub repository.
The relay may be configured to export statistics, requests received, and route traces to Datadog, Stackdriver, and Prometheus via the OpenCensus protocol. (This information pertains to the relay, and not to the core LaunchDarkly service itself.) Instructions for configuring the relay to export metrics and traces can be found in our GitHub repository.