The concept of an Application is core to the Tonomi Platform. An application is a cohesive collection of components that can be launched as a single unit. For example, a web application may include a collection of servlets, a database schema and a set of configuration files. Large systems will likely comprise several overlapping applications.


Application Manifests

To define an application within the Tonomi Platform, an application manifest must be uploaded or linked. The application manifest presents essential information about the application, including components, configuration, deployment settings and runtime dependencies. It behaves similarly to Makefile or Maven POM, which are used by build systems; however, the application manifest maintains runtime dependencies rather than build time dependencies.


You do not need to know how to write an application manifest if you only want to deploy applications that have been created by others. If you are interested in learning more about manifest development, please refer to Manifest developer’s guide.

Within the Tonomi Platform, a single application can be shared between multiple users under the same corporate account. If you were invited to an existing corporate account, there are most likely applications already set up for you to try out. Any application that belongs to a corporate account is listed on the Applications screen.

New applications can be added to a corporate account via the following methods:

  • By uploading the manifest to the Tonomi Platform.
  • By hosting the manifest on the web and linking its location to the Tonomi Platform.

Application Instances

When an application is launched, a new instance is created that holds state and configuration data for that copy of the application. Uploading a new manifest or refreshing an externally hosted manifest will not affect existing instances.

Most applications will allow you to specify input parameters (e.g. version or the location of source artifacts), which allow for customization at launch time. If defaults are provided for an application’s parameters, you can launch it with a single click on the Applications screen. You can alternatively override the defaults (for the purpose of running a customized instance) by clicking on Advanced launch….

A v1 manifest is described below. Component-based manifests differ slightly in that their startup and destruction sequences can only be indirectly modified by changing the components’ configuration.

Launch Sequence

Every instance begins its life in a Requested state. Once the request to launch a new instance has been acknowledged by the zone controller, the instance’s state changes to Launching. While in this state, the instance will report the launch progress by breaking it down into individual steps.


During launch, the instance will allocate and initialize resources provided by platform services. The time it takes to complete this procedure can range from seconds to hours, depending on the manifest complexity and individual steps’ execution time. Currently, a strict upper limit of 10 hours has been set on the launch time.

A launch can fail due to the absence of a necessary resource, a misconfiguration, etc. If the launch fails, the instance’s state will change to Failed. You can also cancel a launch sequence, which results in a state change to Unknown. When an instance is abruptly stopped, it may result in an inconsistent state.

Once the launch sequence is complete, the instance’s state will change to Running. At this point, the instance’s properties (or return values) will be displayed. Properties are values that are calculated dynamically based on input parameters, resources provided by platform services, and other conditions that are unknown in advance. The properties list depends on the particular instance and application manifest. For example, a common instance property for web apps is a URL pointing to the application entry point.

Destroy Sequence

A running instance typically consumes resources. If you would like to release these resources, you can destroy the instance. The destroy sequence is specified by the application manifest. As with the launch sequence, the instance’s state will first change to Requested, then Destroying and finally to Destroyed. Note that if a destroy sequence fails, the instances state will change to Failed.

Destroyed instances are not removed from the instance list automatically. You must remove them manually if you no longer need the instance record.

Unlike the launch sequence, the destroy sequence cannot accept parameters and relies on instance properties for the data it requires.

Custom Workflows

Every application requires specifications for launching and destroying its instance. Additionally, custom workflows can be triggered by a user action or API call. Custom workflows can only be executed individually and only while an instance is in Running, Failed or Canceled state.

Similar to a launch sequence, custom workflows can accept parameters and modify instance properties. For example, a custom workflow that scales out an application can update the number of virtual machines and their IP addresses as the result of a successful execution.

If a custom workflow fails, the instance’s state changes to Failed. If a custom workflow is canceled, the instance’s state changes to Unknown.