Firebase Remote Config alternative for teams that want to run it themselves.
Nona solves the same broad runtime-config problem, but with a different product model: open source, Docker-first, plain HTTP access, and direct migration tooling instead of a closed hosted service.
High-level differences
Search intent
Why teams search for a Firebase Remote Config alternative
The search usually starts when runtime configuration has become important enough that the team wants to own it directly. Firebase Remote Config is convenient, especially for mobile teams already committed to Firebase, but it is still part of a closed, Google-operated platform. That can be the wrong fit for teams that need source visibility, infrastructure control, predictable self-hosting, or a config API that backend services can consume without adopting a mobile-first SDK model.
Nona is intentionally narrower. It stores typed parameters, separates them by project and environment, protects reads with scoped API keys, and serves values through HTTP and client libraries. Boolean values work as feature flags; text, number, and JSON values cover broader remote configuration. That makes it a practical alternative when the primary goal is runtime control, not experimentation analytics.
Use Nona if...
- You want one Docker-deployable service you can inspect and run yourself.
- You need feature flags and runtime values in the same small system.
- You want backend, mobile, and web apps to read config over plain HTTP.
- You are moving off Firebase Remote Config and want a CLI migration path.
Firebase is still better if...
- You want Google to operate the global service for you.
- Your app is already deeply coupled to Firebase products and SDKs.
- You need hosted experimentation, personalization, or advanced targeting around Remote Config.
Migration path from Firebase Remote Config
Nona includes CLI migration support so teams do not have to recreate every Firebase parameter by hand. The important part is not only copying values. It is checking how Firebase concepts map into the Nona model: projects, environments, content types, scopes, and API keys.
Run Nona locally or in a disposable environment and create the target project.
Export or connect the Firebase Remote Config source for a dry-run migration.
Map Firebase concepts into Nona projects, environments, scopes, and typed entries.
Import one environment first, then validate real application reads before cutover.
A practical migration shape
A typical Nona project after migration has one project, environment-specific values, boolean entries for feature flags, and text/number/json entries for broader remote config. Firebase conditions can be mapped during migration, but Nona is not trying to be a Firebase clone or a full experimentation platform.
project: mobile-app environments: staging, production Features:Checkout -> boolean App:BannerText -> text App:Settings -> json
Frequently asked questions
Is Nona a Firebase Remote Config clone?
No. Nona covers the same runtime configuration problem space, but it uses a smaller self-hosted model. It is not a hosted Google service, and it does not try to copy Firebase targeting, experimentation, or analytics workflows.
Can Nona replace Firebase Remote Config for mobile apps?
It can replace the core remote-config read path when your app needs environment-scoped values, feature toggles, kill switches, app copy, numeric limits, or JSON settings. If your app depends heavily on Firebase conditions, audiences, A/B testing, or Google-managed global delivery, evaluate those needs separately.
Do I need a Nona SDK to replace Firebase Remote Config?
No. Nona exposes a plain HTTP API, so any platform can read config with a GET request. Official clients exist where they help, including JavaScript, .NET, Android/Kotlin source, Swift package source, and OpenFeature providers.
How should I evaluate Nona as a Firebase Remote Config alternative?
Start with one real project, one staging or production-like environment, one boolean flag, and one non-boolean config value. Read both from an application path, verify fallback behavior, then test the migration workflow before moving a larger parameter set.
Try the replacement path
Validate one flag before moving everything.
Run the Docker image, create one environment, add one boolean flag and one non-boolean parameter, then read both over HTTP. If that works, the core model is already proven.