If the application is already deployed, you need to either increment the
version field in the
package.json file to publish a new version of the application or pass the
--force flag to the publish command to republish the application. Before republishing the application, API Runtime Services sends the
SIGTERM signal to the currently deployed application to let it shutdown gracefully. If the app does not shutdown shut down in time, API Runtime Services will kill the application.
The execution time reported by the
accesslog commands report slightly different values. The
accesslog command reports the time required by Appcelerator Cloud to handle the initial user request, pass it to your Node,.js application for processing, and deliver the response. In contrast,
loglist only reports the execution time for your application itself, not including the time required to process the request and response. Consequently, the
accesslog execution times are a slightly longer than those of the corresponding
loglist log item. For instance, below is
Prior to API Runtime Services (formerly known as Arrow Cloud) 1.2.0, the only Node.js versions you could use were 0.8.26 and 0.10.22.
Starting with API Runtime Services 1.2.0, 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
To specify a Node.js version, in the
Starting with API Runtime Services 1.2.0, you may explicitly set the port the application listens on. Set the
Verify that the application listens on PORT, otherwise your app cannot be connected. Use
Install custom binaries
API Runtime Services allows you to install additional binaries before your application is built.
Starting with API Runtime Services 1.3.0, to install additional third-party tools, create a script called
Below is a sample script located in the
Prior to Release 1.3.0, you needed to create a script in your project folder (no name restrictions) and add the script to the
Note that from API Runtime Services 1.3.0 and later, you can still use the above method but do not name the script
Starting with API Runtime Services 1.3.1, if you have scaled your application to use more than one server container, you can make a request to a specific container that your application is running on. To make a request to a specific server container, pass the
_serverid parameter with the request and set it to the ID of the server container. To retrieve the server container ID, run the
appc cloud cloud
accesslog --show_serverid command.
You can bind a custom domain to your application that points to either a CNAME record or A record as well as assign it a path. When setting the domain, do no not specify the protocol, that is, do not prefix the URL with
To set a custom domain, set the
cloud.domain field in the
appc.json file. You can optionally set the
cloud.domainPath field to assign a path to the application. The following example sets a domain and path on the application that can be accessed from
- Certificate file (
customapp.com.crt, for example)
- Intermediate An intermediate certificate authority (
gd_bundle.crt, for example)
- Key used to generate the certificate (
customapp.com.key, for example)
- To specify a bigger container for the application, set the
cloud.containerfield in the
appc.jsonfile or use the
appc cloud servercommand.
- To use more than one container for your application, see Scale the Application.
You can specify one of the following container sizes depending on your AMPLIFY Appcelerator Services subscription: