Following are the basic terms and concepts you need to configure your deployments using DeployHub. They are organized here in order of importance.


A software product to be deployed by DeployHub is represented by an Application. Applications are organized under a Domain structure. An Application’s Project Domain can contain Life Cycle Sub-Domains that map to your Continuous Delivery Pipeline.

Life Cycle Sub-Domains and Continuous Delivery

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 task 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 within DeployHub.

Delivery Pipeline

A Delivery Pipeline appears when a Domain containing Life Cycle Sub-Domain has been selected. The Delivery Pipeline contains all information for a Domain concerning the deployment of Applications and their movement through the Life Cycle Sub-Domains within it. It shows and keeps track of the procession of Applications through the continuous delivery pipeline, as well as the deployment of Applications into Environments. Your Delivery Pipeline can contain any number of Tasks.


Tasks are associated to any Domain and can be defined as Pre or Post. Tasks are most commonly defined to Life Cycle Sub-Domains and become part of your continuous delivery process.


Your software project will be defined by an Application. An Application is a collection of Components that make up a complete software release, including database objects, binary objects, microservices, infrastructure, and environment variables. An Application can also be thought of as a software ‘Project’ and may map directly to your version control repository. However, in DeployHub, your software project’s Components can come from many different locations if needed. Applications are managed under the Deploy Main Menu item.


Components are grouped together under an Application (binaries, database, microservices, etc.). Components are deployed objects called Component Items. Components also include Procedures, Functions, and Actions. These are executed to perform the deployment step for that Component Item such as creating directories, moving and copying files, updating a databases table, changing an environment variable or other similar tasks required for installing that Component. Components are managed under the Deploy Main Menu item.

Deployment Versioning

DeployHub uses a back-in versioning engine to track all configurations of your software deployments. Your software deployment is configured within an Application. An Application consists of one or more Components. Versioning tracks all changes in both your Application and Component attributes including low level information such as the Action used to perform the installation, environment variables, and database schemas.

When you first define your Application to DeployHub, you create an Application Base Version. Over time, as you update your code and deliver new features, each change to the Application creates a new Application Version. Application Versions package together all your Components that make up your entire software product. Like Application Versions, there is an initial Component Base Version and subsequent Component Versions, which represent the updates over time. An Application Base Version or Component Base Version is always the first one created, and it acts as a model for subsequent Application or Component Versions. Otherwise they are identical types of objects.

When a new Application Version is created from either an Application Base Version or another Application Version, it inherits all previous Components from its predecessor. The predecessor is determined when running a Create Version Task for an Application Version. You can specify whether the new Application Version inherits its Components from the original Application Base Version, the latest Application Version, or a specific Application Version.

DeployHub uses a simple versioning number schema starting at 1 and incrementing over time, for example  Myapp;1, Myapp;2.  

Rolling Forward, Back, or Version Jumping

When you define your Application and its Component, you specify the logic for installing, rolling forward, or uninstalling, rolling back. Some Component Types can be defined to include both a “Roll Forward” or “Rollback” logic. Not all Component Types need a Rollback. For example, a Database will need the logic to back out a change to a schema update. A binary will only need a previous binary to replace it – no uninstall logic is required.

When an Application is deployed to a target Environment, DeployHub loops through each Application Version between the one recorded as being on the target Environment and the one being deployed. For each "interim" Application Version, a check is made for any associated Components that have Component Items marked as "roll-forward" or "roll-back". If any are found, those Components are deployed automatically. Only the Component Items marked as "roll-forward" are used when deploying a newer Application Version. Similarly, only the Component Items marked as "rollback" are used when deploying an earlier Application Version than that recorded as being in the target Environment. This technique allows "deltas" to be applied in sequence for accurate iterative software deployments critical in Agile practices and required in the Kubernetes microservice architecture.

You can roll Versions forward, backward, or even jump between any two versions. For example, you can jump from Version 4 to Version 10 and DeployHub deals with all incremental updates.

Component Items and the Repository

Each Component Item contains a pointer to where an artifact is stored in a Repository or on a file system. When DeployHub performs the pre-deployment steps, it will retrieve the artifact from any location you specify. It pulls that artifact from the repository and creates a deployment package at deployment runtime. For this reason, it doesn’t need to store the actual artifact in the DeployHub versioning engine. Each Component Item is defined with a Repository reference. Your Repository can be any versioning solution such as Git, Subversion and Perforce, or binary repository such as Maven. A Repository can also reference a file system.

The Application’s Environments and Endpoints

DeployHub sends an Application Version to numerous container, virtual and physical Endpoints simultaneously through the use of Environments. An Environment is a DeployHub object which acts as a collection of Endpoints. An Endpoint is a DeployHub object that represents a single container, virtual image, or physical server in an enterprise’s IT environment targeted for deployment. An Endpoint can be assigned many different Environments, and an Environment can contain many different Endpoints.  

