Skip to main content

Provisioning overview

Harness provisioning is categorized into the following use cases:

  • Ad hoc provisioning: temporary and on-demand provisioning of resources for specific tasks or purposes.
  • Dynamic infrastructure provisioning: provision the target deployment environment as part of the same deployment process. Typically, dynamic infrastructure provisioning is for temporary pre-production environments, such as dev, test, and qa. Production environments are usually pre-existing.

Important notes

  • Dynamic infrastructure provisioning:
    • Only provisioners that produce outputs can be used in an Infrastructure Definition to dynamically provision deployment target infrastructure.
    • Currently, dynamic provisioning of target infrastructure is not supported for the AWS ASG, AWS SAM, and SpotInst deployment types.
    • Dynamic provisioning is not supported when using multiple services and environments in a pipeline stage.

Ad hoc provisioning

To perform ad hoc provisioning in your Harness Deploy stage, you use provisioning steps as part of the stage Execution section.

For example, in the following figure, Harness Terraform Plan and Apply steps are used to provision the required AWS IAM resources, which are independent of the rolling deployment to the Kubernetes cluster itself.

Figure 1: Ad hoc resource provisioning.


See the following topics for steps on how to perform ad hoc provisioning:

Dynamic infrastructure provisioning

Dynamic infrastructure provisioning creates your target infrastructure dynamically during the execution of your pipeline.

To perform dynamic provisioning in your Harness Deploy stage, you add provisioning steps to the stage Environment settings. Then you map specific provisioner script/template outputs to the target infrastructure in the same stage Environment section.

For example, the name of the target Kubernetes cluster namespace is provisioned by the Terraform Apply step in Environment section and then mapped to that stage's target Infrastructure.

At deployment runtime, Harness does the following:

  1. Provisions the target environment using your script/template.
  2. Uses the script/template outputs to locate it and deploy to it.
Figure 2: CD stage target infrastructure provisioning and mapping.


See the following topics for steps on how to perform dynamic provisioning:

Dynamic provisioning and deployment type support matrix

The following table shows the provisioners you can use with each deployment type for dynamic provisioning.

Terraform and Terraform CloudCloudFormationTerragruntAzure Resource Manager (ARM)Azure BlueprintShell ScriptAWS CDK
Azure Web Apps✔️✔️✔️✔️✔️✔️
AWS ECS✔️✔️✔️✔️✔️
AWS Lambda✔️✔️✔️✔️✔️
Spot Elastigroup✔️✔️✔️✔️✔️
Google Cloud Functions✔️✔️✔️✔️ framework✔️✔️✔️✔️✔️
Tanzu Application Services✔️✔️✔️✔️✔️✔️✔️
SSH deployments✔️✔️✔️✔️✔️✔️✔️
WinRM deployments✔️✔️✔️✔️✔️✔️✔️

Dynamic provisioning outputs for mapping

To use dynamic provisioning, you map outputs from your provisioner script/template that tell Harness what infrastructure to provision and use as the deployment target infrastructure.

You use these outputs in Harness expressions that you enter in the Harness infrastructure settings.

The format for the expression is <+provisioner.OUTPUT_NAME>.

For example, if a Terraform script has the following output, the expression is <+provisioner.default_namespace>:

output "default_namespace" {
value = kubernetes_namespace.example.metadata[0].name

Here you can see the expression used to map the output in the infrastructure settings:

Figure: Mapped output

The following table shows the Infrastructure Definition settings that are mapped to provisioner outputs.

Infra typeInfra settings that require mapping
Kubernetes DirectNamespace, Release Name (optional)
Kubernetes GCPNamespace, Cluster, Release Name (optional)
Kubernetes AzureNamespace, Cluster
Kubernetes AWSNamespace, Cluster, Release Name (optional)
Physical Data CenterHost Array Path, Host Attributes
SSH and WinRM on AWSRegion, Tags
SSH and WinRM on AzureSubscription Id, Resource Group, Tags
Azure Web AppSubscription, Resource Group
Google Cloud FunctionsRegion, Project
AWS LambdaRegion
AWS ECSRegion, Cluster
Tanzu App ServicesOrganization, Space AWS LambdaRegion, Stage

Using ad hoc and dynamic provisioning together

Ad hoc and dynamic provisioning can be used together.

For example, you can:

  1. Dynamically provision the target deployment Kubernetes namespace in the stage Environment.
  2. Deploy your services to the provisioned namespace in the stage Execution.
  3. Use subsequent ad hoc provisioning steps in Execution to change the provisioned namespace, etc.

Dynamic provisioning is configured in a CD Deploy stage's Environment settings and ad hoc provisioning is configured in its Execution settings.

At deployment runtime, Harness processes the Environment settings first, along with its dynamic provisioning, followed by the Execution settings, containing its ad hoc provisioning.

Consequently, the Environment settings cannot reference subsequent Execution settings, but the Execution settings can reference previous Environment settings.

For example, if you dynamically provisioned a Kubernetes namespace in the Environment settings and mapped the namespace output using the expression <+provisioner.default_namespace>, you can reference the namespace in the Execution steps settings using the same expression, including any files that those steps use.

But if you performed ad hoc provisioning in the Execution steps, you cannot reference the outputs of those steps in the Environment settings.

Service Instances (SIs) consumption

Harness Service Instances (SIs) aren't consumed and no other licensing is required when a Harness stage uses Azure ARM to provision resources.

When Harness deploys artifacts via Harness services to the provisioned infrastructure in the same stage or pipeline, SIs licensing is consumed.


For frequently asked questions about Harness infrastructure provisioning, go to Infrastructure provisioning FAQs.