Automating with UiPath CLI for enterprise CI/CD

Why does this matter?

Enterprise automation programs depend on repeatable delivery, versioning, approvals, and environment promotion - the same DevOps practices used for applications and APIs. As solutions grow to include multiple projects, dependencies, and assets, they must fit into these pipelines the same way Processes and Libraries already do. Without CLI support, automation teams couldn't integrate solutions into:

• Source control workflows

• Gated promotions between environments

• Automated deployment pipelines

• Change tracking and auditing

By enabling full lifecycle management through UiPath CLI, Solutions now participate naturally in CI/CD, alongside existing assets, using the same mechanisms enterprises already use to deliver software.

Automating solutions with UiPath CLI

Now that UiPath CLI supports Solutions, any CI/CD system—Azure DevOps, GitHub Actions, Jenkins, GitLab CI, Bamboo, or others—can run solution lifecycle operations non-interactively.

Available CLI operations

Analyze governance/compliance

uipcli solution analyze <solution-folder-or-uipx>

Pack the solution

uipcli solution pack <solution-folder-or-uipx> --output <path> --version <x.y.z>

Upload a ZIP package

uipcli solution upload-package <path-to-zip>

Deploy the solution

uipcli solution deploy <package-name> -v <x.y.z> -d <deployment-name> -f <deployment-folder-name>

Activate a deployment

uipcli solution deploy-activate <deployment-name>

Deployments can target specific tenants, folders, and configurations using environment variables or parameters.

Authentication and scopes

To use these commands, pipelines authenticate through an External App in Orchestrator with the appropriate Solutions Management scopes.

Versioning requirement

Unlike standalone UiPath projects, Solutions do not auto-increment their version when packaged. The pipeline (or user) must explicitly define the version at build time.

Typical pattern in CI/CD

A common approach is to generate the version dynamically, for example:

• 1.0.$BUILD_ID

• 2.1.${GITCOMMITSHA}

This version is passed to the pack command:

uipcli package pack <solution-path> --version "<x.y.z>" --output <output-folder>

The resulting ZIP follows that naming convention, and subsequent upload, deploy, and activate commands reference that same version.

If the version is not provided, packaging will not infer or auto-bump it. This is by design, giving enterprise teams full control of release numbering.

NuGet restore is the real bottleneck

When packaging feels slow in UiPath CLI, the delay almost never comes from the packager itself. The real cost is a NuGet restore. Every pack operation triggers NuGet to resolve both direct and transitive activity dependencies.

No cache means a full restore every time

Hosted CI agents (GitHub, Azure DevOps, GitLab, Jenkins, etc.) start from a clean environment. The NuGet global package cache does not persist between runs unless it is explicitly cached. With no cache in place, NuGet must download every dependency again on each job.

A package that appears to have a few direct dependencies often expands into dozens of transitive packages during restore.

Example cache locations:

• Linux/macOS: ~/.nuget/packages

• Windows: %UserProfile%\.nuget\packages

Feed order is the real delay

If no custom nuget.config is provided, NuGet queries all configured sources. NuGet does not skip a slow or unreachable feed. It waits for a response or timeout before moving to the next source.

How the delay scales

For each missing package, NuGet performs:

1. A cache lookup (empty on fresh agents)

2. A probe of each configured feed in order

3. A wait or timeout if a feed does not respond

4. A download only after a reachable source is found

How to avoid the restore bottleneck

The slowdown is a consequence of NuGet behavior in clean environments, not UiPath CLI itself. To reduce restore time:

• Use a trimmed nuget.config with only feeds reachable from the agent. See docs https://docs.uipath.com/cicd-integrations/standalone/2024.10/user-guide/managing-nuget-feeds#managing-nuget-feeds. Make sure to

• Persist the global package cache between pipeline runs

• Use self-hosted runners if persistent storage is required

Example using Azure DevOps pipeline on Windows agent

In Azure DevOps, one Cache@2 block is enough — it restores the NuGet cache at the start and automatically updates it at the end.

Before

After

Use self-hosted runners if persistent storage is required.

Without these changes, every pipeline run is effectively a cold restore, and NuGet repeatedly waits on feeds even for packages it resolved minutes earlier.

Proxy and certificate handling in enterprise environments

Many enterprise build agents run behind SSL-inspecting proxies. Even if the OS trusts the proxy’s certificate, Node-based tools (including UiPath CLI and NuGet tasks) do not read the Windows or Linux certificate store.

This leads to errors such as self-signed certificates in the certificate chain. The SSL connection could not be established, see inner exception

To ensure UiPath CLI works reliably, two steps are required:

1. Define proxy variables at pipeline/agent level

Set these before any CLI or Node task runs:

• HTTP_PROXY

• HTTPS_PROXY This ensures the agent and all child processes inherit them automatically.

Trust the proxy’s certificate via NODE_EXTRA_CA_CERTS

If the proxy uses a private , or self-signed CA, export it in .pem format and place it in a path readable by the agent. Then set: NODEEXTRACA_CERTS=<path-to-pem> For example, on Windows: C:\agent\certs\myCA.pem Node will load this file at startup so HTTPS calls will succeed without certificate errors.

Closing summary

With the addition of Solution support in UiPath CLI, automation teams can now extend the same CI/CD practices they already apply to Processes and Libraries to Solutions as well. This provides a consistent way to package, version, and deploy all automation assets through pipelines, ensuring that Solutions fit naturally into enterprise DevOps workflows.

What this unlocks:

• End-to-end automation: restore, analyze, pack, upload, deploy, activate

• Source control native workflows: branch, commit, merge, build

• Environment promotion: deploy across tenants consistently

• Explicit versioning: controlled by the pipeline, no auto-increment

• No manual Studio Web publishing needed

Native plugin support (Azure DevOps and Jenkins)

In addition to CLI-based automation, support for UiPath Solutions will also be available through native integrations in Azure DevOps and Jenkins. These plugins will expose the same operations—packaging, uploading, deploying, and activating solutions—as first-class pipeline tasks.

Teams that prefer script-less pipelines will be able to use these tasks instead of inline CLI commands, without moving YAML files or restructuring repositories. The plugin-based and CLI-based approaches are compatible and can coexist in the same delivery model.

YAML examples in context

The following examples reflect real enterprise setups where UiPath CLI is used in a CI/CD pipeline to pack, upload, deploy, and activate a solution.

Get started with automation and check out our pipeline samples for GitHub, Azure DevOps, and Jenkins. Found a bug? Help us improve by opening an issue on GitHub if anything doesn't work perfectly.