Traditional Deployments

Updated 4 weeks ago by Michael Cretzman

This guide discusses how to perform traditional deployment using application package files and a runtime environment (Tomcat, JBoss) in Harness. These deployments are different from Harness deployments using container orchestration platforms like Kubernetes, Helm, Pivotal Cloud Foundry, Amazon ECS, and Azure.

Traditional deployments involve obtaining an application package from an artifact source, such as a WAR file in an AWS S3 bucket, and deploying it to a target host, such an AWS AMI.

This topic covers the following:

Deployment Summary

For a general overview of how Harness works, see Harness Architecture and Application Checklist.

The following list describes the major steps we will cover in this guide:

  1. Installing the Harness Delegate in your target infrastructure.
  2. Add an Artifact Server. In this guide, we will use an AWS S3 bucket containing the file we want to deploy.
  3. Add a Cloud Provider. This is a connection to your deployment infrastructure, either physical or hosted in a cloud platform like AWS, GCP, or Azure.
  4. Create the Harness Application for your deploying your file(s). The Harness Application represents a group of microservices, their deployment pipelines, and all the building blocks for those pipelines. Harness represents your deployment using a logical group of one or more entities: Services, Environments, Workflows, Pipelines, Triggers, and Infrastructure Provisioners. Applications organize all of the entities and configurations in Harness CD.
  5. Create the Harness Service using the SSH type.
    1. Add your packaged application file(s) as an Artifact Source.
  6. Create the Harness Environment containing the Service Infrastructure definition of your deployment infrastructure.
  7. Create the Basic Deployment Workflow.
  8. Deploy the Workflow.
  9. Advanced options not covered in this guide:
    1. Create a Harness Pipeline for your deployment, including Workflows and Approval steps. For more information, see Pipelines.
    2. Create a Harness Trigger to automatically deploy your Workflows or Pipeline according to your criteria. For more information, see Triggers.
    3. Create Harness Infrastructure Provisioners for your deployment environments. For more information, see Infrastructure Provisioners.

Supported Packaging Formats

Harness supports the following traditional deployment packaging formats: WAR, JAR, TAR, RPM, ZIP, Docker, and custom files.

All of these formats are also supported by other Harness deployment types, such as Kubernetes, Helm, PCF, ECS, etc.  This guide is concerned with traditional deployments outside of the container orchestration platforms.

Harness Delegate

The Delegate needs to be able to connect to the artifact server or repository containing the file, and the target host where the file will be deployed. Typically, the Delegate is installed on a host in the same subnet as the target host.

For steps on installing the Delegate, see Delegate Installation and Management.

For AWS, you can install the Delegate on an EC2 instance and then have the Harness Cloud Provider assume the IAM role used by the Delegate host. For more information, see Delegate Tags.

Artifact Server and Cloud Provider

Harness retrieves the package file from an artifact source using a Harness Artifact Server and deploys it to the target host using a Cloud Provider. For steps on adding these connections, see:

If the artifact is hosted on a cloud platform, such as AWS or GCP, you can use a Harness Cloud Provider for both artifact retrieval and deployment to the target host.

For example, if your artifact file is in an AWS S3 bucket and you are deploying it to an AWS EC2 instance, you can simply use one AWS Cloud Provider.


The Harness Service contains the application package artifact (file or metadata) and the related commands to execute on the target host.

To create a Service for an application package, do the following:

  1. In your Application, click Services, and then click Add Service. The Add Service dialog appears.
  2. In Name, enter a name for the Service. You will use this name when selecting this Service in Harness Environments, Workflows, and other components. For more information, see Services.
  3. In Deployment Type, select Secure Shell (SSH). All file-based Services are Secure Shell (SSH) deployments.The Artifact Type and Application Stack settings appear.

  1. In Artifact Type, select the file type of your artifact. For example, Java Archive (JAR).
  2. In Application Stack, select the app stack you want to use to as a runtime environment for your application, such as Tomcat. If you are deploying to an existing instance that already has an app stack installed, you can leave Application Stack empty. For more information, see Application Stacks.
  3. Click SUBMIT. The new Service is created.

The Service page has the following important sections:

  • Artifact Source - The package files you want deployed are added here. In some cases an actual file is obtained, but in most cases metadata is sufficient.
  • Artifact History - You can manually pull metadata on your artifacts to see their builds and versions.
  • Script - The scripts to set up your files. These will typically include application stack setup unless your target hosts already have the application stack set up.
  • Add Commands - You can add new commands from an Application or Shared Template Library, or simply add a blank command and add Harness scripts to it.
  • Configuration - You can add variables and files to use in your Service scripts. These can be encrypted by Harness, allowing you to use secrets. The variables and files can be overwritten in Environments and Workflows.

