FeatureProbe: A Self-Hosted Feature Management Service With A/B Testing Built In

The Problem FeatureProbe Targets: Flags Without Handing Over Your Traffic

FeatureProbe is a feature management service you host yourself. The README frames the audience as R&D, SRE and operations teams that want to launch features or swap implementations with lower risk, and it lists the operational payoffs it cares about: fewer long-lived branches, faster recovery by turning a toggle off instead of waking an on-call engineer, testing in production for a slice of users, and a single portal for rollout, rollback, peer review and permissions. That last item is the interesting one. Plenty of open source flag libraries exist as a library only; FeatureProbe ships the whole loop, including a management center with accounts and permissions, so a non-engineer can change a rollout percentage without a deploy. The README also states the project ran for over five years inside a company with 5000+ developers and supports a million-user level product. That is a claim about the authors' prior deployment, not a benchmark you can reproduce, and it is not evidence about your workload. Treat it as context for why the feature set looks the way it does, not as a capacity guarantee.

Architecture: Three Services Plus SDKs, Not a Single Binary

The repository layout splits FeatureProbe into distinct pieces. There is a management center made of an Admin UI (the ui directory, React and TypeScript) and an API backend (the api directory, Spring Boot). There is a separate evaluation Server in its own directory. Then there are SDKs, split into client-side (JavaScript, Android, iOS) and server-side (Java, Rust, Go, Python, Node.js). The split matters because it tells you where flag decisions actually happen. Your application imports an SDK, constructs an FPUser, and asks the SDK for a value. The SDK is the component that receives toggle state and evaluates targeting rules locally, which is why the README's pseudo-code calls boolValue with a default fallback rather than making a blocking HTTP call per request. The Admin UI and API are the control plane where flags are defined and targeting rules are edited; the Server is the data plane that distributes configuration to SDKs. That is a standard control-plane/data-plane split, and it means a failure of the Admin UI does not necessarily stop flag evaluation in your services. The README does not spell out the transport between Server and SDKs, so if you need to know whether it is polling or streaming, that has to come from the SDK repositories, not from this README.

Getting It Running: Two Commands and One Default Password

The quickstart is short. The README requires git and docker, then gives:

git clone https://github.com/FeatureProbe/FeatureProbe.git cd FeatureProbe docker compose up

After that you visit http://localhost:4009 and log in with username admin and password Pass1234. The README explicitly notes you should change the ports defined in docker-compose.yml as needed, which is the only configuration guidance it offers. On the application side, the pattern is a user object plus a typed lookup with a default:

FPUser user = new FPUser("user_id", "user_name", "user_email"); if (fpClient.boolValue(YOUR_TOGGLE_KEY, user, false)) { ... }

The default value in that call is the part that decides your outage behaviour. If the SDK cannot reach the Server, or the toggle key does not exist, your code takes the fallback branch. The README does not document what happens to a running SDK when connectivity drops, so pick your defaults as if the flag system is unavailable, because at some point it will be. Two things about this quickstart deserve a direct callout. First, Pass1234 is a published default for an admin account on a service that controls what your production code does; changing it is not optional hygiene, it is the difference between a feature flag system and a remote code execution path for anyone who can reach port 4009. Second, docker compose up on the default ports is fine for a laptop and wrong for anything else, which the README acknowledges only in passing.

The A/B Testing Story Is Real but Underspecified in the README

FeatureProbe markets A/B testing as a first-class capability alongside flags, and the screenshots include a traffic monitor and a metric analysis view with metric configuration. The README's sixth bullet claims the operation team can run online A/B tests and gain insight from different marketing or sales strategies. What the README does not explain is the mechanism: where metric events come from, how exposure is recorded, whether there is a separate event ingestion endpoint, or how statistical significance is computed. The screenshots imply a metrics pipeline exists, and the topic list on the repository includes abtest and abtesting, but the README stops at the marketing description. If A/B testing is your primary reason for looking at FeatureProbe, the flag half of the product is documented well enough to evaluate from this material and the experimentation half is not. You would need to read the Server and API directories and the docs site before you could judge whether the metrics model fits your event pipeline. That gap is not disqualifying, but it is the difference between a platform you can scope in an afternoon and one you have to reverse-engineer.

