Ping CLI 1.0: A Command Line Utility for the Ping Platform

We’re excited to share that Ping CLI has reached version 1.0, a long-term supported, generally available release. Ping CLI is a command-line tool that connects to multiple Ping Identity services simultaneously, allowing you to manage them through one consistent, developer-first terminal interface.

Ping Identity has a broad platform, and Ping CLI enables standard management patterns through a generalized, consistent terminal interface. Use it to promote configuration from staging to production, validate that your apps are set up correctly before a release, script a repeatable setup, or explore an API interactively with common conventions. For developers who live in the terminal, it means one management interface across your configured services, a logical set of commands, and configuration you can export, version, and share.

This article is an introduction and will highlight what Ping CLI is, what you can do with it right now, and where it’s headed.

Where we’ve come from

CLIs at Ping have taken many forms and have evolved incrementally for their individual use cases. As our platform capabilities have expanded and become better integrated, we saw the need for a single terminal experience that allows developers to manage configuration from the terminal, as well as bundle configuration into configuration-as-code packages and reliably deploy those packages to higher environments.

We started the unified CLI journey with Ping CLI in late 2024 as an evolution of pingctl and, in its initial experimental releases, you gave us valuable feedback that helped us steer toward our current milestone release.

Version 1.0 represents our commitment to our developer community: to meet developers where they’re at, whether that’s in the terminal, the web admin consoles, or using agents. The CLI is now fully supported and can be built into workflows with confidence.

What it is used for

The CLI serves three main use cases:

1. Developers in the terminal
2. Deterministic automation and CI/CD
3. Headless, AI-first use cases

Here we briefly discuss all three, but keep an eye out for future deep-dive articles.

Developers in the terminal

The CLI is designed to be intuitive and easy to use for developers that live in the terminal. If you prefer the terminal to the browser for quick (or extensive) configuration changes and shell scripting for rapid prototyping and personal automation, then the CLI presents an efficient alternative to administration in the web console.

Tip: use the CLI’s shell completion to quickly build commands with Tab autocomplete.

Deterministic automation and CI/CD

GitOps-based CI/CD is an industry standard method of promoting configuration between environments in an automated, auditable, and highly governed way. Where customers have invested in GitOps CI/CD pipelines, there has to be a repeatable, idempotent way to:

• Export Ping Identity configuration as code.
• Organize exported configuration as code within the filesystem.
• Version control within source control (such as Git).
• During CI/CD workflow execution, apply that versioned configuration to the next environment in the deployment pipeline.

There is no one-size-fits-all approach to CI/CD, but there are industry-standard patterns of use, so the CLI provides the toolkit to natively integrate with a wide range of CI/CD workflow orchestrators, with both imperative (“these are the actions to take to get to the end state”) and declarative (“this is the end state I want, take whatever actions are needed”) methods of configuration management with the ability to integrate with OpenTelemetry collectors for deep observability.

Headless, AI-first use cases

Ping CLI is designed to be natively understood by coding and configuration agents. The ability to understand and use CLIs is inherent in the training of many large language and small language (LLM and SLM) models, meaning they know how to read and run CLIs and interpret the output, to determine the actions to take.

By logically laying out the command structure with brief but effective --help text, agents can crawl the CLI to be able to compose commands to achieve an outcome. When paired with developer documentation (such as the Developer Use Cases), the agent can compose commands, with data payloads, to accelerate the development of use cases.

Tip: Use the bundled ping-cli-usage Agent Skill so the agent doesn’t need to crawl the --help texts to understand how to use the CLI.

Agents can use the Ping CLI to augment the CI/CD and configuration promotion workflows, by exporting configuration, raising requests to change the configuration-as-code within the GitOps pipeline with Pull Requests (as coding agents do today), and orchestrating the CI/CD workflows to reduce repetitive work by DevOps developers and administrators.

Refer to Build with AI developer documentation for more information on how agents can use the Ping CLI alongside Agent Skills and documentation for agents.

What you can do today

We’re on our journey to build out the CLI capability and build a truly unified CLI experience that allows rich management features covering all of Ping Identity’s product capabilities. We’ve started by releasing a solid foundation, with configuration management features for PingOne and universal services:

• DaVinci
• PingOne MFA
• PingOne Protect
• PingOne Verify
• PingOne Authorize
• PingOne Credentials

Let’s take a look at some of the new features available in 1.0!

Interactive guided setup

The Ping CLI now provides a guided setup process. Use pingcli init to walk you through first-time configuration, including connecting products and services and setting some initial preferred settings.

Tip: If you’re looking to just connect one set of products, each platform has its own guided setup process. To specifically connect PingOne with the guided setup interface, use pingcli pingone init

The pingcli init command

Authenticate across multiple services

We’ve streamlined the login process for developers using interactive logins using the browser. After connecting products to the CLI through the interactive setup, login for all can be performed with a single command.

The pingcli auth login command

The simplicity of managing admin sessions, as one CLI session, allows developers to spend less time authenticating and more time getting the job done.

Ping CLI supports the login methods you’d expect:

• Service accounts for automation: for use with CI/CD pipelines and fully automated workflows.
• Interactive login flows with silent token refresh: where supported, interactive logins are for developers using the CLI directly in the terminal. IAM administrators can apply strong policies to CLI users, including the use of admin MFA.

Where available, the CLI stores tokens safely in your OS keychain, or ephemerally where keychains are not available (such as when running in an OCI container).

