As indicated by the name, application manifests are owned and maintained by the application team. A manifest acts as a system of record for an application’s components and dependencies, providing a basis for configuration management and release automation. A manifest should be versioned as part of an application’s source code, so that it is always in sync with development.

Whenever an application manifest is fetched by or uploaded to the platform, a new internal version is created. Newly launched application instances use the latest internal version. It is also possible to specify another version if launching an instance through an API.


A manifest is a valid YAML 1.2 file. If you would like to write your own manifests, we recommend that you familiarize yourself with YAML.

Tonomi Platform uses a JSON-compatible subset of YAML. Thus, a manifest can be written in JSON with no effect on semantics. You can think of YAML notation as a convenient shorthand to JSON notation (i.e. you use whitespace instead of curly braces, quotes around strings are mostly optional, etc).


{ "launch": {
    "provision": {
      "action": "execrun",
        "phase": "provision",
        "parameters": {
          "command": ['git', 'fetch']
    action: execrun
      phase: provision
        - git
        - fetch


A manifest consists of the following three sections:

  • (Optional) Version identifier: Latest version is 1.1. If not specified, “1.0” is used.
  • (Optional) Header: Dependencies are specified in the header. Not present in 1.0.
  • Two or more workflow definitions: launch and destroy are required.

Please refer to the example minimal manifest (v1.1), below.

version: "1.1"
header: {}
  steps: []
  steps: []

The next example depicts a v1.0 minimal manifest.

  steps: []
  steps: []


Two manifest versions are currently supported in Tonomi Platform 47.43: 1.0 and 1.1.

  • 1.0 is currently the default.
  • 1.1 introduced the header section. You cannot specify dependencies using 1.0 syntax.


Every application instance is launched in an environment and can only access the services within that environment. However, an instance cannot arbitrarily consume any service that is defined in the environment. Rather, it must explicitly specify required functionality in the form of dependencies. This allows the platform to verify whether the chosen environment contains the necessary pre-requisites before launching, as well as to track which services are consumed by the application. Dependencies are specified in the header of the manifest. Please refer to the Dependencies section for more information.


Workflows define how an instance reacts to external stimuli. Two workflows are required: launch and destroy. Every workflow (except for destroy) can accept parameters and every workflow can set instance properties.

Workflows consist of steps, each of which executes a single action. Steps can be executed sequentially or in parallel, on a single resource or a group of resources, based on defined phases and roles.

Please refer to the Workflows section for more information.