Specify versions of Node.js
The buildpacks project provides support for the Current and Active LTS releases of Node.js. Older releases of Node.js are available but might not be actively maintained by the project.
Use package.json
You can specify the Node.js version of your application during deployment
by configuring the engines.node field in the package.json file. To configure
the buildpack to use the latest version of Node.js when deploying your app, add the following values in your package.json:
"engines": {
"node": "24.x.x"
}
Use GOOGLE_NODEJS_VERSION
You can also specify the Node.js version using the GOOGLE_NODEJS_VERSION
environment variable.
If both configurations are set, the GOOGLE_NODEJS_VERSION value takes precedence
over the engines.node property. If you don't provide a version, then the
buildpack uses the most recent LTS version of Node.js.
To configure the buildpack to use Node.js 24 when deploying your app, run the following command:
pack build --builder=gcr.io/buildpacks/builder \
sample-functions-framework-node \
--env GOOGLE_NODEJS_VERSION=24.x.x
You can also use a project.toml project descriptor to encode
the environment variable alongside your project files. See instructions on
building the application with environment variables.
Tips
engines.nodefield can take a semver constraint. The specific library we use for the Node.js buildpacks is Masterminds/semver- Avoid using greater than (>) specifiers in the
engines.nodefield. - When deploying the application into App Engine standard environment, the
engines.nodeproperty should be compatible with the runtime specified inapp.yaml. For more information about theengines.nodeconfiguration option inpackage.jsonfile, see the official NPM documentation for the engines topic. - When deploying a function onto Cloud Run functions, the
engines.nodeproperty should be compatible with the runtime used to deploy your function
Install dependencies
NPM is the default package manager for all versions of Node.js. The following section includes the compatible dependencies for your Node.js applications.
NPM package manager
- NPM is the default package manager.
- Whenever possible, use
package-lock.jsonto improve cache performance. - By default only production dependencies are installed.
- Specify the npm version using the
engines.npmfield in yourpackage.jsonfile. For more information, see the NPM documentation.
Yarn package manager
- buildpack uses Yarn when you include the
yarn.lockfile in your project. - Specify the yarn version in the
engines.yarnfield of yourpackage.jsonfile. - buildpack supports Yarn2 PnP mode if your project includes a
.yarn/cachefolder.
Pnpm package manager
- buildpack uses Pnpm when you include the
pnpm-lock.yamlfile in your project. - Specify pnpm version in the
engines.pnpmfield of yourpackage.jsonfile. - For a working example, see sample-node-pnpm.
Bun package manager
The Node.js buildpack supports the Bun package manager,
google.nodejs.bun buildpack for installing dependencies. To use the Bun package
manager, follow these steps:
- Create a
bun.lockorbun.lockbfile in the root directory for automatic detection. - Alternatively, you can also explicitly set the
GOOGLE_PACKAGE_MANAGERenvironment variable tobun. With this method, you don't need to create and maintain lockfiles. - Your project must include a
package.jsonfile. You can specify a Bun version in theengines.bunorpackageManagerfield of yourpackage.jsonfile. If no version is specified, the buildpack defaults to the latest stable release.
For more information on deploying to Cloud Run, see Specify dependencies in Node.js.
For more information about the Bun package manager, see the Bun documentation.
Package manager precedence
The Node.js buildpack determines the package manager based on the configuration in the following order of precedence:
The
GOOGLE_PACKAGE_MANAGERalways takes precedence. This environment variable only supportsbun(preview).The buildpack checks for lockfiles in the following order:
- Yarn -
yarn.lock - pnpm -
pnpm-lock.yaml - Bun -
bun.lockorbun.lockb - NPM -
package-lock.json
- Yarn -
If you don't set the environment variable or use a lockfile, the buildpack defaults to using NPM.
Private modules
Use a private npm module by providing settings for authenticating with
the registry in a .npmrc file in the function's directory. If you're using
Yarn version 2 or later as your package manager, this file is named
.yarnrc.yml.
Private modules from Artifact Registry
An Artifact Registry Node.js package repository
can host private modules for your function. When you deploy a Buildpacks
function, the build process automatically generates Artifact Registry credentials
for the Cloud Build service account.
You only need to list the Artifact Registry repository in your .npmrc file
when using NPM or Yarn version 1. For example, when using NPM or Yarn version 1:
@SCOPE:registry=https://REGION_ID-npm.pkg.dev/PROJECT_ID/REPOSITORY_NAME
//REGION_ID-npm.pkg.dev/PROJECT_ID/REPOSITORY_NAME:always-auth=true
If you're using Yarn version 2 or later, you only need to list the Artifact Registry
repository in your .yarnrc.yml file without additional credentials.
For example:
npmScopes:
SCOPE:
npmRegistryServer: https://REGION_ID-npm.pkg.dev/PROJECT_ID/REPOSITORY_NAME
npmAlwaysAuth: true
Private modules from other repositories
The npm documentation explains how to create custom read-only
access tokens. We discourage using the .npmrc file created in the home
directory because it contains a read-write token. Write permissions are not
required during deployment, and could pose a security risk.
Don't include the .npmrc file if you're not using private repositories,
as it can increase the deployment time for your functions.
File format
If you're using an .npmrc file to set a custom auth token, include the following:
//REGISTRY_DOMAIN/:_authToken=AUTH_TOKEN
Replace:
- REGISTRY_DOMAIN: the domain name of your private
npm registry. For example if your repository host is
npmjs.org, set this field toregistry.npmjs.org. AUTH_TOKEN: the authorization token for your npm registry. This can either be the literal text value of the token or the text string
${NPM_TOKEN}, which thenpmcommand replaces with the actual token value from the environment.You can set the
$NPM_TOKENenvironment variable with the--set-build-env-varsargument to yourgcloud functions deploycommand. See the NPM tutorial on private modules for more details of the NPM auth token.
Execute custom build steps during deployment
By default, npm run build is run if a script is specified in your
package.json file. However, you can instead specify custom build steps to
override the default behavior and run only the scripts that you want
during the build. You can control the build steps by using either the
GOOGLE_NODE_RUN_SCRIPTS environment variable or gcp-build in your
package.json file.
You can only use one method. Note that the GOOGLE_NODE_RUN_SCRIPTS
environment variable takes precedence and overrides anything that is specified
for gcp-build in your package.json.
By default, when you configure custom build steps, both the dependencies and
devDependencies in your package.json file are installed first
before any scripts or commands are executed. To override the default behavior,
you can use the NODE_ENV environment variable.
Use GOOGLE_NODE_RUN_SCRIPTS
You can pass the GOOGLE_NODE_RUN_SCRIPTS environment variable to the build to
control what scripts run. You can specify one or more scripts, or instead
pass an empty environment variable to prevent the default behavior from
running, like GOOGLE_NODE_RUN_SCRIPTS=. For complete details, see
Environment variables.
Use package.json
Adding gcp-build in your package.json file only runs
npm run gcp-build, meaning that it overrides the default
behavior. You can specify one or more commands, or instead specify an
empty string to prevent any command from running, like "gcp-build":"".
"scripts": {
...
"gcp-build": "npm run lint && npm run build"
...
}
Application entrypoint
The Node.js buildpack executes the command you specify in the
scripts.start field of your package.json file. If you don't configure the
scripts.start field, the buildpack runs the npm start command.
We recommend using a Procfile because it takes the package manager out of the path and allows for direct execution.
Environment variables
You can set environment variables to configure builds of your container image.
The Node.js buildpack supports the following environment variables to customize your container.
NODE_ENV
Specifies the development environment during the build; set for npm install.
Example: NODE_ENV=development installs both the dependencies and devDependencies specified in package.json.
NPM_CONFIG_<key>
Specifies the configuration parameter, for example, NPM_CONFIG_FLAG=value
passes -flag=value to npm commands.
For information about this environment variable, see Config in the NPM documentation.
GOOGLE_PACKAGE_MANAGER (preview)
Supports the Bun package manager only. This environment variable acts as
an override for the automatic detection process. For example,
GOOGLE_PACKAGE_MANAGER=bun forces the use of Bun even if you don't create a
lockfile.
GOOGLE_NODE_RUN_SCRIPTS
Specifies an ordered list of npm scripts from package.json to run after
installing dependencies. The list must be comma-separated and runs in the order
that you list each script.
When you specify GOOGLE_NODE_RUN_SCRIPTS, only the scripts that you list are
run. For example, if you want to prevent the default npm run build from
running, specify the environment variable without a value.
Examples:
GOOGLE_NODE_RUN_SCRIPTS=lint,buildrunsnpm run lintand thennpm run build.GOOGLE_NODE_RUN_SCRIPTS=runs no scripts.