TypeScript

Python

Java

Rust


In the most recent release of Flipt ([v1.31.0](https://github.com/flipt-io/flipt/releases/tag/v1.31.0)) we added support for OCI registries as a backend for feature flag data. The new backend follows in the footsteps of our other [declarative](https://www.flipt.io/docs/configuration/storage#declarative) file-based backends (`local`, `git`, and `object`). This blog post talks a bit about OCI, its growing popularity for non-container usecases and why and how you can leverage Flipt to distribute flags as OCI bundles.

## What is OCI?

OCI stands for the Open Container Initiative. Taking words directly from their landing page:

> The **Open Container Initiative** is an open governance
> structure for the express purpose of creating open industry standards
> around container formats and runtimes.

[https://opencontainers.org/](https://opencontainers.org/)

OCI currently declares and maintains three different specifications:

- [Runtime Specification](https://github.com/opencontainers/runtime-spec)
- [Image Specification](https://github.com/opencontainers/image-spec)
- [Distribution Specification](https://github.com/opencontainers/distribution-spec)

Each of these specifications come together to create a standard set of operating procedures for OCI-compliant container runtimes to fetch, isolate, and execute workloads.

It is probably important to clarify first that Flipt is **not** concerned with running container workloads. Flipt is concerned with the distribution specification (and tangentially with the image specification). OCI-compliant registries have proven extensible and valuable beyond just containerized applications. Their distribution specification includes extensibility points, which can be leveraged to store arbitrary contents with different artifact and media types.

These extensibility points make it possible for Flipt to package and publish its feature flag configuration contents via OCI compatible registries. Some OCI-compatible registries include:

- [GitHub Container Registry](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry) (Fun fact: our own [Mark Phelps](https://www.linkedin.com/in/markphelps1/) was a lead engineer and architect of GHCR at GitHub)
- [DockerHub](https://hub.docker.com/) (the OG)
- [Google Artifact Registry](https://cloud.google.com/artifact-registry)
- [AWS Elastic Container Registry](https://aws.amazon.com/ecr/)
- [Azure Container Registry](https://azure.microsoft.com/en-gb/products/container-registry/)

To ease our integration into the OCI landscape, Flipt has built new capabilities on top of a project called [ORAS](https://oras.land/). To quote what ORAS is from their site:

> ORAS is the de facto tool for working with OCI Artifacts. It treats media types as a critical piece of the puzzle. Container images are never assumed to be the artifact in question. ORAS provides CLI and client libraries to distribute artifacts across OCI-compliant registries.
>

Big shout out to ORAS for making this possible in Flipt.

## Prior-art

We’re not the first and certainly won’t be the last project to leverage OCI for non-container artifact distribution. OCI has created a standard for registry APIs, which is broadly useful for an extensible set of artifact and media types. The APIs are also designed around content-addressability, which lends itself to some very desirable caching traits and security improvements.

We got the idea to leverage OCI from past colleagues (shoutout [David](https://x.com/rawkode) and [Marko](https://x.com/mmikulicic)) and further validation from a number of modern technologies already leveraging OCI for non-container image purposes. To name a few:

**Helm** - A package manager for Kubernetes

Since v3.8.0 Helm has supported using OCI registries as a distribution medium for Helm charts.

[https://helm.sh/docs/topics/registries/](https://helm.sh/docs/topics/registries/)

**Timoni** - Another package manager for Kubernetes

From inception, Timoni has leveraged OCI registries for distributing its modules.

[https://timoni.sh/bundle-distribution/](https://timoni.sh/bundle-distribution/)

**Acorn Labs** - A platform for running and sharing applications

Acorns are shareable bundles of configuration for containers, services, and everything in between, which are distributed via OCI-compliant registries.

[https://docs.acorn.io/advanced/publishing](https://docs.acorn.io/advanced/publishing)

**Nuon** - A BYOC platform

Nuon leverages OCI registries for distributing their configuration artifacts.

[https://docs.nuon.co/concepts/vendor-cloud#artifacts](https://docs.nuon.co/concepts/vendor-cloud#artifacts)

## Improving Scale

The [Git backend for Flipt](https://www.flipt.io/docs/configuration/storage#git) provides an excellent experience for enabling GitOps feature flag workflows, with minimal operational overhead. You simply need Flipt and your repository provider to get up and running (the relational backend becomes optional, depending on whether or not you need authentication). This is great for quickly validating Flipt and should scale reasonably well for small to medium-sized projects and teams. The primary bottleneck for scale becomes the size of the source repository storing your flag state.

When configured this way, Flipt needs to clone the entire target repository and keep it in sync. We want Flipt to be suitable for both multi and mono-repositories, however, the larger the source repository, the greater the initial clone becomes and therefore startup time. Additionally, the higher the contribution throughput, the more work Flipt has to do to stay up to date. Flipt has only really begun to scrape the surface with Git, and there are certainly more optimizations we intend to make to scale this backend. However, OCI registries present a neat solution to this scaling problem.

<StarCTA />

Using an OCI registry and repository for feature flag bundles means the initial fetched payload is kept to only the state that matters to Flipt. In order to support this, Flipt comes with a set of new subcommands (see `flipt bundle`) for building, pushing, and pulling feature flag state as OCI bundles. The bundle format is designed such that Flipt only needs to refetch *namespace* contents when it changes from one update to the next. This is down to how we use separate layers for separate namespaces in the OCI bundles themselves.

One further byproduct of this is regarding the scope of access needed by Flipt. In this mode, Flipt only needs read access at runtime to the repository contents itself. This is opposed to the entire contents of your Git repositories. This is a win for the security-conscious folks out there.

## Experimentation

Beyond these scale improvements, there are further benefits in the form of arbitrary OCI repository tags. If you’re familiar with tagging a Docker image `latest`, then you already know what I am talking about. The `flipt bundle` commands support arbitrary tagging, and Flipt can be configured to source feature flag state from any desired tag you choose.

An intended goal of the Git declarative backend was to unlock branching feature flag state. Now you have the power of Git branches and tags, you can leverage them for experimenting with feature flag changes in different deployment environments. Instead of building the concept of environments into Flipt's own domain models, we would lean into the benefits of a version controlled storage medium to facilitate this kind of validation. Want to experiment with a change to feature flag state in your PR? Then you could automatically deploy Flipt to track your branch in a preview environment. Need to validate a change to your targeting rules in staging first? Then you could have your staging instance of Flipt track a `staging` branch in Git instead of `main`.

This last suggestion however has one big downside, while branches in Git are appropriate for more ephemeral proposed changes (e.g. via pull-requests and preview environments), long-lived branches other than `main` are frowned upon. We’re strong believers in [trunk-based development](https://trunkbaseddevelopment.com/) at Flipt, and we fully intend to help you enable it via feature flags. Expecting you to create long-lived branches for environments in hindsight seems unreasonable.

Where this new approach comes in handy, is instead separate folders can be leveraged in your repositories to represent different environments. The `flipt bundle` command can be employed to create separately tagged bundles for each environment. This has the added benefit that you can see the difference between your environments in a single commit by simply comparing the contents of each directory.

<BlogImage
  src="/oci-backend/diagram.png"
  alt="Demonstration of how to use OCI bundles for feature flag transport"
  width={3162}
  height={1543}
  caption="OCI bundles for feature flag transport"
></BlogImage>

One last potential use case of note is shareable and ephemeral remote bundles using [https://ttl.sh](https://ttl.sh). This is an on-demand ephemeral OCI registry provider. With ttl.sh you simply follow their instructions and tag your bundle with the duration of its lifetime (e.g. `ttl.sh/b7e858c6-8462-41d7-b526-863ae96db14b:10m` for a 10 minute bundle). Then you can share this bundle with anyone and they can `flipt bundle pull` it locally or configure Flipt to serve from ttl.sh directly.

## A Brief Tour

We’re currently working on a guide that will take you through the steps of setting up Flipt with OCI, as well as how to unlock these kinds of long-lived and ephemeral feature-flag environments in your platform. However, here is a quick introduction to get you started.

For this walkthrough, you will need the latest version of Flipt (`v1.31.0`) installed on your path (head over to our [Installation Documentation](https://www.flipt.io/docs/installation) for more details).

Next, you will need a directory with some Flipt feature state configured in it. For this example, we will create a single file named `features.yml`. If you want to name your feature flag files something different, check out our documentation on how [Flipt locates flag state](https://www.flipt.io/docs/configuration/storage#locating-flag-state). The commands we will talk about in this section (`flipt bundle build`) use the same strategy for locating flag state as Flipt’s other declarative backends (`git`, `local`, and `object`).

```yaml
# contents of features.yml
namespace: "default"
flags:
- key: "excitingFeature"
  name: "Exciting Feature"
  type: "BOOLEAN_FLAG_TYPE"
  enabled: false
```

Next, we will create our first bundle based on this state. In the same directory as this new file, run the following:

```bash
flipt bundle build mybundle:latest
```

Given everything works as expected you should see the resulting digest of the bundle printed onto your terminal. Now you have a feature flag bundle created locally. To see all your bundles, run the following:

```bash
flipt bundle list
```

Now that you have built your bundle, we can actually run Flipt over the local bundle itself. This is a great way to quickly validate your flag state before pushing it to some production serving registry. Simply start Flipt like so:

```bash
FLIPT_STORAGE_TYPE="oci" \
  FLIPT_STORAGE_OCI_REPOSITORY="mybundle:latest" \
  flipt
```

This will start Flipt on `http://localhost:8080`, where you should immediately see your feature flag is available.

To publish this bundle, we can use the Flipt bundle push command. Here we’re using the ephemeral registry [ttl.sh](http://ttl.sh) to get going quickly:

```bash
export UUID="$(uuidgen | tr '[:upper:]' '[:lower:]')"

flipt push mybundle:latest ttl.sh/$UUID:10m

echo "ttl.sh/$UUID:10m"
```

This should push your local bundle to the remote registry and print the target repository which can then be used again when running Flipt. Simply take the command to start Flipt earlier and replace the local bundle with the remote one.

```bash
# you can manually substitute the repository with the one echoed in
# the previous command if you're in a fresh terminal
FLIPT_STORAGE_TYPE="oci" FLIPT_STORAGE_OCI_REPOSITORY="ttl.sh/$UUID:10m"; flipt
```

Navigating back to Flipt in your browser should again show your feature flag as it was before. Only this time, Flipt will have used the remote repository to get its state. Try changing your feature flag from `enabled: false` to `enabled: true` and then re-build and re-push to the same repository hosted on ttl.sh. Flipt should eventually update (polling interval defaults to 30 seconds) to reflect this change automatically.

## What’s next?

This new backend in Flipt is in its infancy, and we have a number of ideas to make the experience of leveraging it easier. The following is a short list of features we’re considering:

**More local `flipt bundle` management commands**

For example, commands to help maintain and clean up old bundles or introspect into their contents. Perhaps a little TUI for exploring bundle contents?

**A GitHub action to simplify CI integration**

A quick and easy GitHub action to drop into your workflows for building and pushing.

**Feature flag state attestation**

Now that your flag state is in an OCI artifact, you could use a tool like [cosign](https://docs.sigstore.dev/signing/quickstart/) to sign your feature flag state.

**Garbage collection**

It will be no surprise that at some point someone will want to clear outdated bundles. We think Flipt could eventually help with that too.

We’re excited to see how this resonates with the community and what it unlocks for feature management. OCI is proving to be an invaluable distribution mechanism for all sorts of configuration concerns. We’re just getting started with our own ideas around how to leverage them for Flipt and for broader configuration concerns.

We would love to hear from you about your feature and configuration needs, so come hang out with us on our [Discord](https://flipt.io/discord) or open an issue or discussion in our [repository](https://github.com/flipt-io/flipt).


Feature Flags and OCI


Edge computing has become a recent phenomenon for organizations to explore as they scale to meet the demands of a worldwide customer base. It is simply defined as hosting either devices or networks closer to the consumer. Implicitly, as this happens, the user can perceive a much better experience due to the interaction speed of the application to the devices and networks the application interfaces with.

For example, you can imagine that a user in the United Kingdom will benefit from having their data stored in the UK instead of anywhere else in the world. In broader terms, geographical distance from a consumer to a device or network can be significant at times and does not come for free.

In terms of feature flags, the ability to leverage edge computing suits its use case fairly well. Feature flags can often guard critical paths of an application where it is beneficial that the latency of flag evaluation is kept as low as possible.

At Flipt, we have been exploring many different ways to achieve this goal of minimizing latency for flag evaluations. We already have features such as [server-side caching](https://www.flipt.io/docs/operations/deployment#caching), hosting data in an embedded database such as SQLite, or serving flag state straight from a [filesystem](https://www.flipt.io/docs/configuration/storage#filesystem) to name a few, so the idea of edge computing fits the paradigm quite nicely.

In recent weeks, we have been exploring running Flipt on the edge, and the rest of this post will detail the experience we had running Flipt in front of a notable edge database provider, [Turso](https://turso.tech/).

## Turso/sqld/libSQL

Before detailing exactly what Turso provides as a service, let us briefly cover the open-source technologies and their functionalities that power Turso, [libSQL](https://github.com/tursodatabase/libsql) and [sqld](https://github.com/tursodatabase/libsql/tree/main/libsql-server).

### libSQL

libSQL is an open contribution fork of SQLite and thus is fully backward compatible with SQLite. You can actually run a SQLite client over a libSQL database instance. Since SQLite is famously [closed off to external contributors](https://www.sqlite.org/copyright.html), the fork (libSQL) was born, which tries to cater to some of the issues or feature requests that the community wants with SQLite. There are many various distinct features that libSQL provides from SQLite such as [randomized ROWID](https://github.com/tursodatabase/libsql/issues/12), [WebAssembly](https://blog.turso.tech/webassembly-functions-for-your-sqlite-compatible-database-7e1ad95a2aa7), and [many more](https://github.com/tursodatabase/libsql#features).

### sqld

[sqld](https://github.com/tursodatabase/libsql/tree/main/libsql-server) is libSQL running as a daemon in “server-mode”. It not only provides an HTTP interface over libSQL, but also replication abilities from one libSQL instance to another. When running sqld, you can declare one libSQL instance as the primary and other instances as replicas of the primary. sqld will then replicate data from the primary to the replicas. This is a very powerful feature that we will explore in more detail later in this post.

The libSQL repository provides a nice [docker-compose example](https://github.com/tursodatabase/libsql/blob/main/docker-compose/docker-compose.yml) of how to configure sqld, and how it works overall. In addition to simple replication, sqld also provides [bottomless replication](https://github.com/tursodatabase/libsql/tree/main/libsql-server#integration-with-s3-bottomless-replication) in which data from the primary is continuously replicated to an AWS S3 bucket or any other S3 compatible storage such as [MinIO](https://min.io).

### Turso

<BlogImage
  src="/edge-turso/turso-logo.svg"
  alt="Turso Logo"
  width={100}
  height={100}
/>

[Turso](https://turso.tech/) is a platform that provides managed libSQL with seamless replication of data to multiple regions around the world via sqld. With Turso, you can spin up a database in any region it supports as the primary, and this will be the instance that will accept all writes. Based on that primary instance, you can spin up several replicas in any other region which will serve as read-only copies and will be synced with the primary over time, providing the natural eventual consistency of data.

As we mentioned above, from the other features we already have implemented in Flipt, eventual consistency has been a constant (caching, polling of data), and is acceptable for most use cases. There are also disproportionately more reads than writes of data for most Flipt use cases, so the “extra hop” as Turso describes it to get a write into the primary is acceptable. Knowing these two characteristics, it was a no-brainer for us to at least explore this route of providing capability of running Flipt over Turso.

<StarCTA />

### Flipt and libSQL

Flipt can already be run in a variety of storage modes with a [slew of databases](https://www.flipt.io/docs/configuration/storage#databases). We support the most popular RDBMS' such as: MySQL, PostgreSQL, CockroachDB, and last but not least SQLite. The already existing support for SQLite made it a relatively simple lift to support Flipt with libSQL. The functionality for this is included in [v1.29.0](https://github.com/flipt-io/flipt/releases/tag/v1.29.0) release! This release has support for not only running Flipt against libSQL in flat-file, embedded mode, but also in server mode with sqld over HTTP.

Although relatively painless, we did run into a couple of snags to get sqld working behind Flipt. The repository explains that currently libSQL clients are [somewhat limited](https://github.com/tursodatabase/libsql#getting-started) in terms of breadth of support. For instance, only the Rust, and Javascript clients are stable and supported while the rest of the languages are all “experimental”.

For us, the problem with the [libsql-client-go](https://github.com/yquansah/libsql-client-go) client was that the `main` branch did not have functionality for scanning boolean types nor recognition of the `TIMESTAMP` data type and conversion functions from that type to a common string. We [forked](https://github.com/yquansah/libsql-client-go) the repository and wrote patches for the missing functionality to get it working for the time being. We hope to contribute more to the project in the future if support for running Flipt with libSQL/Turso becomes more popular.

### Flipt ‘on the edge’ with Turso

Along with the functionality of the `v1.29.0` release also came an [example](https://github.com/flipt-io/flipt/tree/main/examples/database/libsql) of how to run Flipt against libSQL with replication provided by sqld. This example contains two containers of Flipt running against two containers of sqld, one primary and one replica instance.

You can access both Flipt instances and make edits via the UI, and witness the replication happening in real time. Although this works nice locally for a proof of concept, it does not show the true power of edge computing, so we opted to do an experiment with each employee at Flipt running in front of a Turso instance.

As you create database instances on Turso, the service will give you a URL that you can use to access the logical database. Turso defines a logical database as a collection of libSQL databases each with a schema and data and access to a primary instance (the primary instance itself is included in the logical grouping). The URL is then mapped to the closest instance to the user asking for the data upon query. Again, writes are routed to the primary instance by Turso, but reads can be served from any replica.

#### Experimenting

For our internal experimenti, we each ran Flipt locally, using the URL that Turso provides as [configuration](https://www.flipt.io/docs/configuration/storage#remote). We spun up a primary instance in IAD (Washington D.C, US), which was the closest on average for all 3 employees, and replicas in DFW (Dallas, Texas US) and LHR (London, England).

<BlogImage
  src="/edge-turso/turso-rw.png"
  alt="Turso Requests"
  width={1776}
  height={1759}
  caption="Turso Requests"
/>

On each read of the data we encountered correctness of routing, as each employee was routed to the nearest libSQL instance. For latency, we experimented with the default state of having a replica in each region closest to an employee and took some instances away over time to see if we could witness an increase in latency. Sure enough, as we took away the replica in DFW, the employee closest saw an increase in latency, and the same for the employee near London when we took away the replica in LHR.

<BlogImage
  src="/edge-turso/worldmap.png"
  alt="Worldmap of two of our Turso Instances"
  width={1105}
  height={426}
  caption="Worldmap of two of our Turso Instances"
/>

Given Turso's ability to replicate data to any region in the world in seconds, we could have spun up replicas in any region that Turso supports, and we would have seen similar results. This is a very powerful feature that we are excited to explore more in the future.

We're also looking forward to trying out Turso's [embedded replica feature](https://blog.turso.tech/introducing-embedded-replicas-deploy-turso-anywhere-2085aa0dc242) which would allow you to access a Turso/libSQL database via the native [libSQL C binding](https://github.com/tursodatabase/libsql/blob/main/bindings/go/libsql.go) instead of over HTTP with sqld and the [libsql-client-go](https://github.com/libsql/libsql-client-go) client. This would remove the additional latency of handling HTTP requests/responses and the marshalling/unmarshalling of JSON.

## Conclusion

Turso provides an impressive experience for managing distributed SQLite compatible databases and we are excited to see how it evolves in the future.

At Flipt, we've been actively exploring how to make feature flag evaluation as fast as possible. We are very excited about the many opportunities/technologies that can aid in that mission, including running Flipt with your own data on the edge. In the [previous blog post](/blog/flipt-as-a-sidecar), we explored running Flipt as a sidecar which can work well in a Kubernetes environment, and now we have explored running Flipt on top of a managed edge database provider without Kubernetes.

We're continuing to explore alternative ways to run Flipt on the edge, and we're excited to share more about that going forward.

If you are interested in Flipt, edge data/computing, or how to leverage the power of feature flags in your organization, please feel free to reach out to us via [GitHub](https://github.com/flipt-io/flipt), [Discord](https://flipt.io/discord), [X](https://twitter.com/flipt_io), or [Mastodon](https://hachyderm.io/@flipt).

Until next time!


Experimenting on the Edge


As organizations choose to integrate a feature flag solution within their stack, they should consider several core characteristics carefully. Feature flags can be used in various ways, and often guard critical paths of functionality that an organization wants to slowly rollout, or quickly turn off in case of a disaster. This naturally lends itself to an organization asking about the consistency and availability of the feature flag solution and how fast they could get values from feature flag evaluations to their clients that are leveraging it.

At Flipt, we have had several [feature requests](https://github.com/flipt-io/flipt/issues/2122) for client-side evaluation of flags. Currently, Flipt allows only server-side evaluation, with the option of enabling cache to reduce round trips to the database. This works fine for a good amount of use cases that our users, however, client-side evaluation is still a heavily requested feature.

For client-side evaluation to work, a special client would have to be written in each desired language to asynchronously pull flag state from a central server and store the flag state in memory. Evaluations for flags in this case would certainly be faster because it removes network hops to receive an evaluation value on each evaluation request. This could be a great solution for us, however writing a custom client in each language that users may request takes time away from building other necessary features for the core product.

Acknowledging the above facts, we still want to develop a solution that works for us as a company and our users. For these reasons, we have decided to explore using Flipt as a [sidecar](https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/ch02.html), a very popular design pattern used in distributed systems.

The remainder of this blog post will focus on what the architecture looks like in this new world and how consumers can leverage it.

### Architecture

Before talking about the overall sidecar architecture, however, it is important to note that today Flipt can be run in a variety of configurations for a storage backend. The traditional way to run Flipt is in front of an RDBMS (SQLite, MySQL, Postgres, etc.). By default, if you were to run Flipt locally it runs with a SQLite database 'next to' the Flipt binary. In addition to traditional RDBMS, Flipt can also be run in [file system (FS) mode](https://www.flipt.io/docs/configuration/storage#filesystem). In this mode, Flipt will periodically fetch from the target FS backend and build an in-memory snapshot of all of it's state. This process is asynchronous from any actual evaluation requests as requests are serviced on a live snapshot of state. The snapshot is only replaced with the new one once it has been built entirely.

It turns out that this architecture is perfect for doing evaluations in a sidecar as it removes one of our network hops from the evaluation call path. For reference, the different FS implementations we support are local file system, Git repositories (check out our Git blog post [here](https://www.flipt.io/blog/gitops-announcement)), and AWS S3 buckets thanks to an [awesome contributor](https://github.com/flipt-io/flipt/pull/1900).

<BlogImage
  src="/sidecar/s3-replication.png"
  alt="S3 Replication"
  width={1972}
  height={2248}
></BlogImage>

This same diagram can be found in our [labs repository](https://github.com/flipt-io/labs/tree/main/sidecar#object-store), where we also demonstrate how to run the proposed architecture in a minikube cluster.

In this diagram, you can see that there is a `flipt-master` process which will be the main source of truth for all feature flag data. This `flipt-master` process can be backed by any storage mechanism. The data from `flipt-master` will be replicated into an S3 bucket at a configurable interval via a Kubernetes cron job. Within the Flipt binary, there is an [`export`](https://www.flipt.io/docs/cli/commands/export) subcommand that reads flag state data out of `flipt-master` and writes that data into a file. That subcommand is what is used for the cron task, and the resulting data uploaded into the bucket.

Any sidecar that will be deployed alongside a service will then run in FS read-only mode with the S3 bucket as the storage mechanism. As the service makes evaluation calls it can source the data from either the [gRPC](https://www.flipt.io/docs/integration/grpc) or [REST](https://www.flipt.io/docs/integration/rest) API. These evaluation calls will be served from the sidecar, which will use data in memory from the S3 object store instead of having to get the data from a database over the network.

### Sample Results

If you run the `minikube` example within the labs repository, there is also another custom application that is written in Go and serves HTML content to the client.

The HTML page allows you to make evaluation calls by selecting either the `sidecar` or the `master` process.

As the instructions state in the [README](https://github.com/flipt-io/labs/tree/main/sidecar), you can choose from `flag_001` - `flag_010` to make evaluations as these flags exist in the initial seed data to `flipt-master`.

<BlogImage
  src="/sidecar/latencies.png"
  alt="Flipt Sample Evaluations"
  width={1527}
  height={708}
  caption="Load test results against `sample-app`"
></BlogImage>

The image above was generated doing a short load test using the [vegeta](https://github.com/tsenart/vegeta) tool. It made requests to the `sample-app`'s `/cli` endpoint at a rate of 15 req/s for 10 seconds, and dumped latency measurements to a csv file which was read and plotted using the [matplotlib](https://matplotlib.org/) + [pandas](https://pandas.pydata.org/) Python libraries. As you can see, evaluations against the sidecar were much faster (up to an order of magnitude) than evaluations against `flipt-master`. Keep in mind that this is just `minikube` as well, which is ultimately a VM running on your machine simulating a Kubernetes environment. In a real distributed environment, the difference in latency between the sidecar and `flipt-master` would likely be much more pronounced.

### Where to Go From Here?

At Flipt, we aim to make evaluations of your feature flags as fast as possible. We realize that adding an external dependency such as Flipt has a cost and we want to minimize it. Because of this, we are devising ways to decrease evaluation time for the source as much as possible, and the sidecar approach is one way to make this happen.

However, we are not done just yet. We're experimenting with additional integrations, architectures, and deployment patterns in the coming weeks to aide in operating Flipt in a multitude of real-world environments. Stay tuned and keep an eye on our [deployment docs](https://www.flipt.io/docs/operations/deployment) as well as this blog for updates.

If any of this interests you or you have any questions, please feel free to reach out to us via [GitHub](https://github.com/flipt-io/flipt), [Discord](https://www.flipt.io/discord), [X](https://x.com/flipt_io), or [Mastodon](https://hachyderm.io/@flipt).


Open Source Feature Management

Deploy With Confidence

Works with your existing stack

Features

GitOps Support

Context Targeting

Runs Anywhere

Secure

Fast

Easy Integration

GitOps for Feature Releases

Trusted by the world’s most innovative teams

Integrations

From the Blog

Feature Flags and OCI

Experimenting on the Edge

Flipt as a Sidecar

Open Source Feature Management

Deploy With Confidence

Works with your existing stack

Features

GitOps Support

Context Targeting

Runs Anywhere

Secure

Fast

Easy Integration

GitOps for Feature Releases

Trusted by the world’s most innovative teams

Integrations

Keep up with what we're building

From the Blog

Feature Flags and OCI

Experimenting on the Edge

Flipt as a Sidecar