FeatBit: self-hosted feature flags with a relay proxy and an agent model
Enterprise-grade feature flag platform that you can self-host. Get started - free.
At a glance
- What is it?
- FeatBit is an MIT-licensed feature flag platform you run yourself: a portal, an evaluation API, and SDKs for .NET, JavaScript, React, React Native, Node, Java, Python and Go. It fits teams that need flag data to stay inside their own network, and it costs you a Docker Compose stack or a Kubernetes deployment to keep alive.
- Who is it for?
- Adopt FeatBit if you already run containers and need flag evaluation and flag data to stay inside your own network, and if your stack is one of the SDKs it ships. Do not adopt it if nobody on the team owns a Compose or Kubernetes deployment, or if you need a hosted service with a support contract.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem FeatBit solves, and the teams it is aimed at
FeatBit is a feature flag management tool you host yourself. The README frames the pitch around four claims: ship code safely by rolling a feature out to a fraction of users first, target specific users, decouple deployment from release, and host the flag service wherever your business needs it, which the README ties to compliance and data protection. That last point is the one that decides adoption. If your organization can send user identifiers and flag rules to a third-party SaaS, a hosted flag service removes a whole class of operational work. If it cannot, or if procurement will not sign off on it, a self-hosted platform is the realistic option, and FeatBit is one of the MIT-licensed ones.
The intended user is a developer, not a platform team. The README says the project is "born for developers" and that flag checks are if/else statements rather than DevOps work. The C# example in the README is exactly that shape: build an FbUser with an id, call BoolVariation with a flag key, a user and a default value, and branch on the result. The effort sits on the hosting side, not the calling side.
The repository is TypeScript as the primary language, with .NET 8, Python 3.9 or later and Angular 19 appearing in the README badges. That mix matters if you plan to read the source or file a patch: the portal is Angular, and there is .NET in the stack alongside the TypeScript.
Portal, evaluation API, relay proxy: how the pieces fit
The material describes three moving parts. The portal is the web UI where flags are created, managed and filtered, and where users are targeted with specific flag variations. The SDKs are the client side: the README lists .NET (C#), JavaScript, React, React Native, NodeJs, Java, Python and Go, plus OpenFeature providers, and says more are coming. Between those two sits the relay proxy, covered in a separate documentation section, with an agent model described under "Understanding Agents".
The relay proxy is the piece worth understanding before you commit. In a self-hosted flag system, every application process either talks to the flag service directly or talks to a local relay that holds flag data and answers evaluations. The FeatBit documentation has a dedicated relay proxy section and an agent concept, and the README points at it for self-managed deployments. What the supplied material does not give is the internal data flow: it does not say how flag rules propagate from the portal to the relay, how often agents poll, or what happens to evaluation when the relay is unreachable. Those are the questions to answer from docs.featbit.co before designing a production topology, not from the README.
The SDK call itself is a local evaluation against a default value. In the C# example the third argument is defaultValue: false, so the calling code has a defined branch even when the flag cannot be resolved. That default is a design decision you make per call site, and it is the thing that determines what your users see during an outage of the flag infrastructure.
Getting a local instance running in three documented commands
The README's quick start is three commands and a URL. Clone the repository, change into it, and bring the stack up with Docker Compose:
git clone https://github.com/featbit/featbit cd featbit docker compose up -d
Once the containers are up, the portal is at http://localhost:8081. The README gives default credentials of test@featbit.com with password 123456. Those are published in the README, so treat them as a bootstrap account to change immediately, not as a login.
The README carries a note that the portal is only reachable from the machine running Docker Compose by default, and points to a FAQ entry titled "How to make FeatBit portal accessible publicly" for the change. That default is sensible for a first run and wrong for anything shared, so the port exposure is the first thing to decide.
For anything beyond a laptop, the README points at three places: the installation documentation for Docker Compose, Kubernetes manifest files in the kubernetes directory of the repository, and the relay proxy documentation including the agent section. There is no Helm chart mentioned in the supplied material, so the Kubernetes path appears to be raw manifests you apply and maintain yourself. The README does not list the individual service names, ports or environment variables for the Compose stack, so sizing the deployment means reading the compose file in the repository rather than the README.
Release cadence and what that means for your upgrade window
The release list shows 5.4.6, 5.4.7 and 5.4.8 landing within about three weeks of each other in August 2026, with the last push to the repository in September 2026. Patch releases at that interval are normal for an actively developed platform, and they are also the maintenance cost you take on by self-hosting. There is no managed upgrade path in the material: you pull a new image and restart your stack, or you apply updated manifests.
What the material does not tell you is whether the portal, the evaluation API and the relay proxy can be upgraded independently, or whether a version skew between them is supported. That is the single most important operational question for a self-hosted flag system, because the relay is typically deployed closer to your applications and moves on a different schedule. Check the release notes and the installation documentation for a compatibility statement before you plan a rolling upgrade.
Licensing is straightforward on paper: the repository is MIT, and the README shows an MIT badge. MIT permits commercial use and modification, and it comes with no warranty. That is a permissive licence, not a support contract, and it does not settle the question of what your own compliance team requires for the data the portal stores about your users.
Where FeatBit is the wrong choice
The obvious limitation is operational. A self-hosted flag platform is a service with a database, a portal and an evaluation path that your applications depend on at request time. The README's three-command start is genuinely short, but it produces a stack you now own: backups, upgrades, TLS, and the question of what happens when it is down. The default-value argument in every SDK call is your answer to that last question, and it is per call site, so it is easy to get wrong in one place and not notice until an incident.
A second limitation is SDK coverage relative to your stack. The README lists .NET, JavaScript, React, React Native, NodeJs, Java, Python and Go, plus OpenFeature providers. If your services are in a language outside that list, the OpenFeature provider route is the only documented option, and the material does not describe how complete those providers are. Verify the provider against your language before assuming parity with the first-party SDKs.
The third case is scale of need. If you have a handful of flags and one team, a self-hosted portal, an evaluation API and a relay proxy is more infrastructure than the problem requires, and the upgrade cadence above becomes a recurring chore. The README itself offers a hosted demo at app.featbit.co, which is the right way to evaluate the UI before you decide to run it.
How this differs from a hosted flag service
The real alternative for most teams is a hosted feature flag service rather than another self-hosted project. The difference is not the SDK call, which looks similar everywhere, but who operates the evaluation path and where the flag data lives. With a hosted service, flag rules and user identifiers leave your network, the vendor handles availability and upgrades, and your cost scales with seats or evaluation volume. With FeatBit, the network boundary is yours, the upgrade schedule is the release cadence shown above, and the cost is the containers and the person who maintains them.
Against other self-hosted options, the distinguishing element visible in this material is the relay proxy and agent model, documented separately from the core installation. That is the part aimed at deployments where applications should not each hold a direct connection to the flag service. The README does not compare FeatBit to any specific project, and the supplied material gives no basis for a feature-by-feature comparison, so treat the relay design and the SDK list as the two things to evaluate against whatever you are running today.
One concrete difference worth noting: FeatBit's README pushes self-hosting first, with the hosted demo as a try-before-you-run path. A vendor-led service does the opposite. That ordering tells you which deployment the project is optimized for.
Editorial conclusion
Adopt FeatBit if you already run containers and need flag evaluation and flag data to stay inside your own network, and if your stack is one of the SDKs it ships. Do not adopt it if nobody on the team owns a Compose or Kubernetes deployment, or if you need a hosted service with a support contract. Before committing, run the documented three commands on a laptop, open the portal at localhost:8081, change the default credentials, then read the Kubernetes manifests in the kubernetes directory and the relay proxy and agent documentation to confirm the topology matches your network.
Community notes