Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

CLI for Continuous Delivery

Reference for the Harness CLI commands that manage Continuous Delivery resources, including services, environments, infrastructure definitions, and service overrides.

Use the Harness CLI to manage Continuous Delivery resources including services, environments, infrastructure definitions, and service overrides. Go to Harness CLI to install, authenticate, and review all supported resources.

All commands follow the harness [verb] [noun] <identifier> pattern. Every list command supports --ui for interactive browsing, --all to fetch every page, and --format table|json|jsonl|csv|tsv|markdown for output control.

PIPELINE COMMANDS

Go to Continuous Delivery and pipeline commands to manage pipelines, executions, triggers, input sets, templates, and freeze windows from the CLI.

What will you learn in this topic?

By the end of this page, you will know how to:

  • Create, inspect, update, and delete service definitions from the CLI.

  • Manage environment entities and the type field that distinguishes production from pre-production targets.

  • Work with infrastructure definitions and why --env is required for list, get, and delete.

  • Use the two service override types (ENV_GLOBAL_OVERRIDE and ENV_SERVICE_OVERRIDE).

  • Use the --ui flag for interactive browsing of Continuous Delivery resources.

Before you begin

  • Continuous Delivery concepts: Familiarity with services, environments, and infrastructure definitions. Go to Continuous Delivery overview to review the resource model.

  • Harness CLI installed and authenticated: Go to Install and upgrade and Authenticate to set up the CLI.

  • Org and project scope configured: All Continuous Delivery resources are project-scoped. Set a default org and project with harness auth setscope or pass --org and --project on each command.

Services

A service represents what you deploy: the artifact, the manifest, and any configuration that defines your application. Services are reusable across environments and stay consistent regardless of the deployment target.

List services

Output of harness list service showing identifier, name, description, and updated columns
Click to view full size image

Get a service

Create a service

Provide a YAML file with the service definition:

Update a service

Fetch the YAML, edit locally, and push it back:

Delete a service

Environments

An environment represents where you deploy: production, staging, QA, or any other target. The type field accepts Production or PreProduction. Environments hold environment-specific configuration such as variables, manifests, and overrides.

List environments

Output of harness get service and harness list environment showing environment identifier, name, type, and updated columns
Click to view full size image

Get an environment

Output of harness get environment and harness list infrastructure showing infrastructure identifier, name, type, deploy type, and updated columns
Click to view full size image

Create an environment

Provide a YAML file with the environment definition:

Update an environment

Fetch the YAML, edit locally, and push it back:

Delete an environment

Infrastructure definitions

An infrastructure definition describes the compute target where a service is deployed within an environment. It specifies the cluster, namespace, region, or other details Harness needs to execute the deployment. Infrastructure definitions always belong to an environment, so --env <environment_id> is required for list, get, and delete.

List infrastructure definitions

Get an infrastructure definition

Output of harness get infrastructure showing identifier, name, type, environment, deploy type, updated, and created fields
Click to view full size image

Create an infrastructure definition

Provide a YAML file with the infrastructure definition:

Update an infrastructure definition

Fetch the YAML, edit locally, and push it back:

Delete an infrastructure definition

Service overrides

Service overrides customize service configuration for a specific environment without modifying the base service definition. Use them to override manifests, variables, or config files so the same service stays portable across environments.

The type field accepts two values:

  • ENV_GLOBAL_OVERRIDE: applies to all services in the environment.

  • ENV_SERVICE_OVERRIDE: applies to one specific service in the environment.

List service overrides

Get a service override

Create a service override

Provide a YAML file with the override definition:

Update a service override

Fetch the YAML, edit locally, and push it back:

Delete a service override

Interactive TUI

All list commands support --ui for a paged, interactive browser. The TUI requires a TTY on both stdin and stdout. Do not pass --ui in CI or headless environments.

When you drill into an execution from the TUI, you can navigate between the Logs, Details, Inputs, and Outputs tabs using the keyboard shortcuts shown in the footer.

The Logs tab streams step output in real time:

TUI execution logs tab showing Initialize step with machine provisioning output
Click to view full size image

The Details tab shows execution metadata including FQN, status, start and end times, duration, and the assigned delegate:

TUI execution details tab showing FQN, status, duration, timeout, and delegate name
Click to view full size image

The Inputs tab shows the step configuration as JSON:

TUI execution inputs tab showing step configuration JSON including identifier, name, timeout, type, and spec
Click to view full size image

TTY REQUIREMENT

The --ui flag is mutually exclusive with --format, --out, and stream redirection. For non-interactive contexts, use --format json or --format jsonl instead.

Next steps

PreviousTroubleshooting
NextCD Best Practices

Last updated

Was this helpful?