Cloud Functions for Firebase samples: a trigger-by-trigger reference

One minimal program per trigger type

The repository is a collection of samples rather than a library, and the README organises it around Cloud Functions trigger types. Each quickstart is a complete small program with one idea in it. The Firestore uppercaser transforms message text to uppercase on write. The Realtime Database uppercaser does the same thing against the other database. The HTTPS time server returns the current server time and accepts a date formatting parameter.

That repetition is deliberate and is the design of the repository. When you already know what a Firestore trigger looks like in Node, the thing you actually need is the Realtime Database equivalent, not another explanation of triggers. Two directories handle the runtime split: `Node-1st-gen/` and `Node/`, with `Python/` alongside them and a `Dart/` directory that appears in the README for callable functions, streaming responses and the HTTPS time server.

The samples are available for Node in both first and second generation and for Python in second generation. Generation matters more than the language does, because the two use different APIs for exporting functions and different configuration, so most samples exist twice.

The trigger catalogue is the actual index

Reading the quickstart list as a feature matrix tells you what Cloud Functions for Firebase can hang code off. Beyond the database triggers there is a Cloud Storage thumbnail generator that fires on image upload, a PubSub hello world that logs the payload, and a Test Lab sample that logs when a device matrix finishes running.

Two entries are less obvious and more useful. Auth blocking functions validate a user's email before sign-in is allowed and check a banned-user list kept in Firestore, which is the mechanism for gating access without a client-side check anyone can bypass. Firebase Alerts can trigger a function, and the sample forwards crash report information to a Discord channel, so a Firebase-side problem can reach a chat room your team already watches.

There is also a sample for custom events, which covers triggering from an extension. That one is marked as unsupported on Node 1st gen, as are the Firebase Alerts sample and its Python counterpart being listed separately, so if you are still on the first generation runtime you are working from a smaller set.

Quickstarts, boilerplates and unit testing

The repository distinguishes quickstarts from development boilerplates, and the difference is instructive. Quickstarts are minimal and demonstrate one mechanism. Boilerplates are closer to what a real application looks like: the Handlebars sample serves server-side rendered HTML pages with user sessions, keeping the Firebase ID token in a `__session` cookie so page requests are authenticated. The Image Maker sample generates custom images such as sparkline or sphere charts through a function plus Hosting.

Testing gets its own section, with two frameworks and two language flavours: Jest for Node, Jest with TypeScript, and Mocha. Seeing a function tested both ways in one repository is useful when you are deciding which runner to standardise on, and the TypeScript variant answers a question most teams hit a month in, which is how to get types onto an existing JavaScript codebase without rewriting it.

A large share of the repository is image processing samples, gathered into their own section. Upload-triggered thumbnails and conversions are common enough that they are close to mandatory reading for anyone building a media upload flow on Firebase, and having both the quickstart and the longer sample side by side saves an afternoon.

Monorepo plumbing and what it implies

The repository is a pnpm workspace, and the root `package.json` shows the shape. Scripts, development dependencies and the engine pin all sit in the same small block:

"bootstrap": "pnpm --recursive install",
"eslint": "^8.57.1",
"pnpm": "^10.28.2",
"typescript": "^5.0.4"
"node": "22"

The install script runs recursively across every workspace package, which means one clone gets you all of them, and the lint, test and compile scripts are the same recursive call with a `--filter` on `./Node/**` or `./Node-1st-gen/**`. Running checks for one generation is a flag rather than a checkout dance. The dependency list stays deliberately thin, since each sample carries its own Firebase packages. Two compat packages, `@firebase/app-compat` and `@firebase/app-types`, are listed under `peerDependencyRules.ignoreMissing`, which tells you the workspace tolerates samples that do not install cleanly rather than failing the whole tree.

The rest of the tree is documentation and governance: `CONTRIBUTING.md`, `community.md`, an `.opensource/` directory and a `LICENSE`. There are no tagged releases, which is correct for this kind of repository, since nothing here is published to a registry and each sample is deployed from its own directory.

Billing, Python preview status and how much to trust it

Two constraints in the README are worth reading before you clone anything. The first appears under Prerequisites: all samples require the Blaze pay-as-you-go billing plan to deploy. Free-tier Spark projects cannot deploy these, which surprises people who assume a sample is free to run.

The second is the Python status. The README states plainly that Python support is a public preview, that functionality might change in backward-incompatible ways, and that a preview release is not subject to any SLA or deprecation policy and may receive limited or no support. The Node samples carry no such caveat. If you are choosing a runtime for something that has to keep working, that asymmetry is the deciding fact.

The repository itself is unambiguously alive. It is not archived, the last push was 2026-09-21, and at 12213 stars with 3830 forks it is one of the most-visited repositories in the Firebase organisation. The 157 open issues are mostly the normal traffic of a repository this size where every user files against the samples rather than against a single package.

Editorial conclusion

The useful thing about this repository is not any individual sample but the shape of it: one minimal program per trigger, then larger walkthroughs, so you can find the shortest working example of a mechanism and go deeper only if you need to. The trigger coverage is the real catalogue, spanning Firestore, Realtime Database, Storage, Auth including blocking functions, PubSub, HTTPS, callable functions with streaming, Hosting rewrites, Test Lab matrices, Firebase Alerts and custom events from extensions. Two caveats belong next to that: Python is still a public preview with no SLA, and every sample needs the Blaze pay-as-you-go plan to deploy.

Frequently asked questions

Official sources

1. firebase/functions-samples on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README