Artifact Source and History

The Artifact Source for the Service lists the file(s) that you want copied to the target host(s). The Artifact History will manually pull artifact build and version metadata from the Artifact Source.

Before you can add an artifact source, you need to add a Harness Artifact Server or Cloud Provider. If your artifact files are located on cloud platform storage like AWS S3, GCP Storage, or Azure Storage, you can add a Cloud Provider. If the files are located in a repo such as Artifactory or an automation server such as Jenkins, you can create an Artifact Server.

For more information, see Add Artifact Servers and Add Cloud Providers.

Add an Artifact Source

To add an artifact source, do the following:

  1. Click Add Artifact Source, and select the repo or cloud platform where the artifact is located. The dialog for the artifact source appears. This guide will use AWS S3 as an example.
  2. In Cloud Provider, select the Harness Cloud Provider to use to locate your artifact file.
  3. In Bucket, select the name of the bucket containing your artifact.
  4. In Artifact Path, click the artifact Harness located in the bucket you selected in Bucket. If the artifact is at the root of the bucket, then just the filename is provided. If the artifact is in a folder, the file path is provided also.

    The Metadata Only option will be available if the artifact source file can be downloaded, and unavailable if the Harness only needs the metadata to download the file on the target host. Metadata is sufficient as it contains enough information for the target host(s) to obtain or build the artifact. Harness stores the metadata. During runtime, Harness passes the metadata to the target host(s) where it is used to obtain the artifact(s). Ensure that the target host has network connectivity to the Artifact Server. For more information, see Service Types and Artifact Sources.

    When you are done, the dialog will look something like this:
  5. Click SUBMIT. The artifact source is listed.

View Artifact History

When you add an Artifact Source to the Service, Harness will pull all the build and version history metadata for its artifacts. You can see the results of the pull in Artifact History and, if you do not see a build/version you expected, you can manually pull them.

To view the artifact history,  do the following:

  1. Click Artifact History. This assistant lists the artifact builds and versions Harness has pulled.
  2. In the Artifact History assistant, click Manually pull artifact.
    The Manually Select An Artifact dialog appears.
  3. In Artifact Stream, click the Artifact Source you added to the Service.
  4. In Artifact, select an artifact build/version, and then click SUBMIT.
  5. Click Artifact History to view the history.

Now all available artifact builds and version history metadata is displayed.

Application Stacks

If the target hosts you will deploy your files on do not have an application stack installed already, you can add an application stack as part of your Harness deployment.

Use an Application Stack

To use an application stack, do the following:

  1. To add an application stack to Harness, follow the steps in Add Application Stacks.
  2. When you create your Service, select the Application Stack in the Add Service dialog's Application Stack setting.

When the Service is created, it contains the scripts need to install the application stack.

Application Defaults

You can define Application-wide variables that can be referenced in any entity within an application. The Application Defaults include the paths for runtime, staging, and backup used by the scripts in the Service.

For example, here is the Application Defaults dialog, the Copy Artifact script in the Service using the RUNTIME_PATH variable and the Tomcat application stack webapps folder, and the resulting file path for the deployed artifact on the target host:

For more information, see Application Default Variables.

To create Application Defaults, you must be logged into Harness as a member of a group that has create or update permissions for that application.

The Application Default are used throughout the scripts in the Service. Here is an automatically-generated Start Service script that uses the RUNTIME_PATH variable to start Tomcat.

Commands and Scripts

When you create the Service, Harness automatically-generates the command and scripts needed to install the application stack on the target host, copy the file(s) to the correct folder, and start the application stack.

Add Commands and Scripts

You can add commands and scripts using the Add Command settings, and by clicking the plus icon in the commands.

All of the scripts include tooltips to explain how to use them:

Script Execution Order

When you look at the default commands in a file-based Service their order of execution might be confusing. For example, it looks like they are executed like this: 

But the are actually executed like this: 

The order is clearer when you see the deployment in the Deployments page:


Download Artifact and Exec Scripts

The Download Artifact script is supported for Amazon S3, Artifactory, and for PowerShell, the SMB and SFTP artifact sources. For other artifact sources, add a new command and use the Exec script to download the artifact. For more information, see Exec Script.

Harness and Custom Variables

You can use Harness built-in variables in your Service scripts, or add your own variables and reference them in your scripts.

For information on Harness built-in variables, see Variables and Expressions in Harness. For information on using variables in your scripts, see Configuration Variables and Files.


Environments represent one or more of the deployment infrastructures where you want to deploy your application package files. Within an Environment, you add a Service Infrastructure for each specific deployment infrastructure, using a Cloud Provider and the specific infrastructure details for the deployment, like VPC settings.

This section covers adding a Service Infrastructure for a file-based Service.

For details on creating an Environment, see Environments.

Service Infrastructures

When you add a Service Infrastructure, you will specify the Service to deploy, the Cloud Provider to use, and the infrastructure details. For the example below, we will create a Service Infrastructure for a WAR Service using an AWS Cloud Provider, and we will specify the AWS infrastructure settings for the target AWS VPC and host.

To add a Service Infrastructure, do the following:

  1. In your Harness Application Environment, click Add Service Infrastructure. The Service Infrastructure dialog appears.
  2. In Service, select a file-based Service, such as a WAR Service.
  3. In Cloud Provider, select the Cloud Provider you set up to connect Harness to your deployment infrastructure.
  4. Click Next. The Configuration section appears.

    The Configuration section will look different depending on the Cloud Provider you selected. For example, for an AWS Cloud Provider, you will see AWS-specific settings, such as Region and Auto Scaling Group. When you select a region, more settings appear, such as VPC and Tags.
  5. Provide the settings for your infrastructure. For example, here are the settings for an AWS infrastructure that identify the target host using AWS EC2 Tags.
  6. When you are finished, click SUBMIT. The Service Infrastructure is added.

Now that you have defined the deployment infrastructure, you can create a Workflow to deploy your Service to it.


When you set up the Service Infrastructure in Harness to identify the target host(s) where your file will be deployed, you also add Connection Attributes that use a Harness SSH Key secret. This key is used by the Harness Delegate to SSH into the target host.

For more information, see Secrets Management.

Basic Workflows

The Basic deployment Workflow is the most common Workflow type for traditional, package file-based deployments. Basic Workflows simply select nodes in the deployment infrastructure and install a Service.

To create a Basic Workflow for a traditional deployment, do the following:

  1. In your Harness Application, click Workflows.
  2. In Workflows, click Add Workflow. The Workflow dialog appears.
  3. In Name, enter a name for the Workflow.
  4. In Workflow Type, select Basic Deployment.
  5. In Environment, select the Environment where the Service Infrastructure you defined for your deployment is located.
  6. In Service Infrastructure, select your target Service Infrastructure. When you are finished, the dialog will look something like this:
  7. Click SUBMIT. The Workflow is created.

Let's look at the two default steps in the Workflow, Select Nodes and Install.

Select Nodes

The Select Nodes step selects the target hosts from the Service Infrastructure you defined. You can choose to select a specific host or simply specify the number of instances to select with the Service Infrastructure criteria.

If you choose to set the number of instances, in Select specific hosts?, select No.

In Instances, enter the number of instances to use. Remember that Harness is deploying to existing instances as defined in your Service Infrastructure. Ensure that there are enough instances that meet your criteria.

If you choose Yes in Select specific hosts?, click in Host Name(s) to select the specific target hosts for the deployment. Harness will obtain the host names or hosts that match the criteria of your Service Infrastructure.

The following image shows a Service Infrastructure specifying an AWS Region, VPC, and Tags (Name:doc-target), the EC2 instance that meets that criteria, and the host name in the Node Select dialog.


The Install step runs the command scripts in your Service on the target host.

The following image shows the Install step in the deployed Workflow and its corresponding Service commands and scripts.


There are not many causes for a rollback of a Basic Workflow using application packages. Artifact issues are uncommon because the artifact must be available to the Harness Delegate before you deploy. If the Delegate cannot reach the target host, the deployment will fail without changing the target host, and so no rollback is needed.


The Basic Workflow is the most common deployment of Services deploying application packages. Once you've successfully deployed the Workflow, you can click the Install step to see the Service commands and scripts in the Deployments page.

You can expand logs for each script in the Install step to see the log of its execution by the Harness Delegate. For example, here is the Copy Artifact script copying the application package todolist.war to the runtime location set up in Application Defaults ($HOME/${}/${}/${}/runtime):

Begin execution of command: Copy Artifact

Connecting to ip-10-0-0-54.ec2.internal ....

Connection to ip-10-0-0-54.ec2.internal established

Begin file transfer todolist.war to ip-10-0-0-54.ec2.internal:/home/ec2-user/ExampleAppFileBased/WAR/Development/runtime/tomcat/webapps

File successfully transferred

Command execution finished with status SUCCESS

You can SSH into the target host and see the application package:

Next Steps







How did we do?