The Avatarfile documentation is still incomplete, but you can use the following example as a good reference:

# This is of no use... for now, but it must be there
avatarVersion: '0.18.1'

# Keep the value generated by `avatar init`, don't share it across projects.
# This value is used (among other things) to keep track of managed volumes and
# containers
projectInternalId: v2ZmtbkGuVdvGwVE

# The field shellConfig is optional, it allows you to define some settings for
# the Avatar-CLI subshell (started via `avatar shell`).
  # You can define environment variables for the subshell
    SOME_ENV_VAR: 42
  # In the case of the $PATH environment variable, Avatar-CLI forbids declaring
  # it through the `env` field, but you can extend it adding multiple paths to
  # the `extraPaths` field. This can be useful if you want to access tools
  # provided by some package manager, like `npm` or `composer`, as if they were
  # installed globally.
    - ./node_modules/.bin

# In this section we declare the OCI images that we'll use in our project
  # Image name
        # The runConfig block allows us to tweak our containers, to improve
        # their integration with our development environment.
          # You can specify hardcoded environment variables for your containers,
          # in this example we use this to configure NPM's cache
            npm_config_cache: /caches/.npm

          # You can pass host environment variables to your containers
            - NPM_TOKEN

          # You can specify which container paths have to be mounted as volumes,
          # this is specially useful for package managers' caches
            /caches/.npm: {} # In most cases, we won't need to configure volumes
              # Volume names are usually autogenerated, use this configuration
              # option only in case you want to share volumes accross projects
              name: exotic_volume

              # By default, the scope of a volume is "Project", allowed values
              # are "Project", "OCIImage" and "Binary".
              # This setting defines how volumes are shared between containers,
              # and has no effect if a custom volume name has been set.
              scope: Project

          # In most cases, bindings won't be necessary, and it's advisable to
          # avoid them as they difficult to share development environments with
          # other people. But, if you really need to map a container path to
          # your host filesystem, they will allow you to do so.
            /container/path: /host/path

      # For each image, we can declare which binaries we want to expose to our
      # project.
          path: node # The path can also be an absolute path

          # Although we don't do it in this example, each binary can have its
          # own `runConfig` block, and its values will override the ones defined
          # at the image tag level

        # Usually we can skip configuring the binary, we just have to list it
        npm: {}
        npx: {}
        yarn: {}

  # Image name
            path: cargo