Local Development

Cloud Functions supports several methods of running your functions outside of the standard deployment environment. This is particularly useful for iterative development, and for situations where you want to test your function before deploying.

Use cases

The ability to run your functions without deploying them can simplify local testing, compliance with data locality restrictions, and multi-cloud deployments.

Local testing

Testing a function by re-deploying it after each change requires waiting for deployment each time. By contrast, testing your function directly in your development environment can shorten the iterative test cycle.

Note: for more information on testing strategies, see the Testing overview page.

Data locality restrictions

In some cases, regulations or policies may require data to be kept within a certain geographical, organizational, and/or network boundary that may not be accessible to Cloud Functions itself.

If a platform that complies with your data locality restrictions is compatible with one of Cloud Functions' abstraction layers, you can run your functions directly on that platform atop one of these layers.

Multi-cloud deployments

Multi-cloud function deployments are an established pattern to mitigate downtime risk in reliability-critical environments. Deploying functions to environments other than Cloud Functions itself reduces the risk of your application experiencing unplanned downtime.

Implementation Choices

Before you can set up your own function hosting environment, there are two key choices you will need to make:

• Which layer of abstraction you want to use.
• Which type of function you will be running.

Abstraction layers

Cloud Functions itself uses a multi-layer architecture, much of which has been open-sourced. These open-source components allow you to run code designed for Cloud Functions on other platforms.

Two primary open-source components of this architecture that can be run outside of Cloud Functions itself are the Functions Framework and Google Cloud CLI. This document explains the purpose of each of these layers and how they fit together.

The diagram below shows the typical layout of function deployments atop Cloud Functions, Cloud Run, and other container-based platforms:

Event types

Cloud Functions has two main types of functions:

• HTTP functions
• Event-driven functions

HTTP functions can be triggered by arbitrary HTTP requests such as webhooks, whereas event-driven functions receive events produced by other Google Cloud Platform products.

Choosing an abstraction layer

You can run functions locally using either Functions Framework or Functions Emulator.

Function Framework are open-source libraries used within Cloud Functions to unmarshal incoming HTTP requests into language-specific function invocations. You can use these to convert your function into a locally-runnable HTTP service.

Functions Emulator uses Cloud Native buildpacks and Docker to wrap HTTP services created by the Functions Framework and build them into runnable containers, which then run on Cloud Functions container-based architecture.

Both options have advantages and disadvantages:

• Functions Framework-based environments often have lower resource needs
• Functions Framework does not require underlying containerization software (such as Docker)
• Functions Framework-based environments require underlying language infrastructure (such as package managers and language runtimes)
• Functions Emulator mirrors production commands, such as calling and deploying.
• Functions Emulator offers high fidelity to how functions execute when deployed in production.

Run Functions Locally

Both Functions Framework and Functions Emulator work by forwarding HTTP requests to your function.

See Running Functions Framework for more information on how to run functions locally using Functions Framework.

See Run Functions using the Functions Emulator for more information on how to run functions locally using the Functions Emulator.