Google Cloud Functions
Single-purpose handlers wired directly to the events that should cause them to run.
Serverless compute
Chosen per project
Maintainable handover
Cloud Functions are at their best as the connective tissue of a system: a document lands in storage and a thumbnail appears; a record changes in Firestore and a notification goes out; a schedule fires and a report is generated. None of that justifies a running server.
They are also the natural backend for a Firebase application, where the triggers into the database and authentication are built in rather than assembled.
What we build with Cloud Functions
Firestore and Firebase Authentication triggers
Scheduled jobs replacing cron on a server
Webhook endpoints for third-party services
File processing when an object is written to storage
Where it fits — and where it does not
Good fit when
Event-driven glue between managed services
Firebase-backed mobile and web applications
Occasional or bursty work
Consider something else when
Sustained request volume — Cloud Run costs less at scale
Work needing a long execution time or large local scratch space
What tends to run as a function
Work that is real, short and event-shaped.
Storage events
Resize, scan or index a newly uploaded file.
Database triggers
React to a Firestore document changing.
Scheduled
Nightly summaries, reminders, cleanups.
HTTP webhooks
Payment and delivery callbacks.
How we work with Cloud Functions
One trigger, one purpose
Functions kept small so their failure modes are individually understandable.
Idempotent by design
Event delivery is at-least-once, so handlers are written to tolerate repeats.
Deployed from source control
Functions in the repository and released by pipeline, never edited in the console.
Alarms on failure
Error rate and execution count alerted on, including a function that stops firing.
Our typical Cloud Functions setup
| Concern | What we use |
|---|---|
| Runtimes | Node.js, Python, Go |
| Triggers | HTTP, Cloud Storage, Firestore, Pub/Sub, Cloud Scheduler |
| Delivery | At-least-once, with idempotent handlers |
| Secrets | Secret Manager, injected at runtime |
| Monitoring | Cloud Logging and alerting on errors and silence |
Frequently asked questions
Functions for event-shaped work and Firebase triggers; Cloud Run once you have a real application, sustained traffic or a need to control the runtime. Many systems use both.
Yes, over a serverless VPC connector, so the database does not need a public endpoint.
That is the failure worth alerting on specifically — an alert on zero executions in a window, not just on errors.
Services built with Cloud Functions
Cloud Solutions
Hosting designed around what your application actually needs, with the monitoring and backups that make it safe to rely on.
Mobile App Development
Apps built to be used daily — fast to open, sensible offline and maintainable once they are in the stores.
API Development
The interfaces that let your systems talk to each other, and let partners build on top of what you have.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.