If you are already familiar with the Cloud Platform user interface, getting started with a Node.js application is similar to the other applications you have already created in Cloud Platform.

For your reference, here is how Node.js applications and environments are managed, and how you develop your code in them, which may be slightly different than your previously created applications and environments.

Managing applications

Many of the basic application management functions are the same for Cloud Platform-hosted Drupal applications. These functions include:

• Modifying views of applications
• Adding applications
• Renaming applications

For a full explanation of each of these functions, see Managing applications with the Cloud Platform interface.

Managing environments

The Cloud Platform implementation of Node.js uses separate environments to help you maintain a clear and orderly workflow as you develop, test, and publish your applications. An application is deployed on each of its environments, but each environment may be in a different state—possibly with a build artifact deployed. Each environment has a URL at which its application can be accessed, but only the production environment’s URL is designed to be visible to the application’s users (website visitors).

Acquia Node.js applications start with one production (Prod) environment, and one development (Dev) environments. See Resources and limitations for Node.js environments

If you are already familiar with the Cloud Platform user interface, getting started with a Node.js application is similar to the other applications you have already created in Cloud Platform.

For your reference, here is how Node.js applications and environments are managed, and how you develop your code in them, which may be slightly different than your previously created applications and environments.

Managing applications

Many of the basic application management functions are the same for Cloud Platform-hosted Drupal applications. These functions include:

• Modifying views of applications
• Adding applications
• Renaming applications

For a full explanation of each of these functions, see Managing applications with the Cloud Platform interface.

Managing environments

The Cloud Platform implementation of Node.js uses separate environments to help you maintain a clear and orderly workflow as you develop, test, and publish your applications. An application is deployed on each of its environments, but each environment may be in a different state—possibly with a build artifact deployed. Each environment has a URL at which its application can be accessed, but only the production environment’s URL is designed to be visible to the application’s users (website visitors).

Acquia Node.js applications start with one production (Prod) environment, and one development (Dev) environments. See Resources and limitations for Node.js environments for infrastructure details.

• Development environments: Shared between customers
• Production environments: Dedicated to a single customer

Determining Node.js version on an environment

The Overview page for an environment displays the Node.js version installed on an environment. To check the version installed on an environment, complete the following steps:

1. Sign in to the Cloud Platform user interface.
2. In the breadcrumbs menu, click the triangle and select your organization (glossary term, activate to view definition), application, and environment to display the environment’s page.

The Cloud Platform user interface displays the Node.js version at the bottom of the Information section as shown in the following example:

Configuring Node.js version on an environment

1. Sign in to the Cloud Platform user interface.
2. Select your application and environment.
3. Click the Configure icon. Cloud Platform will display the Configuration panel.

4. In the Configuration panel, select the Node version you want to use for the environment:

   
5. Click Save.

Developing your application

Development with Node.js on Cloud Platform requires you create pipelines for your code.

Based on the normal Pipelines workflow, after connecting your application to a repository, you must create your build definition file.

The Cloud Platform uses the conventional npm start command to start your Node.js application. Ensure that you have a snippet similar to the following in your application’s package.json file:

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

Update your Node.js application within the error-handling code so that the code can capture error information and display logs and error messages in log streaming. Node.js applications that capture logs through console.log() and error messages through console.error() can provide effective monitoring and troubleshooting.

Node.js applications on Cloud Platform have a docroot directory. This directory isn’t used by Node.js applications, and can be safely added to your .gitignore file.

For a detailed tutorial about local Drupal and Node.js setup, see Node.js with Decoupled Drupal on Cloud Platform.

Pipelines client commands

The Pipelines client for Cloud Platform includes commands that are specific to Node.js applications and commands available for your YAML file. For a listing of commands in the CLI client, see Using the Cloud Platform Pipelines client.

Creating a Pipelines artifact for a Node.js application

The following is an example script for building a Pipelines artifact with your Node.js application:

# For more acquia-pipelines.yaml pipelines examples, see
# https://docs.acguia.com/pipelines/yaml/examples/
version: 1.2.0
variables:
  global:
    # All of these settings are only needed if you want to use the custom deployment script.
    # Use the name of the environment where the automatic deployment should happen.
    # The deployment script will deploy all the new commits to this given environment.
    TARGET_ENV_NAME: 'stage'
    ARTIFACT_NAME: '${PIPELINE_VCS_PATH}@${PIPELINE_GIT_HEAD_REF}'
    PIPELINE_JOB_URL: 'https://cloud.acguia.com/app/develop/applications/${PIPELINE_APPLICATION_ID}/pipelines/jobs/${PIPELINE_JOB_ID}'
    PIPELINE_ARTIFACT_START_LOG: '/tmp/pipelines-artifact-start-${PIPELINE_JOB_ID}.log'
    # Put your Cloud API credentials here.
    CLOUD_API_KEY:
      secure:
    CLOUD_API_SECRET:
      secure:
events:
  build:
    steps:
      - build:
          script:
            - nvm use <node_version>
            # <node_version> must be the version of node that you want to target. For example, to target version 22: nvm use 22.
            - npm install --production
            # The next line is only needed when the built code is not part of the commits, otherwise it can be removed.
            - npm run build
            # Here you can include all the needed scripts for the build to be production ready. Only needed if the built code is not part of the commit.
      - upload-artifact:
          script:
            - pipelines-artifact start
            - pipelines-artifact upload $SOURCE_DIR
  fail-on-build:
    steps:
      - fail:
          script:
            - pipelines-artifact fail
post-deploy:
  steps:
    - deploy:
        script:
          - 'chmod +x ./deploy-artifact.sh'
          - ./deploy-artifact.sh
          - 'echo Artifact $ARTIFACT_NAME is deployed to $TARGET_ENV_NAME environment'
          - 'echo Check task log for more details at $PIPELINE_JOB_URL'

For other example scripts for pipelines, see Example Pipelines build definition files.

Configuring Puppeteer

To use the Puppeteer package, add a .puppeteerrc.cjs file in the application root directory with the following content:

const {join} = require('path');

/**
* @type {import("puppeteer").Configuration}
*/
module.exports = {
// Changes the cache location for Puppeteer.
cacheDirectory: join(__dirname, 'browsers', 'puppeteer'),
};

You must replace __dirname with the directory in which you want to install Chrome. Puppeteer uses the specified directory to install and use the Chrome package. Therefore, you do not need the globally installed Chrome package.

For more information, see Puppeteer configuration.