Domains are used in DeployHub to catalog and publish public and private services.  Domains organize reusable objects based on your needs.  Domains can represent functional areas such as ‘security services’ or departments, teams, and software projects. Domains are represented within the DeployHub tree-structure interface by a ‘world’ icon. There are four types of Domains:

Site Domain

This is the highest-level organizational structure.

SaaS User

Your Site Domain will be defaulted to the Project name you entered when you registered. You can rename your Site Domain if needed.  

On Premise Installation

Your default Site Domain name is “Global.” You can rename your Site Domain if needed.

Division Domain

DeployHub Pro User

Division Domains are used by larger companies to define an organizational structure that closely represents how they do business, such as geographical areas, organizational responsibility, or business units.  A Division Domain is a folder of other Sub-Division Domains and Project Domains. Division Domains can create as many Sub-Division Domains as needed. In addition, objects defined to a specific Division Domain can be secured with specific User Groups.  

DeployHub Team User

Division Domains are not available in the DeployHub Team version.  

Project Domains

You assign your software project to a Project Domain. You can create as many Project Domains as needed. Project Domains cannot have child Sub-Project Domains, but they do have Life Cycle Sub-Domains.  

Life Cycle Sub-Domains

This Sub-Domain defines the stages in your Delivery Pipeline. Only Project Domains can have Life Cycle Sub-Domains. You create Life Cycle Sub-Domains to map to each stage in your continuous delivery Pipeline. Life Cycle Sub-Domains allow you to automate the push of your continuous deployments from development through production. DeployHub can be called by your Continuous Delivery Engine (Jenkins, Bamboo, GitLab or GitHub Actions) to perform the continuous deployment across all states of your pipeline. If you are not using a Continuous Delivery orchestration engine, you can assign Tasks to your Life Cycle Sub-Domain to define a continuous delivery process.

You can create as many Life Cycle Sub-Domains as you need for each of your Project Domains. You can also rename Life Cycle Domains if your Pipeline changes. Lifecycle Sub-Domains can be dragged and dropped in their General tab to rearrange their top-to-bottom execution order within the Domain where they exist. Rearranging Lifecycle Sub-Domains allows users to manage and organize the visual representation of their Continuous Delivery Pipeline.  Lifecycle Sub-Domains are represented by a circular multi-object icon under your Project Domain tree-structure.

Top Down Domain Structure

A Divisional Domain inherits all the access properties from its parent Global Domain. Any child  Divisional Domains will inherit its parent Divisional Domain’s access rights. This continues down through all Project Domains and Life Cycle Sub-Domains. All inherited access properties are shown within the Access lists with each Group name highlighted in yellow. All Groups in lists that were added in that Domain, and not inherited, will be shown in the list without highlighting.

Life Cycle Sub-Domains and your Delivery Pipeline

The Delivery Pipeline contains all information for a Domain concerning the deployment of Applications and their movement through the Life Cycle Sub-Domains contained within. It is designed to show and keep track of the procession of Applications through the continuous delivery pipeline, as well as the deployment of Applications into Environments. Keep in mind that when dealing with software lifecycles within DeployHub, parent Domains contain Lifecycle Domains, and these contain Applications and Environments. The Move, Deploy, and Request Tasks discussed in this section are utilized in the tree structure by right clicking on the Applications within Lifecycle Domains. The results are viewed in the Delivery Pipeline tab for the parent Domain.

Creating and Deleting Domains

New Divisional Domain: (DeployHub Pro only) Go to the Domains Menu tab. To create a Divisional Domain right click on your Global Domain at the top of the DeployHub window.  Select the “Create new Sub-Domain in this Domain.” A new Divisional Domain will be created with a default name. Click on the pencil icon on the far right to edit it, including the name.

New Project Domain: Go to the Domains Menu tab. To create a Project Domain right click on your Divisional Domain at the top of the DeployHub window. Select the “Create new Sub-Domain in this Domain.” A new Project Domain will be created with a default name. Click on the pencil icon on the far right to edit it, including the name.

Delete this Sub-Domain: Go to the Domains Menu tab. Select the Domain that you want to Delete. Right click on the Domain for the “Delete this Sub-Domain” option. A message box will appear showing the objects that are associated with the Sub-Domain that prevent it from being deleted.

Deployment Engines and Domains

