Published October 9th, 2025
Picture this: you’re implementing feature flags with LaunchDarkly in a large enterprise environment. The Security team reviews the network traffic and raises a concern:
“Why are our applications making requests to launchdarkly.com?”
Our Enterprise needs all external requests to come from our own domain for compliance and monitoring.
Sound familiar? This is not a new request. Many organizations have network policies that require custom domains for external API calls.
Ad blocker
Split horizon DNS
We collaborate closely with our support team, so we know that this discussion arises frequently.
Now, the question becomes one of implementation.
There are many ways to solve the same problem. Many teams prefer a “keep it short and simple” (KISS) approach to avoid unnecessary complexity. Since we know our time is rarely spent on a single task, building something simple and functional that incurs low ownership and maintenace costs often wins in design reviews.
You can use the one-click deploy below or in the GitHub README: cloudfront-reverse-proxy. If you have an AWS account, you can use the one-click deploy. (A one-click cleanup also exists, and is described below.)
Deploy the CloudFront reverse proxy directly from the AWS Console with pre-configured settings. If you want to use a custom domain, set the parameter UseCustomDomain to true and ensure you use a domain that already exists in Route 53. Setting UseCustomDomain to false will give you an auto-generated CloudFront domain url.
NOTE: Only one sub-domain address was tested ex: flags.mydomain.com behavior may be different or not work if you’re trying to use multiple sub-domains such as my.flags.mydomain.com
Region-specific information is listed in the README.
Configuration Options
When you’re done testing your reverse proxy, you can spin down all your resources with one-click cleanup. Remove your CloudFront proxy deployment and clean up all associated resources including DNS records and certificates.
⚠️ Warning: This will permanently delete your CloudFront proxy and all associated resources. Make sure you’re ready before proceeding!
A reverse proxy is designed for the exact concern the security team has raised. It ensures that requests appear to come from your domain. The single responsibility a reverse proxy has it to route traffic through your domain to upstream services like LaunchDarkly.
Why rebuild what already exists, not to mention requiring the effort needed to maintain such a global system? That said, there are tradeoffs to consider.
You’re stepping away from LaunchDarkly’s optimized Flag Delivery Network (FDN). LaunchDarkly’s infrastructure is built for low-latency flag delivery with global edge locations optimized specifically for feature flag traffic patterns.
When you introduce a reverse proxy:
Latency may increase due to the additional network hop through your CloudFront distribution
Availability becomes your responsibility; you now own another piece of critical infrastructure in your flag delivery chain
You inherit CloudFront’s regional availability (SLA of 99.9) characteristics rather than LaunchDarkly’s FDN optimizations
Consider the ad blocker use case, where this could be only a small percentage of clients. You could limit the reverse proxy functionality to only the events endpoint.
If we don’t have data from our requirements, we should measure and quantify how many users are affected before introducing a reverse proxy. When we have our data. we could even perform experiments and progressive or guarded rollouts when implementing the reverse proxy configuration.
Using an AWS CloudFront proxy over 12 months, we should consider the following for total cost of ownership:
Setup Cost
Monthly Cost
Maintenance
For example, the first year may look something like:
We should always evaluate our approach against the full set of requirements. There are times when a simple solution like the reverse proxy is not the right choice.
A relay proxy is the better choice when we start to discuss things like:
Air gapped environments
Server side SDK optimization
Any manipulation of data, payload, etc.
Extreme data or security requirements
After deploying, configure your LaunchDarkly SDKs to use your CloudFront proxy by specifying the options with the reverse proxy URL.
Open DevTools from your browser and go to the Network tab. Find a LaunchDarkly network event and verify that the request URL matches the one from the reverse proxy deployed.
In this post you learned a simple yet effective approach to satisfying your organization’s network policies requirements for custom domains.
Get started with Reverse Proxy in this GitHub repo, or sign up for a free LaunchDarkly account here.