Tip: Each platform has its own auth management. If you’re looking to just manage PingOne without any other connected product, use pingcli pingone auth login.

Manage configuration across products and services

Each product and service gets its own command namespace. PingOne lives under pingcli pingone, and each resource exposes a consistent set of verbs:

• create: to create new resources within an environment
• apply: an idempotent way of maintaining a resource’s configuration
• get: to return the full configuration of a resource by its identifier
• list: to return multiple resources of the same type (with a filter, where the API allows)
• replace: to overwrite a resource with new configuration
• delete: to remove a resource from the environment
• template: generates a JSON body skeleton as a starting point for manual configuration-as-code development

Tip: Most commands have aliases to make life easier, giving users and agents command patterns that suit them best. For example, pingcli p1 is an alias of pingcli pingone. The create verb also has an alias of new, the update verb has an alias of replace, list has an alias of ls, among others. Try out what suits you. If we miss an obvious command alias, tell us with the pingcli feedback command.

The pingcli pingone application example commands

The universal services (MFA, Verify, Protect, Credentials, Authorize, and DaVinci) are addressable directly by service, or as part of their platform for convenience:

Example showing how DaVinci flows are managed

The same command shapes carry across resources, services, and products, so the muscle memory you build in one place transfers everywhere. Resources deep-nest naturally too:

pingcli pingone applications sop-assignments list --environment-id $ENVIRONMENT_ID --application-id $APPLICATION_ID
pingcli pingone groups group-nestings list --environment-id $ENVIRONMENT_ID --group-id $GROUP_ID

Profiles for every environment

Real workflows span sandboxes, development, testing, staging, and production. Some users will need to be operating on multiple environments, or switching contexts depending on what is needed in the moment.

Configuration profiles let you keep those configurations side by side and allows quick switching between them globally or per command:

Example showing configuration profile use

Configuration is persisted in (and can be loaded by) a readable YAML file, and every setting can be overridden by an environment variable, which is ideal for easily injecting configuration and secrets into CI/CD pipelines at runtime.

Make raw API calls when you need them

The managed resources cover the common cases and are being built out over the next few releases, but sometimes you need the full surface of an API. This is especially useful if you’re using a prerelease product feature that’s not yet built in as a native command, or you need more control than a native resource command can provide.

Each product exposes an api command giving you a cURL-like experience with authentication, base URL, and environment details filled in for you automatically:

Example showing custom API commands

Output built for scripting

Ping CLI speaks both human and machine. Every command accepts -O/--output-format with four modes:

• text: The default, formatted for reading at the terminal.
• json: A single structured document, ideal for jq or JMESPath queries using the --query parameter.
• ndjson: Newline-delimited JSON (one record per line), ideal for jq, grep, awk, and for streaming and sending to log pipelines.
• ndjson-typed: Newline-delimited JSON with type metadata per record, ideal for jq and sending to log pipelines that need a consistent structure.

For extracting exactly the fields you need, --query takes a JMESPath expression directly rather than piping to another tool. For transformations that go beyond what JMESPath supports, pipe to jq.

Using the --query parameter and piping output to jq example

For pipelines that must react to results, --no-color keeps logs clean, while --detailed-exitcode distinguishes success (0), error (1), and success-with-warnings (2) so a CI step can branch on the outcome as well as text.

Quality-of-life extras

• Shell completion: pingcli completion zsh (also bash, fish, powershell).
• AI agent skills: pingcli agent-skills install / list for teams building agent-assisted workflows.
• OpenTelemetry integration: For deep observability into CLI actions.

Getting started

Ping CLI ships as a signed release for macOS, Linux, and Windows across common architectures, and as a Docker image. To get started for PingOne:

1. Follow the PingOne getting started guide in the CLI documentation
2. Run the guided initialization walkthrough (which authenticates you at the end): pingcli init
3. List the environments you’re able to view: pingcli pingone environments list

Full installation instructions, the complete command reference, and configuration guides live on the Ping Identity Developer Portal.

What’s next

Version 1.0 is a commitment to stability: a foundation you can build automation on with confidence. But it’s a milestone, not a destination. The vision is a genuinely universal tool, one that speaks to every Ping service and platform with the same fluency it speaks to PingOne today.

As a preview, in the pipeline we have:

• Advanced Identity Cloud configuration management.
• PingFederate configuration management (for both private tenant and software).
• Defined declarative import/export tools.
• Refined processes for exporting and generating configuration-as-code (as an evolution of the experimental platform export command in Ping CLI version 0.8).
• Enhanced headless AI features, enabling more streamlined use with configuration agents.
• The ability to introspect environments and debug issues.
• The ability to extend with custom plugins. And more to come.

Can we improve? Your feedback matters

Keep an eye out for future releases that enhance the capabilities of the CLI even further. Your real-world feedback matters. As you use the Ping CLI, tell us what you need.

Is there a command alias you’re finding is missing? Is there a feature you’d like included? Is there a use case we can improve upon?

Run pingcli feedback to reach us directly, or open an issue on GitHub to track a request or vote on features.

And finally

Look out for upcoming articles where we deep dive into Ping CLI with headless, AI-first configuration using agents, building a CI/CD workflow with Ping CLI, and generating configuration-as-code. Welcome to Ping CLI 1.0!

Used the CLI to build something great? Tell the community! Join the discussion on the Ping Identity developer community.