Cloudify users will come across several concepts and terms that might have different meanings in other products or systems. For your benefit we define these below:


Agents are task executors.

They may be located on either the application VM, on the manager, or elsewhere - depending on the tools and API’s they need to interface with (see Plugins).

Agents read tasks from a tasks broker and delegate them to a worker subprocess (a Plugin based Python process).

There are currently 3 types of agents. They’re listed below.


An agent dedicated to a specific Deployment.

This agent installs other agents on the hosts of a specific deployment.


An agent dedicated to a specific Deployment which is in charge of executing workflows.


An agent dedicated to a specific Host.

This agent executes plugin tasks on the host machine.


An Application in Cloudify means a software based business service with all of its IT components at the infrastructure, middleware and business logic levels.


A Blueprint is an orchestration plan of an Application.

Cloudify blueprints are inspired by the OASIS TOSCA evolving standard. Essentially it is a YAML file that describes the following:

  • Application topology as nodes and their relationships(#relationship) / dependencies.
  • Implementation of each lifecycle event of each node (the YAML holds a mapping to plugins(#plugin) that implement the events).
  • Configuration for each node.
  • [Optional] Workflows that describe the automation of different processes like installation, upgrade etc. By default the blueprint will use the workflows provided with the product.

Blueprint Resource (Coming soon…)


See the definition here.

Bootstrap Context (Coming soon…)

Capabilities (Coming soon…)

CLI Inputs

When passing inputs/parameters with the --inputs/--parameters flags to different CLI commands, mutiple forms are supported.

  • Simple Key/Value format (e.g. --inputs my_key1=my_value;my_key2=my_value2)
  • Path to YAML file (e.g. --inputs path/to/inputs.yaml)
  • Inline YAML (e.g. --inputs '{"my_key1": "my_value", "my_key2": "my_value"}'. JSON is a subset of YAML so the previous example is completely valid).

Context Object

The context object is an object passed to plugin operations as an argument named ctx which contains the context of the operation invocation.

For example, the context contains the following information:

  • Node id.
  • Deployment id.
  • Plugin name.
  • Operation name.

and more…

In addition, the context object exposes an API for interacting with Cloudify. For example, getting a node’s properties.


A deployment is the plan and the state of a single application environment and is a direct derivative of a blueprint.

Deployments are model-representations of node instances (which form applications) and their runtime state.

DSL Version

See DSL Versioning.


An Event is a JSON representation of an occurance in Cloudify’s environment.

Events are emitted from one of Cloudify’s nodes and are generated as a result of an execution of a specific workflow or any other Cloudify process.

Events are generated (from plugins or Cloudify’s core code) by using the ctx.logger context object(#context-object).


An Execution is a running instance of a workflow and is based on a particular deployment.

An Execution (unlike a deployment or a blueprint has logs and events associated with it.

Execution Cancellation

Standard Cancellation (Coming soon…)

Forced Cacncellation (Coming soon…)


A single instance of a Virtual Machine, Physical Machine or a Linux Container.

Host node

A node in the blueprint that represents a type of host whether it’s a virtual or physical server.


Interfaces set the protocol between the Topology and the Workflow that uses it.

More elaborately, An Interface is a set of hooks (dabbed Operations) that a Type must map to an implementation function in a plugin. Cloudify Types following the aforementioned TOSCA standard, implement, at the very least, the lifecycle interfaces with the following operations:

  • create
  • configure
  • start
  • stop
  • delete

Live node

A node instance(#node-instance) which is not in either the uninitialized or deleted states(#node-instance-state).

Main Blueprint File

When a blueprint is uploaded to the manager, this is the name specified. The entire directory containing the main blueprint file will be uploaded. After that, the main blueprint file will be parsed. Additional YAML files may imported by this blueprint file.


See the definition here.

Manager Blueprints

Standard Cloudify blueprints which are used to bootstrap a Cloudify manager on various providers and/or scenarios.


A Node is one type of component in a topology.

It is an instance of a type with particular properties and dependencies on other components’ (relationships).

For example, a node can be one type of a VM with a particular image ID, HW flavor and bound to a specific security group. Each node can be materialized to any number of runtime components, depending on the number of instances to deploy sepcified in the node settings.

Node Instance

A node instance is a runtime representation of a node.

Node instances carry runtime properties and a state. The number of instances is derived from the property set in a node’s configuration in the blueprint.

Node Instance State

Every node instance(#node-instance) can have one of the following states:

  • uninitialized - The node instance hasn’t been initialized.
  • created - The node instance has been created.
  • started - The node instance has been started.
  • stopped - The node instance has been stopped.
  • deleted - The node instance has been deleted.


An operation is a node or a relationship lifecycle event that is triggered by the workflow.

The operation’s names are defined by an interface and a type that implements this interface maps these operations into plugin functions with the implementation logic.


Plugins are extensions to the agents.

Plugins interface with an API or a CLI in order to execute lifecycle events of a node. Plugins are written in Python.

Policy (Coming soon…)

Policy Engine

See the definition here.


Properties are a node’s design-time configuration details.

Properties are expressed as a YAML dictionary in the blueprint.

Provider Context

Details of the manager environment such as the name of the management network.

The provider context is available in any plugin function in case the plugin code needs such information in order to perform tasks such as agent configuration or VM configuration (as Cloudify needs each VM to be connected also to the management network ifplugin it has an agent installed on it.)


Relationships are types that describe the nature of dependency between nodes and the logic, if required, to glue nodes together.

For example, a relationship can be of type cloudify.relationship.contained_in. That means that node X is hosted within node Y and therefore can’t be created until node Y is created and running.

Another example is an Apache server that’s connected to MySQL. In this case, Apache needs to be configured at runtime to connect to MySQL. Waiting for MySQL to be up and running won’t suffice in this case. The relationship needs to map relationship operations to plugin functions that execute the connection’s configuration.

Relationship instance

An instance of a relationship between 2 concerte node instances.

Relationship type

A relationship type describes the nature of dependency between 2 nodes and the logic to materialize it (through operations mapping to implementation).

A relationship is always between a source node and a target node and it can have implementation logic to run on either or both.

There are 3 basic relationship types:

  • cloudify.relationship.depends_on - a base type for all relationships. It means the orchestrator must wait for the target node
  • cloudify.relationship.contained_in - the source node is installed within the target node
  • cloudify.relationship.connected_to - the source node has a connection to configure to the target node

Runtime Data

The data model of the deployements stored in Cloudify’s database.

Cloudify holds a data model per application deployment. This data model contains the node instances, with each instance storing its unique instance id as well as copy of the blueprint’s original configuration for this node and runtime properties for this node instance.

Runtime Properties

Runtime Properties are execution-time details of node instances.

Runtime Properties are saved to the database so that they can be consumed by plugins or by users. Unlike node properties, which are explicitly specified in the blueprint, runtime properties are only set during runtime by Cloudify or its plugins.


A Task is the execution of one operation in a plugin with a given set of arguments.

The arguments describe the context of the execution including node properties and node instance runtime properties.


See the definition here.


A Topology is an application’s graph of nodes and their relationships.

A Topology also describes the lifecycle events or other operations that each node and relationship exposes for use in workflows.

A Topology is denoted in YAML.


A Type is a class of an application’s node.

For example a db_server type represents a database server.

The basic types provided with Cloudify are abstract and only serve as markers. Derived types have their operations mapped to a particular plugin that enables their materialization using some API or tool.

For example, cloudify.types.openstack.server is using the nova_plugin to communicate with OpenStack’s Nova API (compute API) to spawn virtual machines on OpenStack clouds.

Type Hierarchy

The inheritence chain of a type or a relationship.

Cloudify blueprints use Object Oriented methaphore of inheritence so any concrete Type or relationship is derived from more basic type either with implementation that needs to be refined or without any operation implmentation.


A workflow is an automation process algorithm.

Workflows are described in Python and use dedicated API’s for reading and writing a node’s state, reading a node’s configuration and sending tasks for execution. Workflows are executed via Cloudify’s workflow engine.

Workflow Engine

See the definition here.