Skip to Content

Setup Supra CLI

Installation of the Supra CLI using Docker. Each network has its own image, which holds the CLI release that network runs, and its latest tag is that release:

NetworkImageDirectory on your machine
Devnetsupraoracles/supra-devnet-validator-nodesupra-devnet
Testnetsupraoracles/supra-testnet-validator-nodesupra-testnet
Mainnetsupraoracles/supra-mainnet-validator-nodesupra-mainnet

Use the image of the network you will interact with.

Prerequisites

The installation process of Docker is straight forward and requires no additional configuration. The only requirement to proceed is to ensure the Docker Daemon  is running. If you installed Docker Engine, opening the program will start the daemon.

Install and Setup the CLI

Start the container with Docker Compose

Open your terminal and cd to the directory on your machine where you wish to setup the CLI, for example Documents. Then choose your network and run its commands. They create a directory for the network, write its Compose file and start the container, pulling the image the first time.

The commands need a bash or zsh shell. On Windows, run them in WSL or Git Bash.

mkdir -p supra-devnet/configs supra-devnet/move_workspace cd supra-devnet cat > compose.yaml <<'EOF' name: supra_cli_devnet services: supra_cli: container_name: supra_cli_devnet platform: linux/amd64 image: supraoracles/supra-devnet-validator-node:latest environment: SUPRA_HOME: /supra/configs volumes: - type: bind source: ./configs target: /supra/configs - type: bind source: ./move_workspace target: /supra/move_workspace tty: true network_mode: host entrypoint: > bash -c "echo 'supra() { /supra/supra \"\$@\"; }' >> ~/.profile && echo \"alias supra='/supra/supra'\" >> ~/.bashrc && exec bash" EOF docker compose up -d

The Compose file sets platform: linux/amd64. On an arm64 host, such as a Mac with Apple Silicon, Docker then runs the CLI under emulation.

The network’s directory holds two directories that are bind mounted into the container: configs at /supra/configs, where the CLI keeps its profiles, and move_workspace at /supra/move_workspace, for your Move packages. Each network has its own configs because the networks run different CLI releases, and a CLI cannot open a profile database written by a later release.

You can confirm that the container is running by executing docker ps --all. This command will output all docker containers that exist on your machine, whether they are running or stopped.

Enter the shell of the container

To interact with the Supra CLI, we must enter the shell of the container. This will allow us to execute commands within the container from our host machine.

docker exec -it supra_cli_devnet /bin/bash

The configs and move_workspace directories are your network’s directories on your host machine, bind mounted into the container. The CLI binary is /supra/supra. The Compose file defines supra as an alias for it in interactive shells, such as the one docker exec -it ... /bin/bash opens. In a script or a non-interactive docker exec, run /supra/supra.

Execute the supra command

supra with no arguments lists its commands, supra <command> --help describes one, and supra --version prints the CLI version and, on its second line, the release, for example tag:supra_node_v12.0.0.rc6. That release is the one the network runs.

Within the shell of the container, CLI commands operate in the same manner as you would expect on your host machine. For example, executing commands such as supra move tool init will initialize the new module within your current working directory. You may view all available arguments of any command by passing the --help argument.

Example: supra move tool init --help

Create a profile for the network

A profile holds an account’s keys and the network it sends transactions to. Create one for the network you chose:

supra profile new <PROFILE_NAME> --network devnet

Create a Supra Account describes profiles in more detail.

Coming from the previous setup

The previous version of this page ran one container named supra_cli, with the supra/configs and supra/move_workspace directories next to where you ran the setup command. Those hold your profiles and packages. To keep them:

  1. Copy their contents into the directories of the network the profiles belong to, for example for Testnet:

    cp -R supra/configs/. supra-testnet/configs/ cp -R supra/move_workspace/. supra-testnet/move_workspace/
  2. Remove the old container:

    docker rm -f supra_cli
  3. Start the network’s container and enter its shell as described above, then run:

    supra profile migrate

Profiles created by CLI releases before v11 are kept in an encrypted file, smr_secret_key.pem. Later releases keep them in a database, cli_data.db. supra profile migrate takes no arguments. It reads smr_secret_key.pem from SUPRA_HOME, which is /supra/configs in these containers, asks for the CLI password that protects it, and writes cli_data.db next to it. It leaves smr_secret_key.pem in place. If cli_data.db already exists, or there is no smr_secret_key.pem, it prints a message and changes nothing. If it warns that the password is weak, supra profile reset-password sets a new one.

Updating the CLI

When a network is upgraded, its image’s latest tag moves to the new release. Pull it and recreate the container from the network’s directory:

docker compose pull docker compose up -d

Using more than one network

Each network’s container is named supra_cli_<network>, for example supra_cli_devnet, so the containers of different networks can run at the same time. Start each from its own directory, and enter the one you want with docker exec. docker compose down in a network’s directory removes that network’s container but not its configs and move_workspace directories, so its profiles and packages are still there when you start it again.

Last updated on