Cloud Foundry Documentation
- General Information
- Contribute to Cloud Foundry documentation
- Cloud Foundry concepts
- Cloud Foundry overview
- Security and networking
- Cloud Foundry security
- Container security in Cloud Foundry
- Container-to-container networking
- Identity-aware routing
- Orgs, spaces, roles, and permissions in Cloud Foundry
- Managing Roles
- Planning orgs and spaces in Cloud Foundry
- App Security Groups in Cloud Foundry
- Cloud Foundry app SSH components and processes
- High availability
- How Cloud Foundry manages apps
- Cloud Foundry components
- Cloud Foundry Command Line Interface (cf CLI)
-
- Information for Operators
- Deploying Cloud Foundry
- Administering Cloud Foundry
- Managing the runtime
- User accounts and communications
- Routing
- Enabling IPv6 for hosted apps
- Distributed tracing
- Enabling Zipkin tracing
- Enabling W3C tracing
- Supporting WebSockets
- Configuring load balancer health checks for CF routers
- Troubleshooting slow requests
- Troubleshooting router error responses
- Securing incoming traffic
- Configuring trusted system certificates for apps
- Bulletin Board System data store encryption
- Enabling and configuring TCP routing
- Configuring HTTP/2 support
- Isolation segments
- Delayed jobs in Cloud Foundry
- Managing apps and their stacks
- Running and Troubleshooting Cloud Foundry
- Cloud Foundry logging
- Configuring system logging
- Configuring Diego for upgrades
- Audit Events
- UAA audit requirements
- Usage events and billing
- Configuring SSH access for Cloud Foundry
- Configuring Diego Cell disk cleanup scheduling
- Configuring Health Monitor Notifications
- Adding a custom stack
- Monitoring and testing Diego components
- Troubleshooting Cloud Foundry
- UAA performance
- UAA performance metrics
- Scaling Cloud Controller
- Cloud Controller Multi-Process Mode (Puma)
- Scaling Cloud Controller (cf-for-k8s)
- Logging and metrics in Cloud Foundry
- Logging and metrics architecture
- Installing the Loggregator plug-in for cf CLI
- Security event logging
- App logging in Cloud Foundry
- Limiting your app log rate in Cloud Foundry
- Cloud Foundry component metrics
- Container metrics
- Loggregator guide for Cloud Foundry operators
- Logging and metrics in Cloud Foundry
- Configuring the OpenTelemetry Collector
- Deploying a nozzle to your Cloud Foundry Loggregator Firehose
- BOSH Documentation
- BOSH Backup and Restore (BBR)
- Information for developers
- Developing and managing apps
- How to push your app with Cloud Foundry CLI (cf push)
- Pushing your app using Cloud Foundry CLI (cf push)
- Deploying with app manifests
- App manifest attribute reference
- Deploying an app with Docker
- Deploying your large apps
- Starting, restarting, and restaging apps
- Pushing an app with multiple processes
- Running cf push sub-step commands
- Configuring app deployments
- Pushing apps with sidecar processes
- Using blue-green deployment to reduce downtime
- Troubleshooting app deployment and health
- SSH for apps and services
- Routes and domains
- Managing services
- Provisioning and integrating service instances
- Managing service instances
- Sharing service instances
- Delivering service credentials to an app
- Managing service keys
- Configuring Play Framework service connections
- Using an external file system (volume services)
- User-provided service instances
- Manage app requests with route services
- Streaming app logs
- Managing apps with the cf CLI
- Cloud Foundry environment variables
- Available Cloud Controller API client libraries
- Designing and running your app in the cloud
- Cloud Foundry API app revisions
- How to push your app with Cloud Foundry CLI (cf push)
- Cloud Foundry Buildpacks
- Cloud Native Buildpacks
- Classic Buildpacks
- What are classic buildpacks?
- Binary buildpack
- Go buildpack
- Hosted Web Core buildpack
- Java buildpack
- .NET Core buildpack
- NGINX buildpack
- Node.js buildpack
- Using PHP buildpack with runtimes
- Python buildpack
- R buildpack
- Ruby buildpack
- Staticfile buildpacks
- Creating custom buildpacks
- Information for Managed Service Authors
- Services in Cloud Foundry
- Service Broker API
- Managing service brokers in Cloud Foundry
- Managing access to service plans
- Binding credentials in Cloud Foundry
- CredHub
- Dashboard Single Sign-on
- Service instance sharing in Cloud Foundry
- Service broker examples
- App log streaming in Cloud Foundry
- Offering Route Services in Cloud Foundry
- Supporting multiple CF instances
- User Account and Authentication
- API Reference
- UAA API
- CAPI API
Node.js buildpack additional information
Page last updated:
You can use node-specific information to supplement the general guidelines in the Pushing an app topic.
For information about using and extending the Node.js buildpack in Cloud Foundry, see the nodejs-buildpack repository in GitHub.
You can find current information about this buildpack on the Node.js buildpack release page in GitHub.
The buildpack uses a default Node.js version.
To specify the versions of Node.js and npm an app requires, edit the app’s package.json, as described in “node.js and npm versions” in the nodejs-buildpack repository.
Application package file
Cloud Foundry expects a package.json in your Node.js app.
You can specify the version of Node.js you want to use in the engine node of
your package.json file.
In general, Cloud Foundry supports the two most recent versions of Node.js. See the GitHub Node.js buildpack page for current information.
Example package.json file:
{
"name": "first",
"version": "0.0.1",
"author": "Demo",
"dependencies": {
"express": "3.4.8",
"consolidate": "0.10.0",
"swig": "1.3.2"
},
"engines": {
"node": "0.12.7",
"npm": "2.7.4"
}
}
Application port
You must use the PORT environment variable to determine which port your
app listens on. To also run your app locally, set the default port as 3000.
app.listen(process.env.PORT || 3000);
Low Memory environments
When running node apps, you might notice that instances are occasionally
restarted due to memory constraints. Node does not know how much memory it is
allowed to use, and thus sometimes allows the garbage collector to wait past
the allowed amount of memory. To resolve this issue, set the OPTIMIZE_MEMORY environment variable to true (requires node v6.12.0 or greater). This sets max_old_space_size based on the available memory in the instance.
$ cf set-env my-app OPTIMIZE_MEMORY true
Application start command
Node.js apps require a start command. You can specify the web start command for a Node.js app in a Procfile or in the app deployment manifest. For more information about Procfiles, see the Configuring a Production Server topic.
The first time you deploy, you are asked if you want to save your configuration.
This saves a manifest.yml in your app with the settings you
entered during the initial push.
Edit the manifest.yml file and create a start command as follows:
---
applications:
- name: my-app
command: node my-app.js
... the rest of your settings ...
Alternately, specify the start command with cf push -c.
$ cf push my-app -c "node my-app.js"
Application bundling
You do not need to run npm install before deploying your app.
Cloud Foundry runs it for you when your app is pushed.
You can, if you prefer, run npm install and create a node_modules folder
inside of your app.
Solve discovery problems
If Cloud Foundry does not automatically detect that your app is a Node.js app, you can override auto-detection by specifying the Node.js buildpack.
Add the buildpack into your manifest.yml and re-run cf push with your
manifest:
---
applications:
- name: my-app
buildpacks: https://github.com/cloudfoundry/nodejs-buildpack
... the rest of your settings ...
Alternately, specify the buildpack on the command line with cf push -b:
$ cf push my-app -b https://github.com/cloudfoundry/nodejs-buildpack
Bind services
Refer to Configure Service Connections for Node.js.
Environment variables
You can access environments variable programmatically.
For example, you can obtain VCAP_SERVICES as follows:
process.env.VCAP_SERVICES
Environment variables available to you include both those defined by the system and those defined by the Node.js buildpack, as described below.
BUILD_DIR directory
Directory into which Node.js is copied each time a Node.js app is run.
CACHE_DIR directory
Directory that Node.js uses for caching.
PATH
The system path used by Node.js.
PATH=/home/vcap/app/bin:/home/vcap/app/node_modules/.bin:/bin:/usr/bin
