TL;DR
- What: Nona is an open-source, self-hosted remote config and feature flag service - a Firebase Remote Config alternative.
- Why: we built it small on purpose - one thing done excellently, not another 5,000-feature SaaS.
- How: one Docker container, multi-zone via SQLD, real-time with no cache - obsessing over latency and memory.
- The point: we do it for the craft, not the feature count. Open source isn't dead.
There was no story. No origin, no 2am brilliant idea. I wasn't soaking in my bathtub when - EUREKA - I decided to build feature flags. No, it's nothing like that.
The story has much more to do with love and affection than anything else.
A world full of slop
In the year of 2026 CE, we have found ourselves in a world filled with AI slop - and open source projects are a primary offender in this case. We (not I, because I work in a company full of like-minded and bright-minded individuals) love software. We've been soaking in it for years, and we actually like to write code ourselves, instead of leaning on a mystery black box that pulls out open source project #151,523.
We chose specifically a small scope to work in, and our aim is to optimize the heck out of it. We want to be impressive - and we want to impress with our performance and our care for detail, not because we crammed 5,000 features into a simple application that 99.99% of the audience will never use. We want to deliver something simple that actually solves a common problem.
Our mission
So this is our mission goal: we don't want to be another SaaS in the list of feature-flag products. We want to be an open source go-to product that people use - one that does exactly what it says on the box, does it excellently, and that's it. We want to be the go-to for remote config and feature flags because it's right, not because we have the most shiny features.
Our secondary mission goal is to keep it as simple as possible. If we ship a self-hosted product that makes you jump through hoops, then most devs or ops will just give it up, sign up to something like Firebase Remote Config, and deal with that instead.
The part we pride ourselves on
There are a couple of things we pride ourselves on with this project. We chose this specific architecture so you can run Nona as one single Docker container and yet have multi-zone availability in the product - we implemented this with SQLD as a server that handles all the requests.
We made sure this option is available so you can get your response in the least amount of time possible. We understood that using SQLD will 100% slow things down a peg, because it's an actual server that has to handle HTTP requests inside the server and then create replicas across all servers as necessary. So we have to tune the performance of each of these requests - high load, big amounts of data, replicas, no replicas - and we've gotten to a number we are satisfied with. BUT IT'S STILL A WORK IN PROGRESS.
We really want to squeeze out the best time possible while keeping it REAL-TIME, NO CACHE. For reference, the performance findings can be found in our repo.
Another thing we are trying to work on is the amount of memory the application uses. We are talking about a minimal application that should only provide configuration - why should it eat up more than 512MB of RAM? We currently have no specs for this, but lowering the latency and lowering the memory consumption are our main objectives.
Who we are
We are architects and developers with 15 years of experience in the field. We've built half the internet at this point, and we keep going. Touch the untouchable, break the unbreakable. Row! Row! Fight the power - that kind of thing.
If I need to point it out: we are at our best managing big data and high-scale systems, as we work a lot with ETLs. In these high-scale systems every byte of memory counts and every moment of latency is top priority - so we transfer that experience into this.
Open source is not dead
But on a more hopeful note, I'd like to say: open source is not dead. I've read a lot of articles about how there are products right now that can just copy your repo to make their own exact product - so all our efforts would be nullified with that AI approach.
That's fine. But who is going to take care of this copied product? Who nurtures it, grows it, turns it into something dependable throughout the years? With that kind of approach there would be no way we could build projects like SQLite, for example, or any JavaScript framework (which are too many to list).
To carry that torch of open source is why we hope to write open source projects and invest our time into making something powerful. As I said, we are here not to gain anything - but for the love of the game.
Nona is open source under the Apache 2.0 licence. Browse the code on GitHub, or start at nonaconfig.com.
Top comments (0)