Support for Remote Config #323

Is your feature request related to a problem? Please describe.

The support matrix lists Remote Config as 🔴. That's the one gap that currently forces us to keep part of our backend in TypeScript.

We run a production Dart Cloud Functions codebase (firebase_functions 0.6.0, firebase_admin_sdk 0.5.3, google_cloud_firestore 0.5.2) alongside a legacy Node codebase, and we've been migrating onCall endpoints to Dart as capabilities land. Our internal rule is "write it in Dart unless something forces JS".

Every new endpoint we ship carries an emergency kill switch driven by server-side Remote Config, so we can disable a feature from the console without a redeploy:

const template = await getRemoteConfig().getServerTemplate({
  defaultConfig: {[key]: false},
});
return template.evaluate().getBoolean(key);

There is no Dart equivalent — not in firebase_admin_sdk (no remote_config library), not in firebase_functions (firebase.remoteConfig is the onConfigUpdated trigger, not a template reader), and not in package:googleapis (firebaseremoteconfig isn't in the generated set — I checked config.yaml on google/googleapis.dart). So a whole endpoint that otherwise only needs Firestore admin + package:http + secrets has to stay in TypeScript purely for three lines of kill switch.

Describe the solution you'd like

A remote_config module in firebase_admin_sdk, at minimum the server-side read path (getServerTemplate / evaluate) — that's what backend feature flags need. Template management (getTemplate / publishTemplate / validateTemplate / rollback / listVersions) would be a bonus.

Describe alternatives you've considered

Calling the Remote Config REST API by hand from Dart, with an ADC token from the metadata server. It works, but re-implementing the server-template fetch and the condition/percent-rollout evaluation logic in every app is exactly what an Admin SDK is supposed to prevent — and getting percent-rollout bucketing subtly wrong is a silent, hard-to-notice bug.

Additional context

#249 already implements this, including server-side evaluation with a condition evaluator, ~1.8k lines of tests, docs and an example. It's been open since 2026-04-26 with no review.

The stated blocker there was that Firebase services route through the googleapis generated package. The contributor answered that in the thread: firebaseremoteconfig was dropped from googleapis between 13.2.0 and 14.0.0 and isn't in current versions, and four of the five admin endpoints need ETag / If-Match request and response headers, which the generated clients don't surface — so raw REST is required regardless of whether firebaseremoteconfig comes back. They offered three concrete paths and asked which one the project prefers; there's been no reply since 2026-04-29.

Filing this so there's a trackable issue for the capability itself (there is currently none — #249 is the only reference to Remote Config in the repo, and a PR isn't something users can find or subscribe to easily). Happy to test a branch against a real project if that helps.