Deployment engines do the heavy lifting of transferring files to Endpoints and performing the installation logic.  

  • For On-Premises Users - The Engine Hostname field defaults to ‘Default Engine’, which tells DeployHub to use that deployment engine for that Domain and Sub-Domain, unless defined at the Sub-Domain level. The name can be changed to a different deployment engine.
  • For SaaS users - your reverse proxy runs your deployment engine. If you need multiple deployment engines, contact support for the installers.

Multiple deployment engines can be used to distribute the deployment processing for large data centers with hundreds of Endpoints. Each Domain can be assigned a unique deployment engine. From the Domain General tab, the Engine Host Location refers to the location of the process that executes the deployment’s installation activities. You can install the deployment engine on separate host servers to distribute the workload across multiple host locations, and the high-level Domains and child Sub-Domains can all have unique engines. All deployments to the Environments defined to the Domain and its Sub-Domains will be processed by the host engine defined at that level.

Editing a Domain or Sub-Domain

To the right of the tree structure are several tabs which allow the User to view and edit the Domains attributes. These are explained below, along with the fields contained in each tab, and an explanation for the use and functions of each.

Tasks Tab

Domains can have Tasks assigned to manage the Application Versions contained within. Tasks are most commonly assigned to the Life Cycle Sub-Domains and are most commonly used to define a continuous delivery process. Tasks can be assigned to any Domain or Sub-Domain. Task execution rights can be assigned to User Groups. Only users who are members of one or more of the assigned User Group(s) can execute the Task. DeployHub Team has no execution rights over Tasks.

Tasks are defined for each Domain. By checking the Available in Sub-Domains checkbox then the Task is made available to every Sub-Domain or Life Cycle Sub-Domain below the Task's Domain in the hierarchy.

Once the Tasks are defined for a Domain, they will be available by right clicking on the Applications tree structures. A right click on the Release Version from the tree structure will display a pop-up menu displaying the Tasks that can be performed against the corresponding Application Version.

The contents of the pop-up menu are context sensitive and are based on:

  • For DeployHub Pro, the invoking user's group membership. Only tasks that are available to the User Groups of which the invoking user is a member are displayed.
  • The selected object. For example, the Create Version task is only available when a Base Application is selected and not an Application Version.

There are 7 different types of Tasks:



Move Version

Moves an Application Version from one Domain to another. This is typically used as a promotion or a demotion of an Application Version between Life Cycle Sub-Domains. When the Task is defined, the Target Domain has to be specified as part of the Task definition.

The selected Application Version has to be approved for the Target Domain before the Move Version to that Domain will succeed. Once the Move Version Task has been approved by the Approval Task, the Application Version can be moved back and forth between the two Domains until the Application Version has been rejected through the use of the Approval Task.


Deploys an Application Version to an Environment. The target Environment is selectable via a drop-down list.


For DeployHub Pro - When a User needs to run a Task but doesn’t have access to it, a Request Task is used to ask those with access to the Task to run it.

When the Request Task is executed an entry is placed into the "To Do" list of all the Users who are members of the User Group(s) which have execute access to the Linked Task. When the Linked Task is executed by one of the Users with access, the request is removed from all of the Users "To Do" lists.

The Request Task can have a Request Notification Template defined which can send out a notification to the appropriate User Group(s) when it is executed or that it needs to be performed.


Approves a Request Task so that its linked Task can be executed within a specified Domain. For example, in DeployHub Pro, a User that belongs to a Group with the authority, via a Move Task, to move a particular Application to a specified Domain can do so, but a User in a Group that has not been assigned the authority for this Move Task must request approval from someone in a Group that does have the authority. When the User with the authority receives the request, that User can run an Approval Task, which will then allow a User with access to move the Application to the target Domain. Keep in mind, if an Approval Task exists within a Domain, it must be run before any Move Tasks can be executed to move an Application Version into the specified Domain.

Remove Application

Removes the Application Base Version from an Environment, by rolling back from the currently installed Application Version. All files are removed, and all Rollback Actions are executed for each Application Version between the Version installed in the Target Environment and the Application Base Version. The Rollback Action associated with the Application Base Version is then executed. (Normally, when rolling back to the Application Base Version, the Rollback Action is not executed, and the Application Base Version remains deployed.)

A Remove Application Task cannot be executed against an Application Version, only an Application Base Version.

Create Version

Makes a new Application Version from either an Application Base Version or a specific Application Version, depending on the choice made by the User. The Domain where the new Application Version is created can be chosen in the Create Version in Domain field.

Run Action

