Hacker News: ivarconr

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Sat, 07 Nov 2026 15:46:00 +0000

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.

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 21:13:06 +0000

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.

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 21:00:42 +0000

The ConfigCat team is great!

Unleash also originates from Europe.

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 20:56:11 +0000

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

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 20:49:51 +0000

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?

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 17:20:39 +0000

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.

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 17:09:26 +0000

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.

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 17:08:35 +0000

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 :)

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 14:19:01 +0000

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

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 14:01:46 +0000

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.

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 13:56:12 +0000

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.

New comment by ivarconr in "We've built an open-source feature flag server for 11 years"

ivarconr — Fri, 06 Nov 2026 11:42:28 +0000

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.