For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Sign inTry it free
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
  • Flagship blog
    • 52 Blog Posts, Claude, 3 Prompts, Under an Hour
    • Shipping from Oakland: An Observability Hackathon Recap
    • Day 12 | New Year, New Observability
    • Day 11 | What engineering teams really want from Observability
    • Day 10 | Why observability and feature flags go together like milk and cookies
    • Day 9 | The Three Ghosts Haunting Your AI This Holiday Season
    • Day 8 | Observable Multi-Modal Agentic Systems
    • Day 7 | SLOs that actually drive decisions
    • Day 6 | Stop cardinality from stealing your cloud budget
    • Day 5 | Using a Popular Tidying Method to Consolidate Your Observability Stack
    • Day 4 | Tracing the impact of feature flags in your Node.js app
    • Day 3 | Zero-Config Observability with OpenTelemetry
    • Day 2 | Why AI agents need three layers of observability
    • Day 1 | Observability Under the Tree: What Changed in 2025
    • 5 takeaways from my first PyCon JP conference
    • Dungeons & Downtimes: XP gained from our adventure
    • Reverse Proxy for custom domains
    • Adventures in dogfooding: Guarded Releases
    • A quick tool for npm package scanning
    • My DEF CON 33 experience
    • Make every launch a big deal
    • Fun with JS streams
    • Moonshots XXII: Hack to the Future recap
    • A tale of three rate limiters
    • My good friend Claude
    • My approach to React app architecture in 2025
    • Data isolation with ClickHouse row policies
    • Ingest and Visualization for OpenTelemetry Metrics
    • Alert Evaluations: Incremental Merges in ClickHouse
    • Optimizing ClickHouse: The Tactics That Worked for Us
    • Migrating from OpenSearch to ClickHouse
    • Revamping Privacy Mode: A Better Way to Obfuscate Sensitive Data
    • An open-source session replay benchmark
    • LLM-based Grouping of Errors
    • Building GitHub Enhanced Stacktraces
    • Vercel Edge Runtime Support
    • Finding Interesting Sessions with Markov Chains
    • Building Logging Integrations at LaunchDarkly
    • The Network Request Details Panel
    • Using Github as a Headless CMS
    • Your Source Maps Should Be Public
    • Supporting Outside Contributions at LaunchDarkly
    • Managing our design tokens at LaunchDarkly
    • Our Commitment to OpenTelemetry
    • The 5 Best Logging Libraries for Ruby
    • InfluxDB: Visualizing Millions of Customers' Metrics using a Time Series Database
    • 8 Tips to Help You Maximize Chrome DevTools
    • The Debugging Process and Techniques for Web Applications (Part 2/2)
    • 5 Best Node.js Logging Libraries
    • What are rage clicks and how to detect them
    • 5 Best Practices for Maintaining a Clean ReactJS App
    • Is Kafka the Key? The Evolution of LaunchDarkly's Ingest
    • What Is Full Stack Monitoring and How Does It Work?
    • The beauty of contact-first API design
    • What is Frontend Monitoring and What Tools Help You Do It?
    • 5 strategies to monitor the health of your web application
    • Configuring OpenSearch for a Write-Heavy Workload
    • Maximizing Our Machines: Worker Pools At LaunchDarkly
Sign inTry it free
LogoLogo
On this page
  • The problem: corporate networks demand their custom domain(s)
  • Also consider the following use cases:
  • We’ve seen this before
  • What’s a simple way to satisfy the requirement?
  • How simple is it?
  • One-Click Cleanup
  • Why Reverse Proxy wins: The case for simplicity
  • Performance and reliability considerations
  • Consider a targeted approach
  • Cost Estimates
  • When NOT to use a Reverse Proxy
  • Implementing the Reverse Proxy in code
  • React SDK (React applications)
  • Verify that the application is using the Reverse Proxy
  • Get started with Reverse Proxy
Flagship blog

Use Reverse Proxy for custom domain requests

Was this page helpful?
Previous

Adventures in dogfooding: Guarded Releases

Next
Built with

Published October 9th, 2025

Portrait of Dina Muscanell.

by Dina Muscanell, LaunchDarkly Staff Solutions Architect

The problem: corporate networks demand their custom domain(s)

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.

Also consider the following use cases:

  • Ad blocker

    • For organizations that have a very technical user base (although, generally, this seems to be a declining discussion).
  • Split horizon DNS

    • Cruise ships, need the domain to resolve to a public endpoint off-ship and require a LaunchDarkly relay instance on-ship.
    • You would need to make sure you have valid certs on both sides of the split for the same domain.

We’ve seen this before

We collaborate closely with our support team, so we know that this discussion arises frequently.

Now, the question becomes one of implementation.

What’s a simple way to satisfy the requirement?

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.

How simple is it?

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

ParameterDefaultOptionsDescription
UseCustomDomain

false

true/falseUse your own domain instead of CloudFront default
DomainName

""

Your domainRequired if UseCustomDomain=true (e.g., flags.my-company.com) - will auto-create certificate and DNS records
PriceClass

PriceClass_100

PriceClass_100/200/AllCoverage: US/Canada/Europe/Asia (100) vs Global (All)
cLoggingBucket

""

S3 bucket nameRequired if EnableLogging=true

One-Click Cleanup

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!

Why Reverse Proxy wins: The case for simplicity

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.

Performance and reliability considerations

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 a targeted approach

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.

Cost Estimates

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:

TaskCost
Initial Setup~ 2 hours of engineer time
Monthly$20–100 (based on request volume)
Estimated Maintenance~ 1 hour per quarter
Estimated cost: $1,500 (year 1)

When NOT to use a Reverse Proxy

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

Implementing the Reverse Proxy in code

After deploying, configure your LaunchDarkly SDKs to use your CloudFront proxy by specifying the options with the reverse proxy URL.

React SDK (React applications)

1const LDProvider = await asyncWithLDProvider({
2 clientSideID: 'your-client-side-id',
3 context: {
4 kind: "device",
5 key: "unique-device-id"
6 },
7 options: {
8 baseUrl: 'https://flags.my-company-domain.com',
9 eventsUrl: 'https://flags.my-company-domain.com',
10 streamUrl: 'https://flags.my-company-domain.com'
11 }
12});

Verify that the application is using the Reverse Proxy

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.

Get started with Reverse Proxy

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.