Skip to content

Set up

The purpose of this guide is to set up your system to work with the Open Autonomy framework. All the remaining guides assume that you have followed these set up instructions.


Ensure that your machine satisfies the following requirements:

Additionally, if you wish to deploy your service in a Kubernetes cluster:


On raspberry-pi currently Raspberry Pi OS (Legacy, 64-bit, Debian Bullseye) is tested and supported, The base requirements are same as above.


Although we will use these tools for demonstration purposes only, you might as well consider other local Kubernetes cluster options like kind, or even additional tools like Skaffold or Helm to help you with your cluster deployments.

Set up the framework

  1. Create a workspace folder:

    mkdir my_workspace
    cd my_workspace

    We recommend that you use a Pipenv virtual environment in your workspace folder. Remember to use the Python version you have installed. Here we are using 3.10 as reference:

    touch Pipfile && pipenv --python 3.10 && pipenv shell
  2. Install the Open Autonomy framework and the Open AEA Ethereum Ledger Plugin:

    pip install open-autonomy[all]
    pip install open-aea-ledger-ethereum
  3. Initialize the framework to work with the remote IPFS registry by default. This means that when the framework will be fetching a component, it will do so from the remote registry:

    autonomy init --remote --ipfs --author your_name

    If you had previously initialized the framework, you need to use the flag --reset to change the configuration. Use only letters, numbers or underscores to specify your author handle.

  4. Initialize the local registry:

    autonomy packages init

    This will create an empty local registry in the ./packages folder. If you plan to execute the tutorial guides, you need to populate the local registry with a number of default components.

The registries and runtime folders

As seen above, the framework works with two registries:

  • The remote registry, where developers publish finalized software packages, similarly as Docker Hub images.
  • The local registry, which stores packages being developed (dev), or fetched from the remote registry (third_party) to be used locally.

Additionally, when running agents or service deployments locally, we recommend that you fetch them outside the local registry. This is because the framework will download any required component (or create auxiliary files and folders) within the runtime folders of agents and services. Therefore, we recommend that you keep the copies on the local registry clean to avoid publishing unintended files (e.g., private keys) on the remote registry.

This is roughly how your workspace should look like:


You can override the default registry in use (set up with autonomy init) for a particular command through the flags --registry-path and --local. For example, if the framework was initialized with the remote registry, the following command will fetch a runtime folder for the hello_world agent from the remote registry:

autonomy fetch valory/hello_world:0.1.0:bafybeihyqkidflfhwjr6ik5qmndei467jgud6435ipqi6cp4loxmf5wlny

On the other hand, if you want to fetch the copy stored in your local registry, then you can use:

autonomy --registry-path=./packages fetch valory/hello_world:0.1.0 --local

The Dev template

For convenience, we provide a Dev template repository that you can fork and clone for your Open Autonomy projects, and use it as your workspace folder:

The Dev template comes with:

  • a preconfigured Pipenv environment with required dependencies,
  • an empty local registry,
  • a number of preconfigured linters via Tox.