Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developers.google.com/appengine/docs/flexible/nodejs/runtime below:

The Node.js runtime | Google App Engine flexible environment docs

The Node.js runtime is the software stack responsible for installing your application code and dependencies, and then running that application in the flexible environment.

Node.js 24 (preview) uses buildpacks. The default Node.js engine uses the latest LTS release. For the full list of supported Node.js versions, and their corresponding Ubuntu version, see the Runtime support schedule.

To use a supported Node.js version, you must:

• Install gcloud CLI version 420.0.0 or later. You can update your CLI tooling by running the gcloud components updatecommand. To view your installed version, run the gcloud version command.

• Include the runtime_config and operating_system settings in your app.yaml file to specify an operating system.

• Optionally, specify a version by:

  • Adding the runtime_version setting in your app.yaml file. By default, the latest Node.js version is used if the runtime_version setting isn't specified. For example:

    • To specify Node.js 24 (preview) on Ubuntu 24:

        runtime: nodejs
        env: flex
      
        runtime_config:
            operating_system: "ubuntu24"
            runtime_version: "24"
      

    • To specify the latest supported Node.js version on Ubuntu 24:

        runtime: nodejs
        env: flex
      
        runtime_config:
            operating_system: "ubuntu24"
      

      The runtime_version setting supports semver.

  • Including the latest supported Node.js version in your application's package.json file using the engines field. When you use the engines field to specify a version, the runtime_version setting takes precedence. To prevent unexpected breakages, we recommend that you specify a Node.js version in the engines field, along with the runtime_version. For example:

      {
        "engines": {
          "node": "24.x"
        }
      }
    

    The engines.node property can be a semver range. If you specify this property, the runtime downloads and installs the latest version of Node.js that matches the semver range. If no match is found, the application fails to deploy and the runtime returns an error.

For Node.js runtime version 16 and earlier, specify a version in your application's package.json file using the engines field.

The following example configures the runtime to use the Node 9 release:

{
  "engines": {
    "node": "9.x"
  }
}

The engines.node property can be a semver range. If you specify this property, the runtime downloads and installs the latest version of Node.js that matches the semver range. If no match is found, the application fails to deploy and the runtime returns an error message.

If you need to use a Node.js version that isn't supported, you can create a custom runtime and select a valid base image with the Node.js version you need.

For Google-supplied base images or Docker Node.js base images, see Building custom runtimes.

During deployment, the runtime uses either the npm, or yarn, or Pnpm package manager to install dependencies and start the application. The package manager is set with the following logic:

• The default package manager is npm.
• If a yarn.lock file is present in your application's root directory, the runtime instead uses the yarn package manager.
• For only Node.js version 18 and later, if a pnpm-lock.yaml file is present in your application's root directory, the runtime instead uses the Pnpm package manager.
• If both a package-lock.json, and yarn.lock or pnpm-lock.yaml exist, your deployment will fail with an error. If you need the package-lock.json file, you must specify the other package manager files in the skip_files section of your app.yaml file to resolve which package manager to use.

The runtime image aims to use the latest yarn release and the release of npm that is available in the latest Node.js LTS release.

You can specify a different package manager version to use in your application's package.json file by using the engines field. In this case, the runtime ensures that the package manager used for the deployment has a version that matches the specification listed in the engines field.

If both a yarn and npm version specification is given, only the package manager that is used for the deployment will be updated if needed. This saves deployment time by not installing a custom version of a package manager if it is not actually being used to deploy your application.

The following example configures the runtime to use a custom version of npm:

{
  "engines": {
    "npm": "5.x"
  }
}

The next example configures the runtime to use a custom version of yarn:

{
  "engines": {
    "yarn": ">=1.0.0 <2.0.0"
  }
}

The engines.npm and engines.yarn properties can both be a semver range.

During deployment, the runtime will use either the npm or yarn package manager to install dependencies by running npm install or yarn install. See the Package Manager section for more information on how the runtime selects the package manager to use.

Also, for more information about managing Node.js packages on Google App Engine, see Using Node.js Libraries.

To enable the use of Node.js packages that require native extensions, the following Ubuntu packages are pre-installed in the Docker image.

• build-essential
• ca-certificates
• curl
• git
• imagemagick
• libkrb5-dev
• netbase
• python

If your application requires additional operating-system-level dependencies, you will need to use a custom runtime based on this runtime to install the appropriate packages.

For Node.js runtime version 18 and later, the runtime environment executes npm run build if a build script is detected in package.json by default. If you require additional control over your build steps before starting your application, you can provide a custom build step by adding a gcp-build script to your package.json file.

To prevent your build from running the npm run build script, you must either:

• Add a gcp-build script with an empty value in your package.json file: "gcp-build":"".

• Add the GOOGLE_NODE_RUN_SCRIPTS build environment variable with an empty value in your app.yaml file.

  build_env_variables:
    GOOGLE_NODE_RUN_SCRIPTS: ''
  

For details about specifying build environment variables see

section in the

file.

The runtime starts your application by using npm start, which uses the command specified in package.json. For example:

"scripts": {
  "start": "node app.js"
}

Your start script should start a web server that responds to HTTP requests on the port specified by the PORT environment variable, typically 8080.

You can use custom runtimes to add additional functionality to a Node.js app running in the App Engine flexible environment. To configure a custom runtime, replace the following line in your app.yaml file:

runtime: nodejs

with this line:

runtime: custom

You must also add Dockerfile and .dockerignore files in the same directory that contains the app.yaml file.

Visit the Custom runtimes documentation to learn how to define a Dockerfile in a custom runtime.

App Engine terminates the HTTPS connection at the load balancer and forwards the request to your application. Some applications need to determine the original request IP and protocol. The user's IP address is available in the standard X-Forwarded-For header. Applications that require this information should configure their web framework to trust the proxy.

With Express.js, use the trust proxy setting:

app.set('trust proxy', true);

For information on enforcing HTTPS connections, see How Requests are Handled.

The following environment variables are set by the runtime environment:

You can set additional environment variables with app.yaml.

Each instance of your application can use the Compute Engine metadata server to query information about the instance, including its hostname, external IP address, instance ID, custom metadata, and service account information. App Engine does not allow you to set custom metadata for each instance, but you can set project-wide custom metadata and read it from your App Engine and Compute Engine instances.

This example function uses the metadata server to get the external IP address of the instance.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4