An API Builder application contains a file called
package.json located in the root directory of the project. API Runtime Services uses the
package.json file to configure settings and install dependencies for the application.
Important fields for API Builder applications are defined below.
The application can import any third-party modules that are supported by standard Node.js applications. Before publishing the app to the cloud, make sure all dependencies are listed in the
dependencies field in the application's
package.json file. For example, to add support for MongoDB 1.2.0 or greater:
You can specify which version of Node.js to run your application on. Use the
engines field in the
package.json file to specify engine versions. To specify the Node.js version, set the
node key in the
engines dictionary to the specific version of Node.js to use. For example, to specify to use version 0.10.22:
You may specify any version of Node.js. Node.js 0.8.26, 0.10.22 and 0.12.4 are built in, but other versions will be downloaded from https://nodejs.org/ when the application is built prior to running
npm install. If you do not specify a Node.js version, the application will use 0.12.4 by default.
Starting with API Runtime Services 1.2.0, you may define a health-check endpoint called
arrowPing.json that returns a 200 HTTP code. To let API Runtime Services know you defined the health-check endpoint, set the
healthCheck field to
true. For an example, see API Builder Project.
By default, the health check starts after a two minute wait period. If your application normally takes longer than two minutes to start up, you should set the
start_period environment variable to an appropriate startup time (in minutes) to avoid having the docker swarm restart your application before it is online.
API Runtime Services uses the
main field in the
By default, the
main field is set to the
app.js file located in the project's root folder:
You can load a module by leaving this field blank and specifying the
name field to specify the name of the application. An app's name must be unique across all apps of a user or organization. It will be used to ID the app when publishing/unpublishing to the cloud or setting up the app through CLI commands.
By default, this field is set to the name of the project when it was created.
To enable authenticated package installs from a private npm registry specified by npmRegistry, add the
npmAuthentication field in your application's package.json file and set it to
When enabled, you must provide login credentials for the npm registry when calling
acs publish . You can provide the credentials on the command line when calling the
If no credentials are provided on the command line, the Appcelerator CLI will attempt to read the credentials from
~/.npmrc. If no
~/.npmrc file is found, or it does not contain any credentials, you are prompted for the npm username and password:
Note: If you use a private npm registry hosted by Nodejitsu, you must first synchronize your public npm user account with the private npm, otherwise you will get an "unauthorized" error. To do this, enter the following
See https://www.nodejitsu.com/documentation/npm/cli/ for more information.
If you want to use a different npm registry besides the official public npm registry to install dependencies, add the
npmRegistry field to the
package.json file and set the value to the registry URL you want to use. For example, the entry below uses a European npm mirror:
To require authentication for npm installs, add the
npmAuthentication field to your
Preinstall and post-install
Specifies a path to a script to execute before or after the application is built. You can use the script to install custom binaries in the project folder.
Prior to API Runtime Services 1.3.0, you could also use the script to install custom binaries outside the project directory.
If your application's
package.json file does not specify a
main field, Appcelerator Cloud will now look at the
scripts.start field in the
package.json file to determine the main module to launch. Appcelerator Cloud will execute the start script using
For example, to launch the foo module:
The version of the application. Used to version the application.
By default, this field is set to