## 4.1.3.5.2.2  Tips and Tricks for Node.js Applications
Get to know the Node.js buildpack for the SAP BTP, Cloud Foundry environment.
Check the following Cloud Foundry documentation:
- Node.js Buildpack
- Tips for Node.js Developers
## NPM Version
When deploying an application in the SAP BTP, Cloud Foundry environment without specifying the npm version in the package.json file, it will install the default npm version (depending on the Node.js version) during the build step. A version mismatch can cause the build step to fail.
To check your Node.js version, run:
```
node --version
```
To check your npm version, run:
```
npm --version
```
Tip: We recommend that you use the same npm version as the one on the SAP BTP, Cloud Foundry environment.
Alternatively, you can specify the npm version in the package.json file. For example, if you use Node.js 20, you can set:
```
"engines": {
```
```
"npm": "^8.4.1" },
```
##  Note
Bear in mind that Node.js and npm are different products, with their own independent versions. To check the version mapping between them, see NodeJS: Previous Releases .
## Vendor Application Dependencies
Sometimes, productive Cloud Foundry applications might need to be deployed as self-contained. That means, they need to carry all of their dependencies so that the staging process does not require any network calls. For more information, see: Vendoring App Dependencies
Depending on the region where the application is deployed:
- Running on the China (Shanghai) region: it is mandatory for the application to be deployed as selfcontained.
- Running on the AWS, Azure, or GCP regions: it is only recommended but not mandatory for the application to be deployed as self-contained.
There are various reasons to use vendoring. For example, productive applications usually rely on security scans and because npm doesn't provide reliable dependency fetch, it's possible that your Node.js application ends up with different dependencies in case such are installed during deployment. Additionally, npm downloads any missing dependencies from its registry, so if this registry isn't accessible for some reason, the deployment can fail.
##  Note
Bear in mind when using dependencies containing native code that you need to reinstall in the same environment as the Cloud Foundry container, or make sure that the package has built-in support for it.
To ensure that prepackaged dependencies are pushed to the SAP BTP, Cloud Foundry environment and on-premise runtime, make sure that the node\_modules directory isn't listed in the .cfignore file. It's also preferable that development dependencies are not deployed for productive deployments. To ensure that, run:
```
npm prune --production
```
## Out of Memory at Runtime
For performance reasons, Node.js (powered by V8 engine) has lazy garbage collection. Even if there are no memory leaks in your application, this can cause occasional restarts, as explained in the official Cloud Foundry documentation - Tips for Node.js Applications .
Enforce the garbage collector to run before the memory is consumed by limiting the V8 application's heap size at about ~75% of the available memory. To do that, you can either use the OPTIMIZE\_MEMORY environment variable supported by the Node.js buildpack, or specify the V8 heap size directly in your application start command (recommended).
Example for an application started with 256M of RAM:
```
 Sample Code node --max_old_space_size=192 server.js
```
You can optimize V8 behavior using additional options. To list these options, run:
```
node --v8-options
```
## Specify a buildpack version in manifest.yml
At some point, you might need (or decide) to deploy your application with a particular buildpack version from the community nodejs-buildpack repository. For example, if this buildpack contains a Node.js version that is no longer supported by the SAP BTP, Cloud Foundry environment.
Let's say, you want to pin version 1.8.34 . T o do that, proceed as follows:
1. Open the manifest.yml file of your Node.js application.
2. For the buildpack attribute, add the URL to version 1.8.34, like this:
3. Redeploy your application. Run:
```
---applications: - name: myapp random-route: true buildpack: https://github.com/cloudfoundry/nodejs-buildpack.git#v1.8.34 memory: 128M
```
```
cf push myapp
```
## Alternative way:
If you don't want to make changes in your manifest.yml file, you can include the buildpack version in the cf push command.
- To deploy just a single application with this particular buildpack version, run:
- To pin this buildpack version for all applications running in your SAP BTP, Cloud Foundry environment subaccount, run:
```
cf push myapp -b https://github.com/cloudfoundry/nodejs-buildpack.git#v1.8.34
```
```
cf push -b https://github.com/cloudfoundry/nodejs-buildpack.git#v1.8.34
```
## Specify a buildpack version in mtad.yaml
If you have a multi-target application, you can pin a specific buildpack version for it as well. Let's say, you need version 1.8.34 . T o do that, proceed as follows:
1. Open the mtad.yaml file of your Node.js application.
2. Set the module type to javascript.nodejs , for the buildpack attribute, add the URL to version 1.8.34, like this:
3. Redeploy your application. Run:
```
modules: - name: myapp type: javascript.nodejs parameters: buildpack: https://github.com/cloudfoundry/nodejs-buildpack.git#v1.8.34
```
```
cf push myapp
```
For more information, see: MTA Module Types
## Specify application memory in manifest.yml
When deploying an application in the Cloud Foundry environment without specifying the application memory requirements, the Cloud Foundry controller assigns the default (1G of RAM currently) for your application. Many Node.js applications require less memory and assigning the default is a waste of resources.
To save memory from your quota, specify the memory size in the deployment descriptor of your Cloud Foundry application manifest.yml . For example:
```
---applications: - name: myapp memory: 128M buildpack: nodejs_buildpack ...
```