StrongLoop Arc and slc are no longer under active development, and will soon be deprecated. Arc's features are being included in the IBM API Connect Developer Toolkit: Please use it instead.
Skip to end of metadata
Go to start of metadata

See also: slc deploy.


Once Process Manager is up and listening, you can deploy your application to it.  Remember, slc build did not build in your binary dependencies, so you could compile your binary add-ons based on your server OS.


When you deploy an application to Process Manager, you give the deployed application instance a name, referred to as the service name and indicated in command arguments as <service>. By default, it is the name property from the application's package.json.

Process Manager also automatically generates an integer ID for each application it's managing. Typically, the IDs start with one (1) and are incremented with each application deployed; however, the value of ID is not guaranteed. Always determine it with slc ctl status once you've deployed an app.

A service becomes available over the network at http://hostname:port where:

  • hostname is the name of the host running Process Manager
  • port is 3000 + service ID.

For example, if Process Manager is running on, then service ID 1 is available at, service ID 2 at, and so on.

Using the slc deploy command

Go to your system and repository that has the deployable application and enter the slc deploy command.

Its syntax is:

slc deploy [ [ -s | --service] <service> ] http://<server>:<port> [ package | branch ]

  • If you use the -s (or --service) option, the <service> argument is the service name, a string identifier for the application runtime instance. 
  • <server> is the server name or IP address.
  • <port> is the TCP port on which Process Manager is listening.
  • Either:
    • branch - a branch in the current Git repository. Default is "deploy"
    • package - name of a local .tgz file or npm package to deploy.  Default is ../<package_name>-<package_version>.tgz, where the package name and version come from the package.json in the current working directory. 
       NOTE: Generally, you'll deploy a .tgz file created by slc build or the Arc Build & Deploy module, though it can be any .tgz file with the format created by npm pack.

For example, this deploys an application from the default "deploy" branch: 

For more information, see slc deploy.


You cannot deploy an application to a Windows system. However, you can deploy from a Windows system to a Linux or Mac OS system.

Deploying multiple applications to one PM

Use the -s (or --service) option to deploy more than one application to a single instance of Process Manager.

When you deploy an application, simply supply the option and a unique string identifier  (the service argument).  Subsequently, you can use this identifier when using the slc ctl command to manage and view status of the application.  

Once deployed, the application is available over the network at port number 3000 + ID, where ID is the integer identifier that Process Manager assigns the app.  To find the ID, use the slc ctl command as shown in the example below.


Process Manager currently assigns consecutive integer IDs to each application, starting with one (1); so the first application you deploy has ID one (1), the second ID two (2), and so on.  However, as this assignment algorithm may change, you should always confirm the ID with the slc ctl command as illustrated in the example below.


For example, suppose you have StrongLoop Process Manager running on a host, and listening on port 7777 (for simplicity, without secure configuration for this example). 

Suppose also you have two applications: app1 and app2 from which you've created build archives (.tgz files) with slc build.   Let's assume the .tgz files are in the default location (the parent directory of the application root).

Now, assuming in each case that your working directory is the application root directory, you can deploy these two applications as follows:

Deploy app1


Deploy app2

The above examples use "appone" and "apptwo" as the identifiers (or service names) for the applications. By default, if you don't supply a name argument, Process Manager will use the name property in the application's package.json file.

Now, view status of all applications being run by this Process Manager:

You can see that the first application is available at:

And the second application is available at:
  • No labels