What Is Cloud Functions? Google Cloud Functions Explained

Cloud Functions in simple terms

Think of Cloud Functions like a light switch that triggers an action. When something flips the switch — an HTTP request arrives, a file lands in a storage bucket, a message appears in a queue — your function runs, does its work, and stops. You do not need to think about the wiring behind the wall.

The key difference from a regular web server: nothing runs between events. There is no always-on process waiting for work. When an event arrives, GCP starts your function (or reuses a warm instance if one is available), runs your code, and returns the result. When no events arrive, you pay nothing.

This is “serverless” in the most direct sense. The servers exist, but you never see them. Google manages them. Your job is to write the code that responds to the event.

What is Cloud Functions?

Cloud Functions is a serverless, event-driven compute service on Google Cloud. You deploy individual functions — single-purpose pieces of code — that run in response to triggers. You do not write a full application or web server. You write a handler for one specific task: process this upload, respond to this HTTP request, handle this Pub/Sub message.

Cloud Functions supports multiple runtimes including Python, Node.js, Go, Java, Ruby, PHP, and .NET. You deploy from source code directly with no Dockerfile required. GCP builds and manages the container for you.

Under the hood, Cloud Functions 2nd gen is built on Cloud Run. The infrastructure model is the same, but Cloud Functions provides a higher level of abstraction: you think about functions, not services or containers. When you need more control — custom runtimes, multiple routes, system-level dependencies — Cloud Run gives you that at the cost of managing a Dockerfile.

• Deployment model: deploy from source code; no container registry needed
• Scaling: scales to zero at no cost; scales up automatically with load
• Billing: billed per invocation and per CPU/memory during execution
• Infrastructure: Google manages patching, scaling, and runtime updates
• Supported runtimes: Python, Node.js, Go, Java, Ruby, PHP, .NET

How Cloud Functions works

Every Cloud Function invocation follows the same basic flow:

1. An event happens. An HTTP request arrives, a Pub/Sub message is published, a file is uploaded to Cloud Storage, or another trigger fires.
2. GCP routes the event. Cloud Functions (via Eventarc for 2nd gen) receives the event and identifies which function should handle it.
3. An instance starts or is reused. If a warm instance from a previous invocation is available, GCP reuses it. If not, it starts a new one. That startup delay is called a cold start and typically adds a few hundred milliseconds to a couple of seconds.
4. Your code runs. The function handler executes with the event data passed as input.
5. The result is returned or work is performed. HTTP functions return a response. Background functions (Pub/Sub, Storage) perform side effects like writing to a database or calling an external API.

If your function throws an unhandled exception, the invocation is marked as failed. For Pub/Sub and other background triggers, GCP retries the event automatically. For HTTP triggers, the error is returned to the caller.

Cloud Functions 1st gen vs 2nd gen

Always use 2nd gen for new deployments. It runs on Cloud Run under the hood, has significantly higher limits, and supports concurrency, meaning one instance can handle multiple requests simultaneously instead of spinning up a new instance for every single request.

When to use Cloud Functions

Cloud Functions works best for focused, event-driven tasks where you want minimal deployment overhead. Common good fits:

• Webhooks — receive HTTP callbacks from Stripe, GitHub, or Slack and perform an action in response.
• Lightweight APIs — a small number of HTTP endpoints that do simple data lookups or transformations.
• Background processing from Pub/Sub — consume messages from a topic and process them asynchronously: send emails, update records, trigger downstream workflows.
• File processing on upload — resize images, validate CSVs, or extract data from files as soon as they land in Cloud Storage.
• Simple automation — run a script on a schedule via Cloud Scheduler and an HTTP trigger, or react to a resource change in Cloud Audit Logs.
• Event-driven integrations — a Firestore document change triggers a notification, a BigQuery job completion triggers a downstream report.

When Cloud Functions is not the best choice

Cloud Functions has real constraints. These situations call for a different tool:

• Multi-route HTTP APIs. If you are building an API with many endpoints, routing middleware, or authentication layers, use Cloud Run instead. Cloud Functions is optimised for a single handler, not a full API server.

• Custom runtimes or system dependencies. Cloud Functions supports a fixed set of runtimes. If you need a runtime version not on the supported list, a compiled binary, or low-level system access, Cloud Run lets you control the container entirely.

• Long-running or complex workloads. Cloud Functions 2nd gen has a maximum timeout of 60 minutes. For batch jobs or multi-step workflows that run longer, use Cloud Run Jobs, Cloud Batch, or Cloud Workflows.

• Persistent background workers. Cloud Functions is not designed to run indefinitely. A process that polls a queue or runs a continuous loop belongs on a VM or GKE.

• Full container control. If you want to own the Dockerfile, set infrastructure-level configuration, or use traffic splitting across revisions more granularly, use Cloud Run directly.

Cloud Functions vs Cloud Run

This is the most common question beginners have. Both are serverless, both scale to zero, and Cloud Functions 2nd gen is built on Cloud Run under the hood. The difference is in abstraction level and deployment model.

For more on this decision, see:

• Cloud Run vs Cloud Functions — full comparison with decision guidance
• Cloud Run vs Compute Engine — when to use containers vs VMs
• Choosing Between Cloud Run, GKE, and Compute Engine — opinionated guide to GCP compute options

Common Cloud Functions trigger types

A trigger is the event that causes your function to run. Cloud Functions 2nd gen supports all of the following:

• HTTP — your function is exposed as an HTTPS endpoint. Any system that can make an HTTP request can call it: a browser, a third-party webhook, a cron job via Cloud Scheduler. This is the most flexible trigger type.

• Pub/Sub — your function runs whenever a message is published to a specific topic. Used for decoupled asynchronous processing: one service publishes events, your function consumes them.

• Cloud Storage — your function runs when a file is uploaded, deleted, archived, or modified in a bucket. Used for file processing pipelines.

• Eventarc — the underlying event routing layer for 2nd gen. Supports 90+ GCP services including Cloud Audit Logs and BigQuery. When you set —trigger-event-filters in a 2nd gen deployment, GCP creates an Eventarc trigger under the hood.

• Firestore / Firebase — functions can react to document creates, updates, and deletes in Firestore. Commonly used in Firebase apps to run server-side logic in response to database changes.

See Event-Driven Patterns with Cloud Functions for deeper coverage of each trigger type, chaining functions together with Pub/Sub, and idempotency requirements.

HTTP-triggered functions

An HTTP function is exposed as an HTTPS endpoint. The example below returns a greeting based on a query parameter. Add —allow-unauthenticated to make it publicly accessible, or omit that flag to require a valid Google identity token.

# main.py
import functions_framework

@functions_framework.http
def hello(request):
    name = request.args.get("name", "World")
    return f"Hello, {name}!", 200

# Deploy an HTTP function (2nd gen)
gcloud functions deploy hello \
  --gen2 \
  --runtime=python312 \
  --region=us-central1 \
  --source=. \
  --entry-point=hello \
  --trigger-http \
  --allow-unauthenticated

# Get the function URL
gcloud functions describe hello \
  --gen2 \
  --region=us-central1 \
  --format="value(serviceConfig.uri)"

Pub/Sub-triggered functions

Pub/Sub triggers run your function when a message is published to a topic. Write Pub/Sub functions to be idempotent. If the function throws an exception, Pub/Sub retries delivery and the same message may be processed more than once.

# main.py
import base64
import functions_framework

@functions_framework.cloud_event
def process_message(cloud_event):
    data = base64.b64decode(cloud_event.data["message"]["data"]).decode()
    print(f"Received message: {data}")
    # Write to a database or call an API here
    # If this raises an exception, Pub/Sub retries — make it safe to run twice

# Deploy a Pub/Sub triggered function
gcloud functions deploy process-message \
  --gen2 \
  --runtime=python312 \
  --region=us-central1 \
  --source=. \
  --entry-point=process_message \
  --trigger-topic=my-topic

Cloud Storage-triggered functions

Storage triggers fire when a file is uploaded, deleted, or modified in a bucket. The google.cloud.storage.object.v1.finalized event fires when an upload completes. Use it to process files as they arrive.

# main.py — triggered when a file upload completes
import functions_framework
from google.cloud import storage

@functions_framework.cloud_event
def process_upload(cloud_event):
    data = cloud_event.data
    bucket = data["bucket"]
    name = data["name"]
    print(f"Processing: gs://{bucket}/{name}")
    client = storage.Client()
    blob = client.bucket(bucket).blob(name)
    content = blob.download_as_text()
    # Process content and write output to a different bucket

# Deploy with a Cloud Storage trigger
gcloud functions deploy process-upload \
  --gen2 \
  --runtime=python312 \
  --region=us-central1 \
  --source=. \
  --entry-point=process_upload \
  --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" \
  --trigger-event-filters="bucket=my-uploads-bucket" \
  --service-account=process-fn-sa@PROJECT_ID.iam.gserviceaccount.com

Environment variables and secrets

Use plain environment variables for non-sensitive configuration. Use Secret Manager for any value you would not want in source code: database passwords, API keys, tokens. Never pass secrets as plain environment variable values that end up in deployment configs or version control.

# Non-sensitive config via environment variables
gcloud functions deploy hello \
  --gen2 \
  --runtime=python312 \
  --region=us-central1 \
  --source=. \
  --entry-point=hello \
  --trigger-http \
  --set-env-vars=APP_ENV=production,LOG_LEVEL=info

# Sensitive values via Secret Manager
gcloud functions deploy hello \
  --gen2 \
  --runtime=python312 \
  --region=us-central1 \
  --source=. \
  --entry-point=hello \
  --trigger-http \
  --set-secrets=DB_PASSWORD=db-password:latest \
  --service-account=hello-fn-sa@PROJECT_ID.iam.gserviceaccount.com

Testing functions locally

The Functions Framework lets you run your function locally before deploying. A full deploy-to-GCP cycle takes a minute or more. Local testing catches bugs faster and costs nothing. Install it once, then run your function against it as many times as you need.

# Install the Functions Framework
pip install functions-framework

# Run locally on port 8080
functions-framework --target=hello --port=8080

# Test in another terminal
curl "http://localhost:8080?name=World"

# Test a Pub/Sub-triggered function with a CloudEvent payload
curl -X POST http://localhost:8080 \
  -H "Content-Type: application/json" \
  -H "ce-specversion: 1.0" \
  -H "ce-type: google.cloud.pubsub.topic.v1.messagePublished" \
  -H "ce-source: //pubsub.googleapis.com/projects/my-project/topics/my-topic" \
  -H "ce-id: 1234" \
  -d '{"message": {"data": "aGVsbG8gd29ybGQ="}}'