Which open-source option replaces the LaunchDarkly Relay Proxy
If you run the LaunchDarkly Relay Proxy to keep SDK traffic inside your network, the main self-hosted replacements are Unleash Edge and the Flagsmith Edge Proxy. Be aware that the open-source version of Unleash Edge reaches end of life on December 31, 2026, so any design that depends on it for scale needs a decision before that date. Offline mode, which lets the Relay Proxy serve flags from a file archive, is an Enterprise feature in LaunchDarkly, so you should not assume that capability carries over to a self-hosted design without checking what your chosen server edition provides.
Start by listing what the Relay Proxy does for you today: which environments it serves, how many SDK connections it holds, whether it runs as a daemon or in a container, and whether your applications need it to keep serving flags during an outage of the upstream service. Then map each of those needs to a component. Unleash Edge is a caching layer between SDKs and the Unleash API, so it fits teams that already run Unleash and want its caching behavior. The Flagsmith Edge Proxy is an optional component of the Flagsmith self-hosting design, which the Flagsmith self-hosting documentation describes as a way to lower latency. Confirm with each vendor which features and support levels apply to the edition you plan to run.
The decision usually comes down to the edition you can support long term. Unleash Edge on the open-source track has a defined end of life, and Unleash recommends that OSS Edge users move to an Enterprise plan, so price that path into the design. Flagsmith's Edge Proxy sits inside a project whose core code is BSD 3-Clause, with Enterprise features such as SAML and role-based access control under a license. Ask each vendor in writing whether an offline or file-based mode is available for your edition, how the flag archive is refreshed, and who is responsible for patching the proxy. A short proof of concept with your real SDK count will show more than any comparison table.
How Relay Proxy capabilities map to open-source edge components
This table maps the main Relay Proxy capabilities to the open-source components that can take over its role inside your network: Unleash Edge and Flagsmith's Edge Proxy. Read each row as a question to confirm against the documentation for the exact version you deploy, since edge features change between releases. The main takeaway is that the open-source version of Unleash Edge reaches end of life on December 31, 2026, which should shape the choice as much as any single feature.
| Capability | Unleash Edge | Flagsmith Edge Proxy |
|---|---|---|
| Caching of flag evaluations | Caching layer between SDKs and the Unleash API; confirm cache refresh behavior for your version | Optional component documented for lower latency; confirm what is cached and for how long |
| SDK connection to a local endpoint | SDKs point at the Edge host instead of the central server; confirm the SDK URL setting | Optional proxy placed in front of the API; confirm the SDK base URL and any environment key handling |
| Flag streaming | Not confirmed in the supplied documentation; confirm streaming support in your release | Not confirmed in the supplied documentation; confirm streaming support in your release |
| Offline mode from a file archive | Not documented as a file-based offline mode; LaunchDarkly offline mode is an Enterprise feature | Not documented as a file-based offline mode; confirm before designing around it |
| Container and Helm deployment | Runs as a container next to the Unleash server; confirm the chart or manifest you will use | Edge Proxy is an optional part of self-hosting; confirm the deployment method in the Helm chart docs |
| Upstream license | Confirm the license of the Edge component; the Unleash server moved to AGPLv3 with v8.0.0 | Core code is BSD 3-Clause; confirm the license of the Edge Proxy component itself |
| Support lifecycle | Open-source version reaches end of life on December 31, 2026; OSS users are advised to move to an Enterprise plan | Confirm the supported release line and upgrade path with Flagsmith before selecting this component |
Unleash Edge or Flagsmith Edge Proxy: which fits which network
Both projects offer a component that sits between your SDKs and the central flag server to cut latency and load. The right choice depends on your license posture, whether you need Enterprise governance, and how the edge tier fits inside your network boundary.
Unleash Edge open-source end of life
Unleash Edge is the caching layer that replaces LaunchDarkly's Relay Proxy in an Unleash design. The open-source version entered long-term support on December 12, 2025 and reaches end of life on December 31, 2026. Unleash recommends that OSS Edge users move to an Enterprise plan. If you plan to run Edge for scale, check the support date before you commit the design, and confirm Enterprise pricing for your deployment with Unleash.
AGPLv3 change for modified servers
Starting with Unleash v8.0.0, the server source code moved from Apache 2.0 to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Unleash states that running the unmodified images is not affected. If your platform team patches the server, or offers Unleash to outside users as a service, you must publish the modified source or buy a commercial license. Have counsel confirm how this applies to any edge build you maintain.
Unleash Edge for scaled SDK traffic
Edge suits designs where many SDKs poll one Unleash server and the central API becomes the bottleneck. Place Edge in the network segment closest to your services so that SDKs fetch cached flags locally. Before you deploy, confirm with Unleash which Edge version and plan your environment needs, and plan a path off OSS Edge before its end of life date, since the open-source build will stop receiving support.
Flagsmith Edge Proxy as an option
Flagsmith's self-hosting documentation lists optional Edge Proxies for lower latency, so the component is not required for a basic deployment. Its core code is mostly BSD 3-Clause licensed, which keeps internal modification and redistribution straightforward. Confirm with Flagsmith whether the Edge Proxy you deploy is covered by the open-source license or by an Enterprise agreement before you rely on it in production.
Flagsmith Enterprise-only governance
The open-source Flagsmith build has no API request limits, but SAML single sign-on and role-based access control are Enterprise features and closed source. If your edge tier sits in a segment where auditors expect SSO and fine-grained roles on who changes flags, budget for an Enterprise license. Ask Flagsmith to confirm which governance features ship with the plan you choose.
Choosing by network and license
Choose Unleash Edge when you need caching at scale and can fund an Enterprise plan before the OSS end of life. Choose the Flagsmith Edge Proxy when you want an optional, BSD-licensed component and can keep SSO and RBAC out of scope or licensed separately. In either case, test cache freshness and failover from inside the isolated segment, and document who operates the edge tier as part of your change process.
What offline mode looks like on a self-hosted flag server
When the application servers can reach the flag server inside your network, you may not need an offline archive at all. A local edge sits between the SDKs and the central flag API, caches evaluations and keeps answering while the upstream link is slow or briefly unavailable. LaunchDarkly's equivalent is the Relay Proxy, and its offline mode is a separate Enterprise capability for cases where no connection to the service exists.
- Unleash Edge: a caching layer between SDKs and the Unleash API. The open-source version of Edge reaches end of life on December 31, 2026, so plan the edge tier on a supported basis and confirm current terms with Unleash.
- Flagsmith Edge Proxies: optional components listed in the self-hosting documentation for lower latency. Confirm how they sync with the core API and what they serve during an upstream outage.
- Upstream reachability: measure how often the edge loses contact with the central server in your environment, because that frequency determines whether cached state is enough.
- Stale state: confirm how long a cached flag value stays in use after the upstream link drops and whether the edge marks its data as stale.
Check these behaviors in a test environment before deciding whether a file-based fallback is needed.
In an air-gapped or isolated enclave, nothing leaves the network, so the flag server, its database and every SDK endpoint must run inside the boundary. The self-hosted server becomes the source of truth for flag state, which removes the dependency on a vendor's cloud. Flag definitions still have to enter the enclave through a controlled path, and that path takes the place of the offline archive that LaunchDarkly's Enterprise offline mode uses.
- Server and database inside the boundary: Unleash runs from the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI listening on port 4242. Pull images from an internal registry so the enclave never reaches a public one.
- Database placement: the Flagsmith Helm chart creates its own PostgreSQL server by default, while the documentation recommends an externally managed database for production. Decide where the database lives before the build starts.
- Definitions by controlled transfer: Unleash import and export moves flag configuration as JSON. Segments and custom strategies are exported only as references, so create them in the target before importing flags.
- Outbound calls: confirm with each vendor that the server, its telemetry settings and any Enterprise license check work without outbound connections, and record the answer for your assessors.
Run the full enclave build with a copy of the definitions before any production transfer.
Whatever the topology, the refresh cycle is the operational work that offline mode makes explicit. Your team decides how definitions move from the source system to the self-hosted server, how often that happens and how a bad update is reversed. Refresh behavior differs between products and between SDKs, so confirm each point in the vendor documentation and in a test environment before you depend on it.
- Export and transfer: export definitions from the source instance, record the export time and the source version, and move the file through your approved transfer route.
- Import order: import segments and custom strategies before flags so that references resolve on the target.
- Verification: compare flag counts and environment names on both sides, then evaluate a set of test contexts through a canary SDK and compare the results.
- Rollback: keep the previous export and confirm whether an import overwrites matching configuration and how you revert it.
- SDK caching: confirm the polling or streaming interval each SDK uses and what it serves when the server stops answering.
Write these answers into the runbook, because the refresh record is the evidence an auditor will ask for when reviewing how flag state changed.
How to run the edge alongside LaunchDarkly during cutover
Run LaunchDarkly and the self-hosted edge in parallel behind one abstraction layer, and move traffic in steps, because Unleash's own migration guide recommends exactly this approach before cutover. The abstraction layer is the piece to build first. In practice it is either an OpenFeature provider or a thin internal wrapper that exposes one flag evaluation function, so that the application decides which backend answers. Without that seam, every service has to change at the same moment, and a rollback means a redeploy. Plan the layer so that a single configuration value can route a service to LaunchDarkly, to the new edge, or to both for comparison. Confirm with your platform team which SDK languages in your estate can reach the new layer without a rewrite, and confirm how your chosen edge and SDK handle streaming updates, since that affects how quickly a flag change reaches each service.
Start with a small subset of low-risk services pointed at the new edge, and leave the rest on the Relay Proxy until the first group is stable. Before widening the subset, check evaluation parity: for a sample of flag keys and a representative set of contexts, compare the value returned by LaunchDarkly with the value returned by the new edge, and log every mismatch. Typical causes are differences in how targeting rules, prerequisites or default values are translated, and the Unleash migration mapping is the reference to check against. Keep the comparison read-only on production traffic where you can, so that a mismatch never changes what a user sees.
The most sensitive part of the cutover is user bucketing. A partial percentage rollout assigns each user to a variant by hashing a key, and if the hashing input, the seed or the context fields differ between the two systems, users can move between variants during the switch. That changes their experience mid-rollout and corrupts any experiment that is running. Before routing any traffic, confirm with the vendor documentation and a test run that the new system assigns the same users to the same buckets for your rollout keys, and freeze percentage changes during the transition window. Record the decision in writing, because auditors and product owners will ask how user experience was protected during the change.
Moving SDK traffic from the Relay Proxy to a self-hosted edge
This sequence moves SDK traffic off the LaunchDarkly Relay Proxy and onto a self-hosted flag server and edge layer in your own network, with each step closed by a check that the previous one is complete. The order matters because segments must exist before flags reference them, and a parallel run protects production while the cutover happens.
Inventory applications and SDK versions
Platform engineering lists every service that points at the Relay Proxy, the LaunchDarkly SDK language and version each one uses, the environments it reads from, and the owner who can approve a change. Include batch jobs, edge services and internal tools, since these often pull flags through the proxy without appearing in the main service catalog. Confirm which SDKs have a matching server SDK for your target platform, and check the OpenFeature provider list if you plan to decouple application code first. The inventory is done when every consumer of the proxy has a named owner and a recorded SDK version.
Stand up the server and PostgreSQL
The infrastructure team deploys the self-hosted flag server, such as Unleash from the official Docker image or Flagsmith through its Docker Compose or Helm options, against a PostgreSQL database that the team manages. Flagsmith's Helm chart creates its own database by default, so decide early whether you will use an externally managed instance as its documentation recommends for production. Confirm the PostgreSQL version against the target's current requirements, configure backups, and confirm the admin UI and API respond inside your network. The step is complete when the server is healthy and an administrator can log in.
Export flag and segment definitions
An engineer exports flag and segment definitions from LaunchDarkly as JSON through the LaunchDarkly REST API, using an access token with the minimum read scope needed. Export every project and environment in scope, and save the files in version control with a date and source label so changes can be traced. Record which flags are archived, which are multivariate and which rely on prerequisites, because each maps to a different target construct. The step is complete when the exported files cover every project and environment listed in the inventory and a second person has checked the counts.
Recreate segments before flags
Segments and custom context fields must exist in the target before any flag that references them is imported. In Unleash, the environment import and export feature exports segments as references only, so segments need to be created first through the Admin UI or the Admin API. In Flagsmith, the built-in LaunchDarkly importer copies projects, environments and flags, so confirm how segment-based targeting carries over and recreate anything it does not reproduce. Compare segment membership counts against LaunchDarkly for a sample of contexts. The step is complete when every referenced segment exists in the target and the sample matches.
Import flags into a fresh target project
The team imports flags into the target, using the Unleash import feature or the Flagsmith importer, and uses a fresh project for each import. Flagsmith's importer overwrites existing environments and flags in the target project, so an import into a project that already holds working configuration can change live behavior. Review each imported flag by hand, since targeting rules, multivariate values and archived states should be checked after any automated import. The step is complete when a reviewer has signed off on the imported flags in every environment and no existing production configuration was overwritten.
Deploy the edge and run in parallel
Platform engineering deploys the edge layer in your network, which is Unleash Edge for Unleash or the Flagsmith Edge Proxy for Flagsmith, and points it at the new flag server. If you use Unleash Edge, note that the open-source version reaches end of life on December 31, 2026, so confirm the supported edition before building production on it. Run both systems side by side behind an abstraction layer, with the new edge receiving traffic in a test environment first. The step is complete when the edge serves flag evaluations in staging and the outputs match those from the Relay Proxy for the same contexts.
Switch a canary set of services
Move a small, low-risk group of services from the Relay Proxy to the new edge by changing their SDK endpoint or provider configuration, and watch error rates, latency and flag evaluation results for each one. Choose services whose owners can roll back quickly and avoid partial rollouts where a change could re-bucket users, since bucketing differences can change the experience of existing users. Keep the Relay Proxy running for all other services. The step is complete when the canary services have run through a full business cycle with no unexplained evaluation differences and the owners have signed off.
Migrate remaining services and decommission the proxy
Move the rest of the inventoried services in batches, updating each one and confirming its owner's sign-off as it moves. Once no traffic reaches the Relay Proxy, confirm that with access logs or network monitoring, then shut the proxy down and remove its configuration, credentials and DNS entries. Keep the exported LaunchDarkly definitions and the import records for your audit trail, and revoke the LaunchDarkly access token used for the export. The step is complete when the proxy receives no requests, its credentials are revoked and the migration record is filed.
Questions buyers ask before replacing the Relay Proxy
Does Unleash Edge OSS support end on December 31, 2026, and what should we do?
Yes. The open-source version of Unleash Edge entered long-term support on December 12, 2025 and reaches end of life on December 31, 2026, according to the Unleash Edge documentation. Unleash recommends that OSS Edge users move to an Enterprise plan. If your design relies on Edge for scale, decide before that date whether you will pay for Enterprise, switch to a different caching layer, or redesign the SDK path. Confirm the current support terms and Enterprise pricing directly with Unleash, since those details can change.
Is offline mode available without a LaunchDarkly Enterprise license?
Offline mode is an Enterprise feature in LaunchDarkly, so confirm your current entitlement in your contract. On a self-hosted flag server, the equivalent need is different: the flag server sits inside your network and keeps serving evaluations while the dashboard and API stay internal, so there is no vendor-side archive to refresh. Whether you need Enterprise tiers on Unleash or Flagsmith depends on governance needs such as SSO, roles or audit logs, not on offline serving. Ask each vendor which features are gated in the edition you plan to run.
How much effort does a Relay Proxy migration take, and what drives it?
Effort depends mainly on how many SDK integrations point at the Relay Proxy, how many environments and projects you run, and whether you need Edge-level caching at your traffic volume. The cost components are the internal engineering time to repoint SDKs and test evaluations, the platform work to host the flag server and cache, and the parallel-run period while both systems serve traffic. Unleash's migration guide recommends running both systems in parallel behind an abstraction layer before cutting over. Ask for the effort split by component in any written scope.
What must our team provide before the work starts?
Plan for four groups of inputs. First, a Kubernetes or other container platform, or a Docker host for smaller deployments, where the server and cache run. Second, a PostgreSQL database; Unleash's getting started guide targets PostgreSQL 15 or later. Third, network owners who approve routes from application hosts to the flag server and cache on port 4242 or the ports you choose. Fourth, a named owner for SDK keys, environments and access tokens. Flagsmith's Helm chart creates its own database by default, but its documentation recommends an externally managed one for production.
Can our in-house team do this without an outside partner?
Often yes, if you already run containers, PostgreSQL and internal certificate processes, and you have engineers who can own SDK changes across applications. The harder parts are usually network approval, caching behavior at peak load, and testing that flag evaluations match LaunchDarkly during parallel running. Teams that lack these skills, or that must show evidence for an assessment, often benefit from a fixed-scope engagement. DeployOpen implements, hardens, backs up and documents self-hosted platforms inside your own infrastructure, but the decision on who runs the platform after handover is yours.
What should we ask for in a written scope?
Ask for the scope in writing before work starts, and make sure it names the following: the Unleash, Flagsmith or other flag server edition and version, the caching design and whether Edge or an equivalent is included, the SDK applications in scope, the environments and projects to migrate, the parallel-run period and cutover criteria, the network and certificate changes, backup and upgrade responsibilities, and the documentation delivered. Also ask which items are excluded, such as application code changes or licensing purchases. Confirm current pricing and feature availability with each vendor before you sign.
Which option should we choose, Unleash Edge or Flagsmith's Edge Proxy?
Choose on what your architecture needs, not on the label. Unleash Edge is a caching layer between SDKs and the Unleash API, and its open-source version is on the end-of-life path described above. Flagsmith documents optional Edge Proxies for lower latency in its self-hosting guide. Ask each vendor how its proxy handles your SDK types, failover and upgrades, and which edition includes it. Check the license of each component, since Unleash moved its server to AGPLv3 with v8.0.0 and Flagsmith keeps Enterprise features closed source.
What the cost of self-hosting an edge layer includes
The cost of self-hosting an edge layer is not one line item. It splits into infrastructure to run edge instances close to your workloads, a database and its backups, a license only if you need supported Edge or single sign-on, staff time for upgrades and monitoring, and a one-time migration effort. The first two are paid to your cloud or data center provider and your own team. The license is paid to the vendor, and it is the component most often overlooked. Before you build a cost model, confirm with Unleash whether the open-source Edge version that reaches end of life on December 31, 2026 is still viable for your scale, and what the Enterprise plan includes for supported Edge. Ask the same question of Flagsmith for its Edge Proxy, including whether it is covered by the open-source license or an Enterprise agreement.
Most costs recur. Edge instances need compute in each network segment or region where SDK traffic originates, and they need to stay patched. Upgrades recur as well: each Unleash or Flagsmith release, and each Edge release, needs testing against your SDK versions. Monitoring, certificate rotation and on-call coverage for the edge tier add staff hours every month. The one-time work includes mapping LaunchDarkly Relay Proxy configuration to Edge settings, validating that each application points at the right endpoint, and running both systems in parallel during cutover. The main cost drivers are the number of edge locations, traffic volume, how many environments and SDK keys you run, and whether you want high availability in each location.
When you request a quote, ask for each component as a separate line: the edge compute per location, database hosting and backup retention, license tier and what it covers, support hours and response commitments, upgrade and monitoring responsibilities, and the migration phases with their deliverables. Ask whether the scope includes testing edge failover, and who holds the on-call duty. Compare the result against your current LaunchDarkly Relay Proxy hosting and the service connection billing it replaces. Keep the comparison on a per-location, per-year basis so that adding a region is visible in the numbers.
How DeployOpen scopes and delivers Relay Proxy replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source flag platforms inside your own cloud accounts, data centers or air-gapped networks. For a Relay Proxy replacement, we start from your current SDK topology and the edge components that serve flags inside your network.
How we scope
- Engagements are fixed-scope, with the Relay Proxy inventory, target edge design and deliverables agreed in writing before work starts.
- The written scope lists each application, SDK and network zone that will read flags through the replacement edge layer.
- We confirm which Unleash or Flagsmith edge component fits your cache, latency and license requirements before any build begins.
How we build
- We deploy the flag server and its edge or proxy tier inside your environment, with the database and caching choices recorded in the design.
- Configuration is tested against your SDK connections, including how each application reconnects after an edge restart or network interruption.
- Offline or disconnected operation is designed and tested as a defined behavior, not assumed from the commercial product.
How we hand over
- Deliverables include architecture diagrams, deployment runbooks, configuration files and a cutover plan for moving SDK endpoints.
- We document how the edge tier is refreshed, backed up and upgraded, including the end-of-life dates for any component you rely on.
- Your team receives walkthroughs and a record of tests run, so operators can run the edge layer without DeployOpen on call.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover license changes and version upgrades, such as the Unleash Edge end-of-life planning your team must complete before the open-source version reaches end of life.
- Ask us to confirm which support scope and response terms apply in the written quote for your environment.