Runs a stand-alone Action. It will be available only in the Domain or Life Cycle Sub-Domain where it is created, unless the ‘Available in Sub-Domains’ checkbox is selected. The Task can be selected by right clicking on the Domain or Life Cycle Sub-Domain or by right clicking on an Application. In the latter case, the selected Application is automatically placed onto the stack where it is available for the Action to process. See DMScript documentation and the discussion on Actions for more information.

Adding and Editing Tasks in the Lifecycle States or Domains

You can create as many Tasks as necessary in a Domain or Life Cycle Sub-Domain. Tasks can be renamed to reference the unique purpose of the Task, for example ‘Deploy AR to Dev’. You can add new Tasks to a Domain by first selecting the Task Tab. Right click anywhere in the ‘Tasks in the Domain’ selection dialog. The right click will display the list of available Task Types.  Select the Task Type you require, and it will be added to the list of Tasks for the current Domain. The Task will be created with a default name based on its type along with a number to make the name unique. It is recommended that the newly created Task be renamed to something more meaningful than the default name. You can edit the new Task by selecting the Task and using the pencil icon found in the right-hand corner of the window. Tasks will have the following options:




The name of the Task.


The Action to be executed before the Task is run.


The Action to be executed after the Task is run.

<approve/move/create in>Domain

Optional depending on the type of Task, this is the target Domain for the Approve, Move, or Create Task.

Show Output

When selected, a log will be shown after the Task has executed.

Linked Task (Request Task Only)

When a User, who can’t execute the Task, requests another User with access to run.

Available in Sub-Domains

Makes the Task available to all Sub-Domains under the current Domain.

Success Notification Template

Notification to be sent if the Task succeeds.

Failure Notification Template

Notification to be sent if the Task fails.

Action to Run

For Run Action Tasks, the action to execute when the Task is run.

All Tasks created are available in a drop-down list using a right mouse click from the Component, Application, or Release tree structure. This allows you to perform these actions against a Component Version, Application Version or a Release Version.  Run Action Tasks can also be invoked by right-clicking on the Domain or Life Cycle Sub-Domain.

Pre and Post Task Actions

Assigning Pre-Actions and Post-Actions to Tasks adds versatility to them, allowing such things as prerequisite checking and clean-up operations to take place before and after the execution of a Task. You can create any type of Action by going to the Flows Menu option and adding an Action. Any Actions created for the Domain and any Parent Domains will be available in the Pre and Post Action drop down box.

A Pre-Action will be executed before the Task is run. If the pre-action fails in some way (either by returning a non-zero exit code or by aborting) then the Task is not executed. This can be used for validity checking.

A Post-Action will be executed after the Task is run. The Post-Action is always executed regardless of whether the Task itself has run successfully.

Task Execute Access

Once a Task is defined, it must be granted execute access before it can be invoked. To do this, select the Task from the Tasks in this Domain area and drag the desired User Group(s) from the Available Groups column to the Group Access area. Users who are members of the User Group(s) in the Group Access area will be allowed to execute the specified task.

Keep in mind that Groups are assigned authority on a Task by Task basis, so that it is possible for a Domain to have two different Tasks that perform the same function, one of which allows a particular Group to run the Task, and the other which doesn’t. This allows similar Tasks to be created that have different characteristics assigned to them such as Pre-Actions and/or Post-Actions, Notification Templates, etc., with different User Groups having authority to run them.

Example: A Group is given the ability to run a Move Task which moves an Application Version from the Test Lifecycle State to the Production Lifecycle State, but a Group consisting of testers does not have the ability to run that same Task.

Example: A Move Task is linked to a Request Task. A User in the Test Group would run the Request Task, which notifies Users in the Release Group and requests that the Application Version be moved. Users in the Production Group would then receive the Request Task through their home page (click on the ‘house’ icon on the upper right of the DeployHub window) and optionally an email (which was designated as the Request Notification Template in the Request Task). They would then run the linked Move Task to move the Application Version to the Production Lifecycle State.

NOTE: Another way to accomplish this is to link an Approval Task to the Request Task. The User in the User Group would send the Request Task, and a User in the Admin Group would be notified. They would then run the Approve Task to allow the User in the Test Group to run the Move Task.

NOTE: DeployHub Team has only two Groups, Administrators and Users. Deployhub Pro can have unlimited User Groups.

Additional Parameters