Component Types and Endpoint Mapping

Each Component is assigned a Type attribute. The Type attribute allows you to specify to what kind of Endpoint that the Component should be installed. For example, a Database Component is installed onto an Endpoint that has the corresponding Database Type definition. A Component is assigned a single Type, while an Endpoint can be assigned multiple Types. For example, if your single Endpoint needed to have both a database and your application binaries installed, it would be assigned both a ‘Database’ and an ‘Binary’ Type attribute.

Mapping of Component to Endpoints is accomplished by assigning one or more Component Types to each Endpoint and assigning a single Type attribute to the Component. When an Application is deployed, each Component within the Application will be deployed to each Endpoint as long as the Component’s Type attribute matches one of the Endpoint’s Types attributes.

DeployHub ships with standard Endpoint Types (Database, EAR, Application File, etc.), and allows you to define custom Type attributes.

Component and Application Relationships

There is a many to many relationship between Applications and Components, so that an Application can contain many different Components, and a Component can be used across many different Applications. With DeployHub, Components can be easily shared between Applications. DeployHub tracks and versions the Component relationships including to which Applications they have been assigned.

Components and Microservices

Components map directly to an individual microservice. If you are building a continuous deployment process that deploys your microservice to a container, you will define your microservice as a Component. If you want your microservice Component to be shared across your teams, you will need to move your Component to the highest level in your DeployHub hierarchy. If it is defined to only your Application, then only your team will be able to see it.

Component Deployment Ordering and Logic

Applications are deployed along with all of their Components. The deployment order is determined by how they are linked together using the Blueprint Designer within the Components tab of the Application. These Components each contain Component Items that are also deployed in a predetermined order.

Deployments can be controlled programmatically at several levels throughout the deployment process, including at the Component level. Components can have Actions assigned to them that can be run before and after their Components Items have been deployed. A Custom Action allows a component to be deployed by an external tool such as Ansible or by internal scripting. Actions contain Procedures and Functions which are linked together in order to control the various parts of a deployment.

A Procedure or Function can be defined as:

  • A DMScript running locally to the DeployHub Server. Procedures and Functions written in DMScript have access to the DeployHub Object Model along with the various built-in methods for connecting to external systems.
  • An "external" script running locally to the DeployHub Server.
  • An "external" script running on the Endpoint to which the deployment is taking place.
  • An "external" script which is located locally to the DeployHub Server but which is "pushed" to the Target Endpoint automatically and execute there.


Credentials are objects within DeployHub that contain username and password pairs for accessing the various object. These will be used to retrieve files, access Endpoints, execute actions, and deploy files. Each Credential can be assigned to various objects within DeployHub, so that a single Credential could be assigned to many Endpoints if they all use the same username/password pair. Credentials are primarily used for accessing Endpoints, but can be applied to any object in DeployHub requiring a user name and password to access.

Data Sources

There may come a time when the need to acquire data outside of the DeployHub system becomes a necessity, such as an ODBC connection to Oracle. The Data Source object in DeployHub is available for communicating with various sources of information such as databases, HTTP servers, FTP servers, etc., and can be used to take advantage of this kind of information, as well as many others.


A Notifier is sent to various recipients after a successful or failed deployment attempt. They are also sent when deployed files have been changed, a Request Task has been used, or that an Endpoint is down, if these features have been activated on one or more Endpoints. Notifiers can be found under the Notifiers tab, which is under the Flows menu. DeployHub can use SMTP (Simple Mail Transfer Protocol), Slack and HipChat for this purpose. A Notifier contains all of the technical information necessary to send notifications.


A Release is only available in DeployHub Pro. A Release is a collection of Applications that must be deployed together, sometimes referred to as a ‘Release Train.’


A Timeline contains a complete audit history of any changes applied to Environments, Endpoints, Applications, and Components. An Application’s Timeline shows all deployments that occurred. Comments and documents are also added to a Timeline.


You can subscribe to Environments, Endpoints, Applications, and Components. If your User Group has ‘Read’ access to these objects, you can subscribe to follow the activity and changes of any of these objects.

Reverse Proxy

A Reverse Proxy is used for SaaS users to add additional security to the hosted option. The Reverse Proxy is installed on the inside of your firewall and contacts the DeployHub SaaS database to determine if a deployment is ready. The Reverse Proxy is also a Deployment Engine.

Deployment Engine

The work of managing deployment workflows is done by a Deployment Engine. The Deployment Engine is included in your on-premise installation of DeployHub. If you are a SaaS user, this is part of your Reverse Proxy. You can run multiple Deployment Engines to scale extremely large deployments.


DeployHub speeds up software deployments by using a file location to perform any pre-processing of the deployment, such as retrieving the need artifacts from a Repository. This work is performed on the Reverse Proxy Deployment Engine, or for on premise installations, on the Deployment Engine.