Where FeatureProbe Is the Wrong Tool

The release history is the first limitation and it is not a small one. The three most recent tagged releases are 2.6.0 (May 2023), 2.6.1 (July 2023) and 2.7.0 (September 2023). The repository shows a push in June 2026 and is not archived, so work is happening, but a roughly three-year gap between the last tagged release and the latest activity means you are choosing between deploying a stale tag and tracking main. Neither is comfortable for a component that sits in the request path of your application. The second limitation is operational surface. This is not a library you add to a build file; it is an Admin UI, a Spring Boot API, a separate evaluation Server, and whatever datastore docker-compose.yml provisions. Backups, upgrades, TLS, and access control for the portal all land on you. The README's own bullet about SRE controlling toggles from the UI is a benefit only if the UI is up and secured. Third, the SDK matrix is uneven. Client-side SDKs exist for JavaScript, Android and iOS, and server-side for Java, Rust, Go, Python and Node.js. If your stack is not on that list, the README offers no generic fallback. Finally, the README does not document flag evaluation semantics in any depth: no explanation of how targeting rules are ordered, what happens on conflicting rules, or how percentage rollouts stay stable for a given user across SDK versions. Those details determine whether your experiment is valid, and they are not in this material.

How This Differs From Running Your Own Flag Library

The obvious alternative is not a competing product but a self-managed flag library plus a config store: a small evaluation function in your codebase reading toggles from a database, Redis, or a config file, with a simple admin page you build yourself. The difference in approach is where the targeting logic lives. With a homegrown setup, targeting rules are code you wrote, which means changing a rollout percentage for a segment is a code change or a database edit, and audit trails, peer review and permissions are things you build. FeatureProbe moves that logic into a separate service with a UI, so rule changes are data operations performed by whoever has portal access. That is the trade: you give up the simplicity of a config file and take on a service to operate, and in exchange you get a reviewed, permissioned, auditable path for changing runtime behaviour without a deploy. If your flag needs are five boolean toggles flipped by engineers, the homegrown route is less machinery for the same outcome. If you have operations staff who need to change targeting for a marketing campaign, the portal is the whole point. The README's own framing supports this reading: it repeatedly positions the management portal, not the SDK, as what differentiates the product.

Licence, Upgrade Cost and What to Verify Before You Commit

FeatureProbe is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not impose copyleft obligations on your application code, and running the service internally does not trigger distribution requirements. That is the licence text, not legal advice; if your organisation has policies about which open source licences are acceptable in production infrastructure, route it through whoever owns that policy. The practical upgrade cost is the part the README does not address. There is no migration guide in this material, no statement about storage schema compatibility between 2.6.x and 2.7.0, and no documented upgrade procedure for the compose stack. Because the SDKs live in separate repositories, a Server upgrade and an SDK upgrade are two independent decisions, and the README gives no version compatibility matrix tying them together. Before you deploy, verify four things: that the default admin credentials are changed and the portal is not exposed to the public internet; that your language has a server-side SDK rather than only a client-side one; that the docker-compose.yml ports and any persisted volumes are configured for your environment rather than the defaults; and that the tag you intend to run is the one you have actually read, since main has moved well past 2.7.0. If you cannot answer those four from the repository, the docs site at featureprobe.github.io is the next place to look, and the English and Chinese documentation are both linked from the README.

Editorial conclusion

Adopt FeatureProbe if you need flag evaluation to run inside your own network and you are willing to operate four moving parts (UI, API, evaluation server, database) yourself. Do not adopt it if you want a vendor to carry the pager for flag delivery, or if you need a release cadence faster than the one this repository shows. Before committing, change the admin/Pass1234 default credentials, confirm your language has a server-side SDK (Java, Rust, Go, Python, Node.js) rather than only a client-side one, and check whether the last tagged release still matches the main branch you intend to deploy.

Official sources

1. FeatureProbe/FeatureProbe on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases