Actions are executable scripts in the form of CloudBolt plug-ins, remote scripts, webhooks, emails, and external orchestration engine flows (HPSA, vCO).

This section is meant to provide the initial information needed to get started authoring actions. For sample content, go to any of the links in “Contexts in which actions may be executed” on Admin > All Actions. On those views, you can browse actions published on the CloudBolt Content Library by clicking the cloud button in the top right.


You may also visit the CloudBolt Forge which contains content that is not yet browsable from the CB user interface. If you have questions, do not hesitate to contact CloudBolt support or post to our community help forum.

Action Types

Every action is of a particular type, which indicates its mode of execution:

  • CloudBolt Plug-in - Python module that runs on the CloudBolt server and has access to internal CloudBolt APIs
  • Remote script - arbitrary code that runs on servers under management by CloudBolt
  • Copy file - copy files from CloudBolt to remote server(s)
  • Webhook - call external APIs to integrate CloudBolt with other systems
  • Email - send emails to one or more recipients
  • External flow - run workflows in external orchestrators such as HP Operations Orchestration or vCenter Orchestrator
  • Terraform Plan - apply Terraform plans from a directory containing Terraform files.

Actions with Code

Plug-ins and remote scripts execute code. This code can either be installed on the CloudBolt server by uploading a file or loaded dynamically from a URL. The latter option allows you to maintain action code in a source code repository and deploy changes in a controlled fashion.


Uploaded File

CloudBolt stores uploaded source code files in an upgrade-safe location: /var/www/html/cloudbolt/static/uploads/hooks/.

Some actions come with a source code file provided out-of-the-box. It is perfectly safe to edit these actions, and your version of the code will be stored in the upgrade-safe location above. You can also easily view both the current code and the out-of-the-box code, in order to compare them.

External Source Code

To use code hosted on another system, determine the URL to the raw file content on that system.

After fetching the source code from the system, CloudBolt will cache it locally. The cached version will be used in the future if there’s a connection failure and the system can’t be accessed.

Optionally, add URLs to the External URL Whitelist field in Miscellaneous Settings. This specifies which external URLs CloudBolt is allowed to access. The default (.*) allows access to all URLs.

  1. Click Admin > Miscellaneous Settings
  2. Scroll to External URL Whitelist and begin entering URLs as regular expressions. This is a semi-colon delimited list.
  3. Click Save Changes.

GitHub Example

Navigate to the script in your repository. Click on the Raw link and copy the contents of the address bar without the stuff after the question mark to get a URL like this:


GitHub also supports branch names in URLs (above example is in the ‘master’ branch), so you might create a production branch and only push updates to it when they are ready to be used by CloudBolt.

Source Code Repository Authentication

If your repository is private, CloudBolt will need to have credentials to access file contents. Go to Admin > Connection Info.

Create a new Connection Info entry named exactly “Source Code Repository”. Provide any value for IP/hostname, like “” (this field isn’t used but is required) and enter Username and Password of an account that has at least read-access to the repository.

Authentication Headers may also be used in place of other authentication techniques.


GitLab Example

Basic authentication is not enabled by default on gitlab so you are required to setup a token for the repository and pass the token in the Open raw url using private_token parameter. For example:

Navigate to the script in your repository. Click on the Open raw link and copy the contents of the address bar like:<your private token>


Terraform Git Source Example

Terraform Plan Hooks can pull Terraform Plans (.tf files) from remote git repositories, even if the repo is private. Click the Git Connection Info button to create a new Connection Info object and fill in the necessary details.

You will be prompted with an error if CloudBolt cannot reach the specified host.


Follow the link to Connection Info and click New Git Connection Info.

../../_images/new-git-connection-info-button.png ../../_images/new-git-connection-info.png

This creates a new CloudBolt Connection Info which can be treated like any other.

When the Terraform Plan Hook runs, CloudBolt will look through all Connection Infos with the terraform-plan-source label.

Action Input Parameters

CloudBolt will automatically scan user defined actions to determine if additional input is required for the action to be executed. This process is covered in more detail where each of the Action Types are documented. CloudBolt will handle prompting users for those inputs or substituting in pre-designated default values where appropriate. Note that CloudBolt will not create action inputs for template variables that start with the keyword server, like “”{{ server.ip }}”. To see a full list of these context keys provided by CloudBolt, see Action Context.

