Deploy your App using the CLI

  • 1
    Installing the NodeChef CLI

    Ensure Node.js is installed on your computer and then install the CLI by running the below command:

    npm install -g nodechef-cli

  • 2
    Deploy your cluster

    Log in and navigate to the Dashboard. Click on deployments and complete the form. You will be required to select the size of your container and the region where your cluster is to be hosted.

  • 3
    [Optional] - Environment variables

    If you will like to launch your app with custom environment variables follow the below steps.

    You can always update your environment variables from the dashboard after your deployment.
    • Create a file in the root directory of your app with name env.json. Env.json is completely arbitrary you could name this file with a name more suitable for your use case such as; env_dev.json or env_prod.json
    • Edit the file using the JSON syntax below and save the file. SOME_API_URL is only for demonstration purposes.
      { "SOME_API_URL": "" }
      The CLI JSON parser does not accept single quotes. Environment variables can also be configured after deployment from the web dashboard.

  • 4
    [Optional] - Application start command

    On NodeChef, you may use a Procfile to specify a start command for your App. An example Procfile is shown below. You must create a Procfile in the root folder of your application. If a Procfile is not included, the platform uses the default start command provided by the buildpack to start the application.

    # An example Procfile for a Ruby app web: bundle exec puma -C config/puma.rb

    NodeChef can also detect your manifest.yml typically used for cloud foundry deployments. The command property under application will be auto detected by the platform if present and will use it as the start command.

  • 5
    Deploy your application

    From the command prompt run the below command(s) to deploy your application

    // Log in once and you will always be logged in on your computer until you log out nc login -em -pw ***** // CD into your project folder and deploy nc deploy -i elixir-app -bp elixir,phoenix-static // If deploying a .jar, .war, .zip, use the -l option to specify the path to the build artifact nc deploy -i java-app -l /home/spring-music.jar -bp java


    On NodeChef, the root folder of your app in the executing container, that is the $HOME directory is always "/bundle". Please take note of this if you are migrating from another platform and you have hard coded the root directory.


    Required. Specify the name of your app. Note this name must match the name used when creating the cluster from the dashboard.

    Optional. Deploy your app with environment variables created in step 3 by specifying the relative or absolute path to the file.

    Required. Specify the buildpack to be used to build your application. In some cases, you may specify multiple buildpacks by separating the values with a comma.

    Supported buildpack values include:

    Buildpack names must be typed in all lowercase.

    Optional. Use this switch to specify your application folder or bundle (.zip, .tar.gz, .jar, .war, .tgz). If you are running the CLI from the root folder of your application and you are deploying your folder, you do not have to specify this switch as the current folder will be automatically considered as the root folder of your application.
    The -l switch on nodechef does what the -p switch on the cf cli does.

    Optional. Specify the named command in your Procfile to be executed. For eg: -cmd worker - This will result in your container executing the worker command instead of your web or any other named command in your Procfile. This feature allows you to deploy the same codebase without any modification to your worker, web and other class of containers. Eg:
    nc deploy -i myapp -bp java -l /home/spring-music.jar -cmd worker

    Optional. Whenever you deploy your app, a new container is created which replaces the old one. The intent is to allow a seamless upgrade without any of your clients ever hitting an empty page. However for this to be possible, the new container has to completely load after the build and ready to accept incomming connections. This parameter allows you to control how long in seconds the container manager will wait before replacing your old container with the new one after the build. The highest value that can be specified is 60. Note the usage of a double hyphen before startupwait. eg: deploy -i simple-todos --startupwait 10