Additional parameters can be added to a Task by clicking the plus icon in the lower right corner. A window appears that allows the entry of a Label, a Variable, and a Type.

  • Label: This will appear on the Task’s execution window whenever the Task is executed.

  • Variable: An Entry, Password, or Dropdown field appears to the right of the Label whenever a Task is executed, where values can be either entered or selected, depending on the Type.

  • Type: A value is entered if it is an Entry or Password field type field (a Password type field shows the entered characters as bullet points), or the value is selected from the list if it is a Dropdown. If Dropdown is selected from the list of available Types, another field will appear and the name of an array that contains the list values can be entered.

Additional Parameters are stored in Global variables that can be referenced anywhere within DeployHub during the execution of the Task. This is particularly useful during deployments where Pre and Post Actions are executed at the Component and Application levels.

Access Tab

Domains, their contents and their Sub-Domains are protected from unauthorized use and change via the Access tab. This tab contains four lists, each of which grants a different type of access to Users who belong to the User Groups contained in the list. A fifth list contains a list of all User Groups, which can be dragged and dropped into each of the other four lists. By default the Everyone Group is assigned to each group at the GLOBAL domain level and this permission is then inherited by all Sub-Domains and Lifecycle States. To restrict Access, remove the Everyone Group from the desired Group list, and add only the Groups that should be given the appropriate access to the Domain.

These four types of access are as follows:




If a User doesn’t belong to a User Group in the View Access list for the Domain, that Domain will not appear in the tree structure. This keeps unauthorized Users from seeing the Domain and helps simplify each User’s view of the DeployHub system.


This allows a User who belongs to any User Group in the list to change the attributes of the Domain as well as to add/remove Tasks from the Domain.


Performs no function for the Domain itself but acts as an Inherited Permission for objects created within the Domain. The exact meaning of "Read" will depend on the object created within the Domain.


Performs no function for the Domain itself but acts as an Inherited Permission for objects created within the Domain. The exact meaning of "Write" will depend on the object created within the Domain.

General Tab

The General tab contains fields with basic information for the selected Domain. Information can be changed by clicking on the edit pencil in the upper right-hand corner.




The name of the Domain, which can be changed.

Parent Domain:

The Domain in which this Domain is located. It cannot be changed.


A short text field containing general information about this Domain.


A dropdown list of Users or Groups that can be selected as the owner. The default owner is the User who created the Domain. When editing this field, the Owner Type field is available which includes Owner and Group as choices. Selecting one of these causes the Owner field to display either Users or Groups to choose from.


The date and time the Domain was created. Cannot be changed.


The date and time the Domain was last changed. Cannot be changed by the user.


DNS name of server where the DeployHub deployment engine is installed.  This defaults to the original installation server and can be changed to point to another server for distributed processing. It defaults to ‘Deployment Engine’, which indicates the engine is on the original server where DeployHub was installed.

Contains Lifecycle States

Shows if the Sub-Domain are Lifecycle States with no further Sub-Domain.

Sub Domains

A list of all child Sub-Domain or Lifecycle States.

Creating a Life Cycle Sub-Domain

NOTE: All Domains in DeployHub Team are Project Domains except for the high-level Site Domain.

When you set the Sub-Domain to include Lifecycle States from the Domain Edit dialog, you define that Domain as a Project Domain with all further child Sub-Domains to be Lifecycle Sub-Domains. They will all exist at the same level of the Domain hierarchy. Life Cycle Sub-Domains are a type of child Sub-Domain that allows the parent Sub-Domain to be defined to have a Lifecycle process for Continuous Delivery. Lifecycle processes allow for the management of the flow of the Application as it moves through various states within the enterprise, such as from Development through Production.

In order to create a Life Cycle Sub-Domain, edit the Sub-Domain by highlighting it in the tree structure and select the pencil icon in the right-hand corner. Select the Contains Lifecycle checkbox in the edit dialog. This will now restrict the addition of any lower level Sub-Domains, and instead allow you to create Life Cycle Sub-Domains. A Life Cycle Sub-Domain cannot have a child Sub-Domain. The icon for the newly created Life Cycle Sub-Domain will change from a world to a flowchart, indicating that this is now a Life Cycle Sub-Domain. You can re-order the Life Cycle Sub-Domains by selecting the higher level Sub-Domain General Tab. Edit the Sub-Domain by selecting the pencil icon in the right-hand corner. This will bring you to the Edit General dialog box. You can drag and drop the Life Cycle Sub-Domains to re-order them.