ivarconr

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.