I'm the founder of Flipt, an open-source (https://github.com/flipt-io/flipt) feature flag tool that I (and others) have been working on for the past few years.
About a year or two ago we added support for serving flag state from various non-relational declarative stores like Git, OCI, Object Store, etc.
Many of our users came to love the git-backed storage, as it allows them to keep their feature flags close to their code in there organization's repos. But they had one (rather large) ask, and that was the ability to use the UI to manage flag state changes and still use Git as the backend.
So today we're rolling out our hosted solution that does exactly that (and more soon).
I would love any feedback, questions, etc, or if anyone would give it a spin! Happy to extend the 14-day trial as well for anyone interested in providing product feedback.
Thanks!!
What do you guys do when GitHub inevitably has an outage?
With DB feature flags, there's one more source of truth for changes to production infra.
(downside, of course, is that changing feature flag values is much slower using git vs DB)
Another benefit is you can easily replicate the current (or previous) state of production/staging/etc flags locally just by doing a `git clone` and then run our self-hosted version locally. Its a single binary, can be installed with curl or homebrew and can read the flag state from your local filesytem.
This allows you to test your code locally or in CI with the same state in production
I was thinking that git (in a separate repo from main code) would be used to store the changes to configs, but then you would still need a system that tails the git changes and distributes them to clients.
That’s the way config serving was done at Facebook - a mercurial repo with all configs and tooling to edit configs which creates mercurial commits. Then, the mercurial repo is continuously tailed and values are saved to ZooKeeper, and then client libraries read config data from zookeeper / subscribe to updates / etc.
Use s3. Honestly.
Flipt Open-Source can be run to consume from these locations. You can go as far as configuring a workflow to publish on push, so that you can combine our managed UI with any of these distributions methods through Git.
With any of these backends (including Git), we periodically fetch and cache data in-memory. Evaluations work on an in-mem snapshot. So temporary downtime doesn't propagate into your applications being unable to get flag evaluations.
Re: GitHub outage, each org gets their own instance in our cluster and maintains a checkout of the git state, so you can still write/read from your environments, they just wont be synched to GitHub until they recover.
We're also thinking about adding other 'sinks' like S3/object stores and OCI as backup sinks.
edit: it also seems silly to force users to choose an organization name with a big warning that they can't change it later. Why stop me from signing up? I almost didn't sign up because of this, but decided I would just try it out.
We could definitely look into supporting other types and making this simpler. The constraints that are matched can be of several types, which we try to parse at evaluation time https://docs.flipt.io/concepts#constraint-types.
Also thank you for the feedback about not being able to change the organization name. Currently we use the 'slug' of the organization (based on the name) when we setup the routes for your environment, so it was just simpler to make it a one time thing.
But I think we could support renaming your org, it would just make the previous URLs invalid, or we could maybe handle redirects on our end too.
Feel free to send me an email at mark <at> flipt.io, or drop into our Discord to say hi at https://flipt.io/discord
In our experience a lot folks came and said… but the ui is so important for us to be able to use a feature flag tool.
Use the same SDK and ping github rest api to get the values of the the flag.
I know, this is very weird... But i cant deny it would be helpful for very small projects
We've been thinking a lot recently about supporting 'edge' k/v stores like vercel/cloudflare and having the client side evaluation SDKs pull from there, which wouldn't require a server at all. This seems very similar just with using GitHub. We could even use GitHub Container Registry as the store as its OCI compliant.
Thank you for using Flipt btw!!
Also S3 (+ azure and GCP) would be a good 'edge' k/v store.
Someone could start with Github in a simple project, migrate to S3 to handle more requests and then migrate later to a full server solution... All of this keeping the same client codebase
We're working on personal accounts next, but due to GitHub API/apps permissions, we have to request a different set of creds to get that to work.
One thing is that running Flipt open source on your infra, means running replicas all sourcing from the same Git repo. They currently polls for updates and this means eventual consistency comes into play when you scale. We have plans to help mitigate that with cloud though (pushing updates from cloud to your self hosted runners).
"Feature Flags that live inside your code" - That's just variables, no?
Means you can experiment and target different cohorts with variants of your app without restarting processes everywhere.
