Why did we want to create Nona

The problem we kept running into

Teams want to change application behavior without waiting for a full deployment. That need shows up everywhere: feature flags, mobile app tuning, kill switches, staged rollouts, temporary operational fixes, and experiments. The problem is that remote config tools often come bundled with a larger platform decision. If you want the capability, you are expected to accept the huge entaglement that comes with it - the huge packages, the tech giants that manage them and all the little fineprints you have no idea about that come together with your product.

This trade off is absolutely not necessary and avoidable.
A team should be able to turn a feature on, turn a feature off, or update runtime configuration without handing over deployment independence. That is the gap Nona is trying to close.

Why open source was the right starting point

We as a company have a certain amount of respect for open source development.
Primary not because of the openness and transparency, but because of the discipline it forces on the design and implementation.
Usually when you are doing open source development, you are doing something a small scope of something and hyper focus only on that and make it work good.

Transperancy is a nice to have, but the real reason we wanted to build in the open is that it forces us to be thoughtful about the product direction and the implementation. It forces us to be intentional about the design and the API. It forces us to be disciplined about the scope and the focus. It forces us to be humble about what we can achieve and what we can't.

The product principles that shaped Nona

How that thinking changed the implementation

Those principles pushed us toward a smaller and more legible system. Nona exposes a straightforward REST API. It treats remote config as a simple runtime dependency, not as a hidden sidecar bolted onto one framework. It can be self-hosted with Docker. It keeps environments explicit. It supports official clients where they reduce friction, but the underlying model stays plain HTTP so no team is forced into a special SDK just to read configuration.

The same reasoning is why the project includes a Firebase Remote Config migration path. If the mission is to make open source remote config practical, then leaving closed hosted systems has to be a supported workflow instead of a hand-waved blog post.

What we are trying to make easier

We care about the teams that need safer operational control but do not want to build a custom platform just to get it. That includes mobile teams trying to avoid slow release loops, backend teams that need reliable kill switches, and product teams that want staged rollout behavior without burying business logic in deployment pipelines.

The mission is simple: make configuration changes easy to ship and easy to trust. If a team can run Nona on its own infrastructure, understand what it is doing, switch away from locked platforms, and control application behavior without redeploying, then the project is doing its job.

Our commitments

What success looks like from here

Success is not just more stars or more traffic. Those can be useful signals, but they are not the mission. Success is a project that developers can discover, understand quickly, and actually adopt. It is a codebase that makes sense to read. It is documentation that answers real questions. It is a product direction that stays useful even when deployment targets, frameworks, and LLM tooling keep moving.

That is also why we want the story around Nona to be visible. Search engines and LLMs are better at surfacing projects when there is a clear, first-hand explanation of what the product is, why it exists, and what kind of problem it is built to solve. This page is part of making that intent explicit.