Google Cloud Functions
We build Google Cloud Functions for event-driven workloads: HTTP APIs, Pub/Sub consumers, Cloud Storage triggers, and Firestore event handlers. Cloud Functions (2nd gen) runs on Cloud Run under the hood, which gives it longer timeouts, higher concurrency, and more predictable cold start behavior than 1st gen.
Capabilities
What we build with Cloud Functions
REST · Webhooks
HTTP API Endpoints
Lightweight HTTP APIs and webhook receivers built on Cloud Functions with authentication via Google Cloud IAM or Firebase Auth, routing, and JSON request/response handling.
Async messaging
Pub/Sub Event Consumers
Cloud Functions triggered by Pub/Sub messages for processing events asynchronously. Dead-letter topic configuration, message acknowledgment, and retry policies.
File processing
Cloud Storage Triggers
Functions that fire when files are uploaded, modified, or deleted in Cloud Storage buckets — for image processing, document transformation, data ingestion, and virus scanning.
Database triggers
Firestore Event Handlers
Functions that respond to Firestore document creates, updates, and deletes for maintaining derived data, sending notifications, and enforcing business rules close to the data.
Cloud Scheduler · Cron
Scheduled Jobs
Functions triggered on a schedule by Cloud Scheduler for periodic data processing, report generation, and maintenance tasks that do not justify a persistent process.
Firebase · GCP
Firebase Backend Functions
Cloud Functions used as the backend layer for Firebase applications, handling authentication events, database triggers, and HTTP callable functions from Firebase client SDKs.
Our approach
2nd gen over 1st gen
Cloud Functions 2nd gen runs on Cloud Run and brings minimum instance configuration (to eliminate cold starts on critical paths), longer 60-minute timeouts, higher concurrency per instance, and traffic splitting. We use 2nd gen for new functions unless there is a specific reason to stay on 1st gen.
Pub/Sub for reliable async processing
HTTP-triggered functions are synchronous and fire-and-forget from the caller's perspective. For workloads where reliability matters — where losing a message is unacceptable — Pub/Sub provides at-least-once delivery with acknowledgment and dead-letter queues for messages that fail processing after retries.
Secret Manager, not environment variables
Credentials and API keys belong in Google Cloud Secret Manager, not in environment variables baked into the function configuration. We reference secrets at runtime via the Secret Manager API so that values are not visible in the console and rotation does not require redeployment.
Deployed with Terraform
Cloud Functions definitions, IAM bindings, Pub/Sub topic subscriptions, and Cloud Scheduler jobs are all defined as infrastructure code with Terraform. This makes the function's full configuration reproducible, reviewable, and version-controlled alongside the function code.
All engineering work is done by US-based engineers. We do not offshore any development or architecture work.
Part of our serverless practice
FAQ
Common questions
Virginia · United States
Building on Google Cloud Functions?
Reach out and we will discuss the trigger model, integration requirements, and deployment approach before any work begins.