This buildpack is deprecated. Use the new Heroku Node.js Buildpack, instead.
All new apps use the new Node.js buildpack by default. To upgrade existing apps crated before 17 September 2024 to the new Node.js buildpack, see How to Upgrade Your Node.js Buildpack in App Platform.
App Platform supports two ways to build an image for your app: Cloud Native Buildpacks and Dockerfiles.
When you give App Platform access to your code, it defaults to using a Dockerfile if one is present in the root of the directory or specified in the app spec. Otherwise, App Platform checks your code to determine what language or framework it uses. If it supports the language or framework, it chooses an appropriate resource type and uses the proper buildpack to build the app and deploy a container.
heroku-buildpack-nodejs is utilized as the buildpack for detecting and building your Node.js applications.
Node.js Applications using Buildpacks
App Platform looks for any of the following files to detect a Node.js application:
package.json
package-lock.json
yarn.lock
pnpm-lock.yaml
The order of preference is yarn.lock
, pnpm-lock.yaml
and package-lock.json
.
If all three files are present, Yarn is preferred.
If only pnpm-lock.yaml
and package-lock.json
exist, Pnpm is preferred.
Current Buildpack Version and Supported Runtimes
Default Stack
App Platform uses version 0.4.0
of the Node.js Cloud Native Buildpack by default. If no version is specified in your app, for Node.js v1 App Platform defaults to using version 20.x
and for Node.js v0 App Platform defaults to using version 16.x
.
The buildpack supports the following Node.js runtime versions:
Specifying Versions
Specify your desired Node version in the engines
section of package.json
.
package.json
{
"engines": {
"node": "16.x"
}
}
You can customize the npm version used by specifying the version in the engines
section of your package.json
:
package.json
{
"engines": {
"npm": "~1.0.20"
}
}
You can customize the Yarn version used by specifying the version in the engines
section of your package.json
:
package.json
{
"engines": {
"yarn": "^0.14.0"
}
}
Starting from Yarn v3, the default behaviour is changed to Plug’n’Play i.e.
on yarn install, a single Node.js loader file is generated in place of typical node_modules.
Our nodejs-buildpack needs node_modules to be present in project.
In order to fix this, the user needs to add a .yarnrc.yml file with config - nodeLinker: node-modules.
This tells yarn to generate node_modules.
Long Term Support (LTS) versions of Node.js are not supported.
You can customize the Pnpm version used by specifying the version in the engines
section of your package.json
:
package.json
{
"engines": {
"pnpm": "8.14.1"
}
}
Specifying devDependencies
App Platform installs devDependencies
and doesn’t set NODE_ENV
during the build process by default. If your build command requires devDependencies
but you want to set NODE_ENV
to production
, configure the following custom script. This script installs devDependencies
even if NODE_ENV
is set to production
.
Yarn
package.json
"scripts": {
"build:digitalocean": "yarn install --production=false && yarn run build && rm -rf node_modules && yarn install --production --frozen-lockfile",
...
}
App Platform Build Command
Pnpm
package.json
"scripts": {
"build:digitalocean": "pnpm install --production=false && pnpm run build && rm -rf node_modules && pnpm install --production --frozen-lockfile",
...
}
App Platform Build Command
pnpm run build:digitalocean
npm
package.json
"scripts": {
"build:digitalocean": "npm install --production=false && npm run build && npm ci",
...
}
If you are using an older Node.js version prior to 7.7.x, use this build command instead.
package.json
"scripts": {
"build:digitalocean": "npm install --include=dev && npm run build && npm ci",
...
}
App Platform Build Command
npm run build:digitalocean
Caching
The buildpack automatically caches and re-uses the node_modules
directory between builds. After the package manager’s install command is run (yarn install
or npm install
), the node_modules
directory is stored in the build cache along with snapshot of the package manager’s lockfile. In subsequent builds, the cached node_modules
directory will be restored only if the lockfile’s contents are identical to cached version. Otherwise, the cache will be discarded.
Clearing the Cache
If your app is failing to build and you suspect that the issue is related to node_modules
caching, you can force clear the cache and start a new build. To do this in the control panel, navigate to your app, click the Actions menu, and then select Force Build and Deploy.
In the Force Build and Deploy window, select the Clear Build Cache option, and then click the “Deploy” button. This clears the build cache and starts a new deployment.
Here’s an example with Node and Express that uses the PORT variable or 3000
for developing locally.
const express = require('express');
const app = express();
// get our port
const port = process.env.PORT || 3000;
// application code goes here
// have node listen on our port
app.listen(port, () => console.log(`App listening on port ${port}!`));