CloudBolt administrators can customize the input parameters that are auto-discovered, giving them label, description, type, dependencies, and validation constraints. In addition, for CB plug-ins options for the input parameters can be defined in methods within the plug-in, as described in CloudBolt Plug-in Parameterization.

Action inputs can also reference other CloudBolt resources. For instance: If you have a post-provision action to add a server to a load balancer or a back-up schedule by hostname, you can define the default for the “hostname” input parameter to be “{{server.hostname}}”.

Blueprint Action Context

When executing an action as part of a blueprint deployment the entire deployment is available to the action context. If, for instance you have a database server being built, using a BP build item named ‘DB’, you can reference the context of that item in any action by setting an input parameter value to something like “{{blueprint_context.db.server.ip}}”. Besides being converted to lower case, build item names are modified by converting spaces or hyphens to underscores and removing other non-alphanumeric characters. The conversion also strips leading and trailing whitespace.

Action Blueprint Item Context

Key/value pair representing a mapping between the action inputs and the values that should be used on a given execution.

Provision Server Blueprint Item Context

  • quantity: Reference to the number of Server(s) that will be created by this item.
  • os_build: Reference to the CloudBolt object for the OSBuild being used to provision the Server(s).
  • applications: List of references to CloudBolt objects for all applications included in the provisioning.
  • servers: List of references to the CloudBolt Server objects being provisioned in this item.
  • server: Convenient short-cut available if only one server is being provisioned.
  • <parameter_name> for each parameter on the item: To access the value that will be used for the parameter.
  • <preconfig_name> for each preconfiguration on the item: To access the value that will be used for the preconfiguration.

Pod Blueprint Item Context

  • images: Comma delimited string of images to be installed in the container.
  • container_orchestrator: Reference to the CloudBolt object for the Container Orchestrator being used.

Load Balancer Blueprint Item Context

  • source_port: Access the source port that will be used
  • destination_port: Access the destination port that will be used

Sub-Blueprint Blueprint Item Context

The sub-blueprint context includes everything that would be available in the blueprint-context had the sub-blueprint been ordered by itself. If someone orders a blueprint that includes a sub-blueprint called ‘Web Tier’ that includes a server tier and an action, the resulting blueprint-context would look something like:

   "web_tier": {
      "resource_name": "<sub-blueprint resource name>",
      "<sub-blueprint server tier name>": {
          "servers": ["server1", "server2"],
      "<sub-blueprint action name>": {
          "action input 1": "value 1",
          "action input 2": "value 2",

Retrying Actions

All base actions can have a value set for max retries. This means that, whenever the action runs, if it returns a unsuccessful status or raises an exception, it will be retried up to the max retries number of times. This can be helpful if you have an action that needs to interact with a flaky external system that sometimes fails, for example. Note that for CloudBolt plug-ins the retry logic only applies to methods named “run”.

Exporting and Importing Actions

CloudBolt allows actions to be exported as files so they can be easily reused across CloudBolt instances, or shared in the CloudBolt Forge, a repository of sample CloudBolt resources. Exported actions are typically stored as zip files containing JSON-formatted metadata about the action along with any scripts associated with the action.

When exporting, you can choose between a sanitized or instance-specific version of your action. The formats are the same, but the sanitized version will omit potentially sensitive information such as script credentials, environments, and groups. This makes sanitized versions great for sharing actions on the CloudBolt Forge, or for moving them between CloudBolt instances that don’t have the same groups and environments.

You can import actions in the UI wherever you can create new actions. Note that actions can only be imported in the same context from which they were exported. For example, to import an action as a server action, the action must have been exported from the Server Actions page.

The CloudBolt Forge contains a variety of shared resources you can use to make CloudBolt more powerful. Actions in the CloudBolt Forge are stored unzipped so you can easily browse their contents. To import one of these actions, zip the folder containing the action’s files before uploading.

Actions can also be imported using the CloudBolt API. The sample API scripts included with CloudBolt have an example of how this can be done.


It’s worth noting the way some objects related to an Action are addressed when importing an Action. In cases such as constraints, an instance-specific export will generally include the name of the related object. Import will search for an object with the same name, and set it as a constraint on the object if it exists. This may be imperfect, for example if you have 2 Groups with the same name, and does not guarantee that everything about the constraints will have been preserved when importing to a new CloudBolt (e.g., the quotas or permissions may be different on the Group). It’s always a good idea to double-check your results after import.