ivarconr

That's a great question, and the honest answer is that it is hard. We can easily add new capabilities in the UI, but for the Unleash protocol itself we need to make sure all changes are backward compatible, because we do not control the SDK version.

We have a few tricks we apply:

- Yggdrasil is the "Unleash SDK Engine". Written in rust and cross-compiled to multiple languages. This makes it easier to add features, and ensures all SDKs implements the protocol the same way. https://github.com/Unleash/yggdrasil

- Try to have a simple and generic protocol - This allows us to add new targeting capabilities later, without having to change the SDKs. In practice I must admit this is not easy and have only been possible in a few scenarios

- Make sure the SDK report their protocol version. This allows you do adapt the product to tell the user to upgrade to get new features. We also leveraged the SDK version when we introduced segments, as we could rewrite those to a less performant format in the API, to simplify the rollout.

I will take quaint. We started it as a sideproject in 2014, so the throwback argument is fair. What i find fascinating is the ability to runtime control featurs in production, particularly the ability to kill it, seems more important than ever these days, where AI has made it pretty cheap to produce software.

The ConfigCat team is great!

Unleash also originates from Europe.

Got it, thanks. AI was used to clean up the language, not to generate content.

If your current platform support (AppConfig etc) is sufficient, you should probably keep using it.

We see teams move when they have more complicated needs, either in terms of compliance, 4-eyes approvals, scalability and lifecycle tracking.

Anything you’re missing today, or is it working fine?

Yes, AGPL. And yes, it’s open core. For personal use you can self-host the server and SDKs with no usage limits, and that covers flags, targeting, gradual rollouts and variants. The paid tiers add things that mostly matter to larger teams: SSO, RBAC, change requests, and Edge for high-volume frontend traffic. For a personal setup, the open source version should be all you need.

For one app and one team, honestly not much. It starts to matter when you want gradual rollouts where the same user stays in or out across services, different rules per environment or customer, an audit log of who flipped what when something breaks, and a way to find dead flags. And then the boring parts: not doing a network call on every check, and what happens when the store is down.

This is the real problem in my experience. Creating flags is easy, removing them isn’t. We ended up building lifecycle tracking for it: each flag type has an expected lifetime, flags get marked potentially stale when they pass it, and you can see when a flag was last evaluated in each environment so you know it’s safe to delete. Someone still has to remove the code though :)

On Unleash Cloud: 100M request per month on Unleash cloud would be $235 + 75$ per seat ($53 Million requests included).

Biased answer since I work on Unleash, but the pricing point is something we thought about deliberately:

- Self-hosted open source is free, with no usage limits. Run it on your own Postgres and you pay for a small VM.

- Paid plans are priced per seat (people using the admin UI), not per end user or per request. One million MAUs or a hundred million costs the same (we have some protection for high traffic volumes)

- Server-side SDKs evaluate locally, so a flag check never hits our servers and there's nothing to meter. Frontend traffic goes through Edge, which you can also self-host.

If you'd rather not lock into any vendor, put flags behind OpenFeature. Unleash, Flagsmith, GrowthBook and others all have providers, so switching later is a config change, not a rewrite.

Thanks, "I could build that" → "oh, that's what the other 90% is" is pretty much how Unleash started for us too. What does your homegrown version do? Always interested in where people draw the line between building and adopting.

Hi HN, I'm Ivar, creator of Unleash.

Unleash started in 2014 as an internal tool at my company at the time, because we wanted to ship to production continuously without big-bang releases. It's an Open-Source feature flag platform with SDKs for >25 languages.

A few design choices that might be interesting:

- Local evaluation: server-side SDKs fetch the flag config and evaluate in-process, so user data never leaves your app and a flag check is a memory lookup, not a network call.

- Shared Rust engine (Yggdrasil): the evaluation logic is written once in Rust and embedded in the SDKs, so behaviour is the same across languages.

- Unleash Edge: a Rust proxy/cache for frontend and edge clients at scale. (Commercial)

- OpenFeature: supported if you don't want to lock into our SDKs.

Thanks for sharing. I have seen systems grow in to thousands of flags, where most developers does not know what a particular flags do anymore.

> It seems to be skipping past the use-cases and assumptions

This is a great feedback. Our intention was to describe how such a system work at scale, but I see we could do better in this section, thanks!

Do you have some use-cases in mind?

If we had started Unleash just a few years earlier, we would not have been able to scale private instances like we have.

This is because platforms like Kubernetes empowers Unleash to efficiently sandbox customers. And as managed Kubernetes matures, this sandboxing becomes easier and easier to run.

This significantly brought down the cost of choosing single tenant private instances over multi-tenant solutions. It changed the calculus, especially when you bring in all the benefits of single tenancy.

In this way, single tenant private instances have shifted from an outdated way of doing things, to the future.

Ten years ago it would have been nonsensical to choose single tenant. It would have been seen as a step backwards. A focus on private instances is not for everybody, particularly for B2C companies.

While we can do more today, there is obviously a cap on how many customers we can do this with. We’re nowhere near that limit, and newer technologies could make this even more scalable over time. But for a B2C company with millions of tenants, private instances probably wouldn’t make sense just yet.

It's interesting that we often want to run the databases our-self. Even I thought that was a good idea for a while, but learned the hard way all the work we needed to invest in this.

We often underestimate the total cost of taking care of the database our-self, I did as well (patches, upgrades, backups, scaling) compared to managed services.

Will continue building Unleash (https://www.getunleash.io), still a lot to do.

Strategy constraints have been available for paid users for many years already, and I am super happy to finally bring this powerful feature to all open-source users.

Source code available on https://github.com/unleash/Unleash

Got SDKs for most popular programming langugages:

- Go

- Java

- Node.js

- Python

- Ruby

- .Net

- Rust

- JavaScript

- Android

- iOS

- ...and more

What feature would you want us to add?

- Stream support?

- Native SDKs?

- Third party integrations (jira, datadog, etc)?

- Segmented rollout?

- Business metrics / kpi tracking?

- Automatic code cleanup?

A feature management system such as unleash-hosted can give you full control of your sprint delivery. In this article we will explain why and how.