Nextmv Docs

Run your app remotely

Deploy a custom app to Nextmv Cloud in 5 minutes

Before continuing with this tutorial you will need to start a free Production trial. In your Nextmv Cloud account navigate to the Apps page and follow the prompts there to start your free trial.

1Create a new application

After going through the Get Started guide, you should have a directory with a local version of your app. In this quick start guide, we will go through the steps of deploying this app to Nextmv Cloud.

In your terminal, run the following command to create your first app (this can be done from anywhere, you do not have to be in your project’s home directory):

Bash

nextmv app create \
  --app-id sudoku \
  --name "Sudoku" \
  --description "My sudoku app"

This creates a new app with an id of sudoku. You can also now view your new app in the Apps page in Nextmv Console.

Go to step 2

2Push an executable binary to your app

Your new app is just a shell at the moment. It does not contain any executable code. In this step you will build your local model into an executable binary and push it to your new application in Nextmv Cloud.

First, navigate to your local directory that was created in the Get Started guide (if you’re not already there) and then build and push your local model to Nextmv Cloud with the push command:

Bash

nextmv app push --app-id sudoku

This push command will run through the steps to build and publish your model as an executable binary. After the push process has completed, run your app remotely with the run command:

Bash

nextmv app run \
  --app-id sudoku \
  --input ./input.json \
  --wait

Adding the --wait flag will poll the run until the result is available and then display the result.

When running from Nextmv CLI, an assumption is made to run with the most recently pushed binary. To run with a specific binary you must create an application version. (Read more about version management in the Nextmv Cloud Apps overview.)

Go to step 3

3Create new application version

Run the promote command to create a new application version:

Bash

nextmv app promote \
  --app-id sudoku \
  --name "Release 1"

When you run the promote command it takes the most recently pushed binary (in this case the one pushed in Step 2) and attaches it to the version being created. It then takes the newly created version Release 1 and assigns it as the default version for the app.

Now if you run your application remotely with the REST API endpoints it will use the default version as the executable even if you push more recent binaries. (Remote runs with the CLI use the most recently pushed binary because it’s a developer-first experience.)

You can also view your promoted version in Nextmv Console as well. In the future there will be more features around version management for applications.

Go to step 4

4Run the model remotely

You already ran your app remotely in Step 2 with Nextmv CLI. Now run it remotely using your application’s REST API endpoint:

Bash

export NEXTMV_API_KEY=<YOUR_NEXTMV_CLOUD_API_KEY>
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $NEXTMV_API_KEY" \
  -d "{ \
        \"input\": $(cat ./input.json) \
      }" \
  "https://api.cloud.nextmv.io/v1/application/sudoku/run"

(More API examples can be found in the API Reference section of your app in Nextmv Console.)

The command above executes the run. The run ID that is returned is used to retrieve the run result. Save this unique run ID for step 5.

Go to step 5

5View the results

Retrieve the results of the run created in Step 4 with the application run GET endpoint:

Bash

export NEXTMV_API_KEY=<YOUR_NEXTMV_CLOUD_API_KEY>
curl -X GET \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $NEXTMV_API_KEY" \
  "https://api.cloud.nextmv.io/v1/application/sudoku/run/<YOUR_RUN_ID>"

The returned result from the API call will contain your solution in the output block of the JSON along with search statistics and the solvers options that were used. Also included is a metadata block that contains the run result status and which application and application version was used for the run (among other items).

The application_instance_id shows that the default instance was used (this is equivalent to the default version that was set with the promote command in step 3). The ID in the application_version_id field should match the ID of the version that was promoted in step 3. As mentioned earlier, the functionality around versions and instances will grow in future releases and these concepts will be able to be used to manage various production scenarios.

Bash