---
title: Ping CLI in CI/CD Pipelines
description: How Ping CLI operates as the execution layer in CI/CD pipelines for promoting Ping Identity configuration to production.
component: build-with-ai
page_id: build-with-ai:pingcli:cicd-and-production
canonical_url: https://developer.pingidentity.com/build-with-ai/pingcli/cicd-and-production.html
llms_txt: https://developer.pingidentity.com/build-with-ai/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: June 18, 2026
keywords: ["Ping CLI", "CI/CD", "production", "pipeline", "GitOps", "config as code", "governance", "promotion"]
section_ids:
  the-agents-role-vs-the-pipelines-role: The agent's role vs. the pipeline's role
  role-in-the-pipeline: Role in the pipeline
  authentication-in-a-pipeline-runner: Authentication in a pipeline runner
  full-documentation: Full documentation
---

# Ping CLI in CI/CD Pipelines

[icon: circle-check, set=far]PingOne [icon: circle-check, set=far]DaVinci [icon: circle-check, set=far]Authorize [icon: circle-check, set=far]Credentials [icon: circle-check, set=far]MFA [icon: circle-check, set=far]Protect [icon: circle-check, set=far]Verify [icon: circle-check, set=far]PingFederate

This page covers Ping CLI-specific usage in CI/CD pipelines: its role as the execution layer, how it authenticates in a pipeline runner, and the commands used for environment promotion.

For the broader governance model, why agents operate pipelines rather than production APIs, and how the review gate works, refer to [Agents in CI/CD and production environments](../agentic-cicd-production.html).

## The agent's role vs. the pipeline's role

In production workflows, Ping CLI is used at two distinct points:

1. **By the agent, against development environments**: the agent uses Ping CLI to export configuration from a development or sandbox environment, creates a pull request against a config-as-code repository, and initiates the GitOps promotion workflow. The agent can also drive the running pipeline: triggering runs, monitoring status, and retrying failures.

2. **By the pipeline, against production**: once configuration is merged and the pipeline is running, Ping CLI applies the configuration deterministically to the target environment. At this stage, the agent is not invoking Ping CLI directly; the pipeline is.

This separation keeps production changes under governance: the agent's non-deterministic reasoning is upstream of the review gate, not downstream of it.

**The pipeline is the authoritative, auditable execution layer**.

## Role in the pipeline

Ping CLI handles the imperative operations in the pipeline:

* **Exporting and applying configuration**: producing a snapshot of environment configuration as structured files for version control and through script, applying that configuration to alternate environments.

* **Promoting configuration**: applying configuration as code packages built from one environment to another using `pingcli` commands.

* **Querying current state**: introspecting an environment to confirm that a deployment succeeded and the live configuration matches expectations.

These are stateless operations. Ping CLI doesn't maintain a state file and doesn't reconcile drift, it executes what the pipeline instructs. For declarative state management, [Terraform](../terraform/overview.html) operates alongside Ping CLI in the same pipeline.

## Authentication in a pipeline runner

In a CI/CD pipeline runner, there is no human actor present. Ping CLI authenticates using a **client credentials grant** against a dedicated service account OAuth client.

The pipeline runner must have the following configured as environment variables or in a Ping CLI configuration profile:

* Client ID and client secret for the pipeline service account.

* The target environment's base URL.

* The required OAuth scopes for the operations being performed.

Don't use personal administrator credentials in pipeline runners. The service account must be scoped to the minimum permissions needed for promotion operations, and its credentials must be stored as secrets in the pipeline platform (not in source control).

|   |                                                                                                                                                                                                                                                                                                                                                 |
| - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | The pipeline service account should have write access only to the target environment for the specific pipeline stage it is running. A single service account with write access to all environments is a governance risk. Stage promotion pipelines; staging, pre-production, and production should each use a separate, scoped service account. |

## Full documentation

The complete Ping CLI reference: installation, service connections, configuration profiles, and the full command reference, refer to the [Ping CLI documentation site](https://developer.pingidentity.com/pingcli).