Relay Proxy use cases

Overview

This topic explains common Relay Proxy use cases and how to decide whether to use the Relay Proxy with your configuration.

When to use the Relay Proxy

The LaunchDarkly client-side and server-side SDKs you use impact whether you should use the Relay Proxy. The Relay Proxy works best with the default SDK configurations for all server-side SDKs and for the client-side JavaScript SDK.

The Relay Proxy does not scale well when it has to maintain streaming connections with a large number of client-side SDKs, including mobile SDKs. If you're utilizing LaunchDarkly's streaming architecture in a heavily-used client-side or mobile application, connecting directly to LaunchDarkly's main service may give you the best performance. You could also bootstrap flag rules from the server-side, without using the client-side SDK, in this situation.

If you choose to use the Relay Proxy, you must configure your SDKs to connect to it.

Common use cases for the Relay Proxy

The Relay Proxy was developed to address specific scenarios, and it works best when you use it for those purposes. The sections below describe common use cases.

Reducing outbound connections to LaunchDarkly

A large number of servers, such as thousands or tens of thousands, can present too many outbound persistent connections to LaunchDarkly's streaming API for a proxy or firewall to realistically handle. Use the Relay Proxy in proxy mode so your servers can connect directly to hosts in your own data center, instead of connecting directly to LaunchDarkly's streaming API. On an appropriately configured host, each Relay Proxy can handle tens of thousands of concurrent connections. This dramatically reduces the number of outbound connections to the LaunchDarkly streaming API. To learn more, read Configuring SDKs to use different modes.

Using PHP

The PHP SDK communicates differently with LaunchDarkly than other LaunchDarkly SDKs because it does not support long-lived streaming connections. It must either use HTTP to poll for flags on demand, or get them from a feature store while using the Relay Proxy. We recommend using the Relay Proxy and a feature store, as it is more efficient than polling for flags on demand.

To learn more, read the Relay Proxy GitHub repository's Using PHP.

Reducing initialization latency in short-lived and serverless environments

If you're using short-lived or serverless environments and your app is very sensitive to start up run times, you can use LaunchDarkly with the Relay Proxy hosted on a long-lived server to reduce initialization latency.

Using the Relay Proxy in the same region or availability zone as your provider's server can reduce initialization times, depending on your location. If you are billed by the millisecond, this can help lower costs.

Using larger list-based segments or segments synced from external tools

If you want to use larger list-based segments or segments synced from external tools with server-side SDKs, these segments require a persistent store within your infrastructure. LaunchDarkly keeps the persistent store up-to-date, and the LaunchDarkly SDKs consult it during flag evaluation. You can use the Relay Proxy for this. You can also use a persistent store integration.

If you are already using the Relay Proxy, we recommend also using it for list-based segments and synced segments. However, we do not recommend using the Relay Proxy if supporting segments is your only use case.

To learn more, read SDK and integration configuration for segments.

Reducing redundant database traffic

If you use a persistent data store and you have a large number of servers connected to LaunchDarkly, each server attempts to update the data store when a flag update occurs. This behavior is safe, but inefficient. Instead, you can use the Relay Proxy in daemon mode by setting your LaunchDarkly SDKs to daemon mode. You can then delegate flag updates to a small number of Relay Proxy instances and reduce the number of redundant update calls to your data store. To learn more, read Persistent data stores.

Air-gapped environments

You may be required to operate in environments without internet connectivity. In this situation, running the Relay Proxy in offline mode provides the capabilities of LaunchDarkly without using our SaaS services. To learn more, read Offline mode.

When not to use the Relay Proxy

Some customers may find operating the Relay Proxy cost-prohibitive for their use case, especially customers on Developer or Foundation plans. Adding the Relay Proxy to your LaunchDarkly configuration also introduces architectural complexity that may not be necessary for smaller deployments.

Here are some situations the Relay Proxy is not appropriate for:

• Improving architectural availability or resiliency beyond LaunchDarkly’s SaaS infrastructure
• Increasing SDK security beyond built-in privacy features
• Using many client-side SDK connections
• Adding redundancy

Costs of using the Relay Proxy

There are several considerations that go into determining the total cost of ownership for managing the Relay Proxy at scale. The time cost for onboarding and operating the Relay Proxy varies greatly between organizations, depending on your processes for introducing new technology.

The Relay Proxy has certain features that are available to customers on Enterprise and Guardian plans, including automatic configuration and offline mode. Access to these features may make using the Relay Proxy more beneficial than it would be with only its out-of-the-box feature set. To learn more, read Relay Proxy Enterprise.

Ongoing costs

For the ongoing machine cost, following our scaling guidelines, most customers find that they have plenty of capacity using three machines, with a load balancer in front of them. For customers who decide to use a database, there will be an ongoing machine cost for that as well. To learn more, read Caching guidelines.

There will also likely be a cost when you turn monitoring on, which will depend on your monitoring solution. You may want to consider the cost of adding this information to your runbooks as well. To learn more, read Monitoring the Relay Proxy.

For the ongoing personnel cost, as a general guideline we recommend that customers estimate an hour or so per week of a DevOps engineer's time to monitor and maintain the cluster. We also recommend that your on-call rotation is familiar with this technology and that you set up your monitoring to make sure that you can capture abnormalities when they occur.

If you're on LaunchDarkly's Developer or Foundation plan, you can use the Relay Proxy but the operating costs associated with onboarding and maintaining it may be prohibitive. In general, customers on Enterprise and Guardian plans may be more tolerant of the infrastructural costs associated with using the Relay Proxy's Enterprise features than customers with more limited budgets. To learn more, read Relay Proxy guidelines.

Environments requiring FIPS 140-2 validated encryption

If you are using the LaunchDarkly Relay Proxy in an environment that requires the use of FIPS 140-2 validated encryption modules, such as the LaunchDarkly federal instance, you may need to take additional steps to ensure compliance. To learn more, read LaunchDarkly in environments requiring FIPS 140-2 validated encryption modules.