# Solutions (`uip solution`)

Create, pack, publish, deploy, and manage UiPath solution packages.

> For full option details on any command, use `--help` (e.g., `uip solution deploy run --help`).

---

## What is a Solution?

A UiPath Solution is a container that groups multiple automation projects (processes, libraries, tests) into a single deployable unit. Solutions enable:

- **Bundled deployment** -- Deploy multiple projects together as one package
- **Version management** -- Track and version the entire solution as a single entity
- **Configuration management** -- Apply environment-specific configuration at deploy time
- **Multi-environment promotion** -- Move solutions through dev, staging, and production

### Platform availability

Solutions runs on Automation Cloud and — from **Automation Suite `2.2510.0`** onward — self-hosted Automation Suite. Not available on Standalone Orchestrator.

| Delivery option | Solutions |
|---|---|
| Automation Cloud / Automation Cloud Dedicated | ✅ |
| Automation Suite (self-hosted) | ✅ from `2.2510.0` (added to the AS product portfolio in that release) |
| Standalone | ❌ |

Full delivery-option matrix: [Product and feature availability across delivery options](https://docs.uipath.com/overview/other/latest/overview/product-and-feature-availability-across-delivery-options).

#### Available project types by Automation Suite version

This table is about the **Solutions feature** (`.uipx` bundling/deploy). Which project types a Solution can bundle/deploy on self-hosted Automation Suite depends on the AS version — the backing products land in different releases of the `2.2510` line.

| Automation Suite version | Project types deployable **as a Solution** (`.uipx`) |
|---|---|
| `< 2.2510.0` | None as a Solution — the Solutions feature is not on Automation Suite yet. **RPA still runs**: processes / libraries / tests deploy to Orchestrator directly (classic publish → deploy), as they have on Automation Suite since well before Solutions |
| `2.2510.0`+ | RPA workflow (cross-platform / Windows — **not** Windows-Legacy), App, API workflow, Agent, Agentic process |
| `2.2510.2`+ | adds Maestro (self-hosted): agentic-orchestration / BPMN-process runtime |

- Pre-`2.2510.0` is a gap in the **Solutions packaging path only** — Orchestrator (and RPA on it) is supported on every Automation Suite version, including Standalone.
- From `2.2510.0`+, same Solution project-type set as cloud, gated by AS version. The Solutions feature itself is unsupported on Standalone at any version.
- Agent / agentic-process / API-workflow runtimes ship across the `2.2510` patch line; confirm exact patch level against each product's Automation Suite release notes.
- Sources: [AS `2.2510.0` product bundle](https://docs.uipath.com/automation-suite/automation-suite/2.2510/release-notes/automation-suite-on-eks-aks-2-2510-0) · [Solutions on Automation Suite](https://docs.uipath.com/solutions-management/automation-suite/2.2510/user-guide/solutions-management-overview) · [Maestro on Automation Suite `2.2510.2`](https://docs.uipath.com/maestro/automation-suite/2.2510/release-notes/2-2510-2).

### Solution File Structure

```
MySolution/
├── MySolution.uipx                       <- Manifest. Source of truth: project list + IDs + StudioMinVersion.
├── <ProjectName>/
│   ├── project.uiproj OR project.json    <- Required for add/import. Type auto-detected.
│   ├── bindings.json                     <- Agent runtime bindings. NOT scanned by refresh.
│   ├── bindings_v2.json                  <- Solution refresh reads this (if it exists).
│   └── ...
├── <AnotherProjectName>/                 <- A solution can host many projects side-by-side.
│   ├── project.uiproj OR project.json
│   ├── bindings_v2.json
│   └── ...
├── <AppV2ProjectName>/                   <- AppV2 coded app (Coded or CodedAction).
│   ├── project.uiproj                    <- ProjectType: "AppV2".
│   ├── webAppManifest.json               <- Coded / CodedAction discriminator + bundlePath.
│   └── source/dist/                      <- Build output (bundlePath: "source/dist").
├── resources/                            <- Auto-generated on add/import. NEVER hand-edit.
│   └── solution_folder/
│       ├── package/<name>.json           <- Auto-created on add. NOT cleaned by `projects remove`.
│       ├── process/{process,flow}/<name>.json   <- Auto-created on add. Auto-cleaned on remove.
│       └── app/{Coded,CodedAction}/<name>.json  <- AppV2 apps only. `kind: "app"`, `apiVersion: apps.uipath.com/v1`.
└── userProfile/<user-uuid>/              <- Appears after first `projects remove`.
```

> `.uipx` and `resources/solution_folder/` must always agree on the set of projects. Diffing them is the fastest way to detect a corrupted state — see [develop-solution.md - Field-tested gotchas](develop-solution.md#field-tested-gotchas).
>
> The `.uipx` also carries a `StudioMinVersion` field (e.g. `2025.10.0`). If users hit a version-mismatch when opening the solution, that's the constraint to check.

> **AppV2 coded apps are first-class solution members when authored inside a `.uipx`.** They emit under `resources/solution_folder/app/{Coded,CodedAction}/`, pack / publish / deploy via `uip solution`, and are registered by `uip codedapp init` (run from inside the solution — auto-registers), `uip solution projects add`, or `uip solution projects import`. `uip codedapp init` is the solution-side entry point; standalone coded apps are scaffolded with `npx create-vite` instead and deploy through `uip codedapp pack` / `publish` / `deploy`. See [SKILL.md Rule 7](../SKILL.md#critical-rules) and [/uipath:uipath-coded-apps](/uipath:uipath-coded-apps).

> **`.uis` bundles and the `pack` `.zip` are plain zip archives — unzip to inspect bundled contents.**

---

## Solution Lifecycle

```mermaid
graph LR
    A[init] --> B[project add]
    B --> C[resources refresh]
    C --> D[pack]
    D --> E[publish]
    E --> F["deploy run<br/>(auto-activate by default)"]
    F -->|--skip-activate| G[activate]
    C --> H[upload]
```

Two distinct distribution paths from the same solution source:
- **`pack` → `publish` → `deploy run`** — promotes a versioned package to Orchestrator.
- **`upload`** — pushes the solution to Studio Web for browser-based debugging only. Does not produce a published package and cannot be deployed via `deploy run`.

Always run `resources refresh` before either path so the bundled artefact files and `userProfile/<userId>/debug_overwrites.json` reflect the current cloud state.

---

## Command Tree

```
uip solution
  ├── init <name>                         Create a new solution directory with .uipx manifest
  │                                        (pre-rename CLIs expose this as `new`; see SKILL.md "CLI Surface Probe")
  ├── delete <solution-id>                Delete a solution from Studio Web
  ├── upload <path>                       Upload solution to Studio Web
  ├── restore <solution>                  Resolve NuGet deps in place before pack (needs login; no package produced)
  ├── pack <solution> <output>            Pack into a deployable .zip package
  ├── publish <package>                   Upload packed solution to UiPath
  ├── projects                              (`project` still works as a hidden, deprecated alias)
  │     ├── add <project-path> [solutionFile]   Register an existing subfolder in .uipx
  │     ├── remove <project-path> [solutionFile] Unregister a project from .uipx
  │     ├── import <path>                       Copy external project into solution and register
  │     ├── list                                List projects registered in the local .uipx (no backend call)
  │     ├── publish                             Publish a cloud solution project as a package (--project-name, --package-name, --package-version)
  │     └── resync [project-name]               Sync or reset a cloud solution project (--sync-option Sync|Reset)
  ├── resources
  │     ├── list                          List local, remote, or all resources (--solution-folder, default cwd)
  │     ├── refresh                       Sync resource declarations from project bindings (--solution-folder, default cwd)
  │     ├── get <resource-key>            Get full configuration for a single resource — local or remote (--solution-folder, default cwd)
  │     ├── add                           Add one resource atomically: --source local|remote --kind <kind> --name <name>
  │     ├── remove <resource-key>         Delete one resource from the solution by key (offline, no auth)
  │     └── edit <resource-key>           Patch an existing resource's spec via --patch '<json>' (or '-' for stdin)
  ├── deploy
  │     ├── run -n <name>                 Deploy a published solution package (auto-activates by default; pass --skip-activate to opt out)
  │     ├── status <id>                   Check deployment status
  │     ├── list                          List deployments
  │     ├── activate <name>               Activate a deployment (only needed after --skip-activate or to retry a failed auto-activation)
  │     ├── upgrade <deployment-key>      Move a deployment to a newer package version in place, keeping its existing configuration
  │     ├── uninstall <name>              Uninstall a deployment
  │     └── config
  │           ├── get <package-name>      Fetch default deploy config
  │           ├── set <file> ...          Set a resource property in config
  │           ├── link <file> <resource>  Link to an existing Orchestrator resource
  │           └── unlink <file> <resource> Remove a resource link
  ├── feeds
  │     └── list                          List the feeds you can publish or deploy to (tenant, your Personal Workspace, folder feeds)
  └── packages
        ├── list                          List published solution packages
        ├── download <name> [version]      Download a published solution package .zip
        └── delete <name> <version>       Delete a specific package version
```

`publish`, `deploy run`, `deploy list`, `packages list` and `packages delete` all take
`--feed <name-or-key>` or `--personal-workspace` to target a feed other than the
tenant's. See [Pack and Deploy — Publishing to a non-tenant feed](pack-and-deploy.md#publishing-to-a-non-tenant-feed).

---

## Workflow References

Each workflow doc covers a multi-command choreography for a specific goal. Load the one that matches your task.

| Workflow | File | Covers |
|----------|------|--------|
| Develop a Solution | [develop-solution.md](develop-solution.md) | Create, add projects, manage resources, upload |
| Pack & Deploy | [pack-and-deploy.md](pack-and-deploy.md) | Pack, publish, deploy run, deploy config |
| Activate & Manage | [activate-and-manage.md](activate-and-manage.md) | Activate, uninstall, packages list/delete |
| Scenarios | [scenarios.md](scenarios.md) | Multi-project recipes — same-name across folders, intra-solution cross-refs, shared cloud resources, virtual assets at deploy |

---

## Related

- **Orchestrator** (`uip or`) — folders, processes, jobs, machines → [`uipath-platform`](../../uipath-platform/references/orchestrator/orchestrator.md)
- **Resources** (`uip or assets` / `queues` / `buckets` / …) — resources used by solutions → [`uipath-platform`](../../uipath-platform/references/orchestrator/resources.md)