The Node.js Runtime

Cloud Functions supports the following Node.js runtimes:

  • Node.js 16 (recommended)
  • Node.js 14
  • Node.js 12
  • Node.js 10

For instructions on how to run your Node.js function locally, see Running Functions with Function Frameworks.

To get started with Node.js on Cloud Functions, see the Quickstart.

Selecting the runtime

You can select the desired Node.js runtime for your function during deployment.

gcloud

If you are using the Google Cloud CLI, you can specify the runtime by using the --runtime parameter. For example:

gcloud functions deploy NAME --runtime nodejs16 --trigger-http

For more arguments that you can specify when you are deploying, see Deploy using the gcloud tool.

Console

If you are using the Cloud console, you can select the runtime when you create and deploy a function. See the Cloud console quickstart for detailed instructions.

Execution environment

The execution environment includes the runtime, the operating system, packages, and a library that invokes your function.

The Node.js runtimes use an execution environment based on Ubuntu 18.04. See Cloud Functions Execution Environment for more information.

The library that invokes your function is the Node Functions Framework.

Source code structure

In order for Cloud Functions to find your function's definition, each runtime has certain structuring requirements for your source code. See Writing Cloud Functions for more information.

Specifying dependencies

You can specify dependencies for your functions by listing them in a package.json file. For more information, see Specifying dependencies in Node.js.

Environment variables

The Node.js 10+ runtimes automatically set fewer environment variables than previous runtimes supported by Cloud Functions, and for Node.js 12+ functions with memory limits greater than 2GiB, users need to configure NODE_OPTIONS to have max_old_space_size. For details, see Using Environment Variables.

Signalling function termination

When working with asynchronous tasks that involve callbacks or Promise objects, you must explicitly inform the runtime that your function has finished executing these tasks. You can do this in several different ways, as shown in the samples below.

Background functions

Node.js

functions/concepts/termination.js 
// Await-ing promises within functions is OK if you don't return anything
await Promise.resolve();

// These will cause background tasks to stop executing immediately
return 1; // OK: returning a value
return await Promise.resolve(); // WRONG: returning the result of a promise
return await Promise.reject(); // WRONG: same behavior as resolved promises

// These will wait until the related background task finishes
return Promise.resolve(); // OK: returning the promise itself
return Promise.reject(); // OK: same behavior as to-be-resolved promises

HTTP functions

Node.js

functions/concepts/termination.js 
// OK: await-ing a Promise before sending an HTTP response
await Promise.resolve();

// WRONG: HTTP functions should send an
// HTTP response instead of returning.
return Promise.resolve();

// HTTP functions should signal termination by returning an HTTP response.
// This should not be done until all background tasks are complete.
res.send(200);
res.end();

// WRONG: this may not execute since an
// HTTP response has already been sent.
return Promise.resolve();

Using middleware to handle HTTP requests

Node.js HTTP Cloud Functions provide request and response objects that are compatible with ExpressJS to make consuming HTTP requests simple. Cloud Functions automatically reads the request body, so you will always receive the body of a request independent of the content type. This means that HTTP requests should be considered to have been fully read by the time your code is executed. The nesting of ExpressJS apps should be used with this caveat—specifically, middleware that expects the body of a request to be unread might not behave as expected.

Using ES Modules

ECMAScript modules (ES modules or ESM) are a TC39 standard, unflagged feature in Node version 14+ for loading JavaScript modules. Unlike CommonJS, ESM provides an asynchronous API for loading modules. It also provides a popular syntax improvement via import and export statements that can be used within a Cloud Function (instead of require statements).

To use ESM within a Cloud Function, you must declare "type": "module" within your package.json.

{
  ...
  "type": "module",
  ...
}

Then you can use import and export statements.