docs: Edge Proxy adoption decision guide (complement to operational guide)

Open Beginner friendly
#7,508 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
Half a day
Newbie friendliness
74/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Domain
documentation

Research direction

Start by reading the Edge Proxy operational guide linked in the issue and use it as the sibling page's context. Write a short decision guide covering latency and geographic distribution, data residency, local evaluation, and why cost or rate limits are not primary triggers. Done means the decision flow and operational ownership for self-hosted and Private Cloud customers are explicit.

Written by the indexing model from the issue text.

Description

docs

Gap

The Edge Proxy operational guide covers how to deploy and configure the proxy. It does not cover when a customer should adopt it. Customers consistently ask this during evaluation and during scaling decisions, and the answer is currently improvised by sales engineering and CS.

Proposed scope

A short decision guide as a sibling to the operational page.

Primary trigger: performance / latency concerns, typically driven by geographic distribution of users.
Secondary trigger: data residency needs that core API regions cannot satisfy.

Not a primary trigger: API cost or rate constraints. Edge Proxy is a last resort for cost reduction because (a) it introduces more infrastructure to manage and another failure point, (b) for self-hosted customers, moving API load elsewhere often shifts infra cost rather than reducing it, (c) if you can accept the proxy's limitations on identity/trait persistence, local evaluation often solves the same problem more simply.

Decision flow:

  1. Do you have performance or latency concerns? If no, do not add Edge Proxy.
  2. If yes, can local evaluation solve it? If yes, prefer local evaluation.
  3. If no, Edge Proxy is the right tool. Operational ownership: customer operates it themselves on self-hosted; Flagsmith operates it on the customer's behalf on Private Cloud.

Closes the "when to adopt" gap that the operational guide does not cover.

Dominant language
Python
Stars
6.6k
Forks
571
Avg merge
1d 16h
Merged PRs (30d)
116

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Flagsmith/flagsmith

All issues in Flagsmith/flagsmith

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.