Klor and Firebase Remote Config

It is free at any volume most products will reach, it is already in the project if you use anything else in Firebase, and the console is familiar to people who are not engineers. For changing a string or a number in a shipped app, it works.

If that is your whole problem, and you are already on Firebase, there is no good reason to move. The rest of this page is about the cases where that stops being true.

• Fetch throttling. The client SDK limits how often it will fetch, and in development the workaround is to lower minimumFetchIntervalMillis and remember to put it back. A value you changed can take hours to reach a device.
• No force update. Remote Config can carry a version number, but comparing it, deciding forced against optional, and handling a build that has to be pulled mid incident is code you write and maintain yourself.
• Untyped values. Everything arrives as a string and you cast it. A number that is accidentally a string fails at the call site, on a device, after release.
• No publish history. There are no immutable versions to roll back to, so undoing a change means remembering what it was.
• User context leaves the device. Targeting is evaluated by Google against the identifiers you send.

Update gating is part of the product. A minimum supported version, a latest version, and a list of specific builds to block are configuration, not code you write. Klor returns a verdict and the copy to show; you render your own prompt.

Values are typed, and the type is enforced where it is known. A number flag cannot be published carrying a string, because the server checks against the flag's declared type before the payload is compiled.

Publishing is explicit and reversible. Editing stages a change; publishing compiles an immutable snapshot. Rolling back republishes an old snapshot under a new number, so history moves forward and is never rewritten.

Evaluation happens on the device. Klor sends your app the ruleset, not an answer, so user ids, countries, app versions and any custom attributes you target on are never transmitted to us. You can verify that by watching your own network traffic.

• Force update and blocked builds: Klor yes, Firebase build it yourself.
• Typed values: Klor bool, string, number and JSON with server-side checking; Firebase strings you cast.
• Rollback: Klor immutable snapshots; Firebase none.
• Where targeting is evaluated: Klor on the device; Firebase on Google servers.
• Refresh control: Klor an interval you choose plus on foreground, with ETags; Firebase a throttled fetch.
• Price: Klor free while it is young; Firebase free.
• Maturity: Firebase has years and enormous scale behind it. Klor does not. That is a real difference and it should count.

There is a step by step migration guide that never needs a cutover: both services run side by side for one release, and Firebase is removed only after Klor has proved itself in production. The short version follows.

Both are a key and a typed value, so the mapping is direct. Create a flag per Remote Config parameter with the type it should have had, then read it with a fallback that matches what your Firebase default was.

// Firebase
const raw = remoteConfig().getValue('max_items').asString()
const maxItems = Number(raw) || 25

// Klor
const maxItems = useFlag('max_items', 25)

The fallback argument is not optional and is not decoration: it is what the app serves before the first fetch, on a dead network, and if the key does not exist. Choose the value you would want if Klor were not installed at all.

Run both for a release if you want to. Klor does not need to own the value to be read from, and nothing stops you writing the Firebase value into a Klor flag while you migrate.

If you are deep in the Firebase ecosystem and Remote Config is one of several products you use together, if your config is a handful of strings that rarely change, or if you need the operational track record of a service that has been running for a decade, stay. Klor is newer, smaller, and honest about both.

The case for moving is specific: you are on mobile, you need force update, you want to undo a change without remembering what it was, and you would rather your users' data stayed on their devices. pnpm add @klor/react and the quickstart takes a few minutes.