Feature flags seem simple at first, but they tend to grow complicated over time.
You start with a boolean in a config file. Then you need environment overrides. Then kill switches. Then scheduled rollouts. Then temporary debug settings. Before long, you have conditionals scattered throughout the codebase and a shared understanding of how to toggle things that only exists in people’s heads.
At DealNews we had an internal feature flag system that handled basic enable and disable cases. It worked, but we kept running into situations where we wanted something more flexible. So I started looking at alternatives.
Most of the commercial options were focused heavily on experimentation. They support A/B testing, segmentation, analytics, and complex rollout strategies. Those features are useful for certain teams, but they were not what we needed. We were not trying to build an experimentation platform. We just needed reliable feature control and the ability to store configuration values.
The open source landscape did not have many options that matched those needs out of the box. The tools that existed either did not support the scheduling and value storage we wanted or required architectural patterns that did not fit our environment. So we built Phlag.
Phlag has a very narrow purpose. When asked for a feature flag, it returns a value. That value might be a boolean, a number, or a string. That is the entire contract. It does not attempt to track user behavior or run experiments. It simply answers the question: what is the value of this flag right now?
One of the features that was important for us was scheduling. In production environments you often need temporary changes. You may want to enable debug logging during an investigation and ensure it turns off later. You may want to enable functionality for a seasonal promotion. You may need a change to activate during a maintenance window. Without scheduling, someone has to remember to reverse the change. Eventually someone forgets. Phlag allows flags to have start and end times so those temporary changes manage themselves.
Today we primarily use Phlag for feature rollouts and kill switches. That alone provides a lot of operational safety. It allows us to deploy code paths that can be disabled quickly if needed. Phlag also supports numeric and string values, which means it can act as a centralized configuration system rather than just a collection of booleans. We are beginning to use it in that way as well.
Phlag is written in PHP because that matches our team’s expertise, but it is not limited to PHP environments. It exposes a REST API and can be deployed using Docker or Kubernetes. Any system that can make an HTTP request can consume it. In practice, it should work for most teams regardless of their application stack.
I suspect Phlag will be most useful for teams that want a self-hosted option and do not need a full experimentation suite. Commercial feature flag services can become expensive as usage scales, especially when you are paying for capabilities you do not use. Phlag focuses on the core problem of returning a flag value reliably, without adding layers of complexity.
There was not a single dramatic challenge in building Phlag. Keeping the scope small made the architecture straightforward. We focused on the data model, the API, and predictable behavior. We used AI tools to help with the UI, which allowed us to spend more time on the underlying system design.
Recent work has focused on improving the user interface and making the system easier to use. I have looked at efforts like OpenFeature, which are interesting, but they also aim to support a broader set of capabilities than Phlag currently targets. For now, the goal remains the same: keep it focused and reliable.
If you are evaluating feature flag systems and find yourself wanting something simple and self-hosted that just returns a value when asked, Phlag might be worth trying.
