# Deployment of the Platform Managed by the Orchestrator

[Deployment Diagram](https://docs.sherparpa.ru/en/sherpa-rpa/diagramma-razvertyvaniya-sherpa-rpa) of the Sherpa RPA platform managed by the Orchestrator shows the interaction options of the Orchestrator with other components of the Sherpa RPA platform:

* RDP server with Unattended user accounts – Sherpa Coordinator Service + Sherpa Unattended Robot
* Developer workstation (Windows) — Sherpa Designer + Sherpa Robot
* Client workstation (Windows) – Attended Robot
* Workstation with a browser.

## **Process Sequence**

1\) The business process automation script developer uses the Sherpa Designer desktop software and the local Sherpa Robot to create and debug the automation script. Completed automation scripts are transferred to user or robot workstations manually by copying the robot's configuration file or using the remote publishing feature to publish a new version of the script from Sherpa Designer to Sherpa Orchestrator.

2\) The server component Sherpa Orchestrator maintains communication with robots running on client machines, stores robot configurations and script versions, shared global variables and credentials, logs and screenshots of robot operations, audit logs of the orchestrator, users, roles, and tenants of the Orchestrator itself, licenses for all platform components, and script execution statistics.

3\) Users and administrators of Sherpa Orchestrator access resources, settings, and statistics through the orchestrator web application available via a web browser. Sherpa Orchestrator includes an Nginx web server, a PHP interpreter, and a relational database (default is MariaDB, option is Postgre).

4\) Local users launch the Sherpa Attended Robot to execute locally stored scripts as needed. During script execution, the Sherpa Attended Robot can send the Orchestrator the current status, tasks, logs, values of global variables and credentials, or receive tasks, values of global variables, and credentials from it.

5\) On a schedule, API call, robot command, or another supported trigger, Sherpa Orchestrator instructs the Sherpa Coordinator Service of the corresponding terminal server to create an RDP connection to a local or remote account designated for the Unattended robot, with multiple such accounts able to be hosted and actively used on a single terminal server.

Access to the Unattended robot account is made with the login and password provided by the Orchestrator.

After logging in, the corresponding instance of Sherpa Unattended Robot starts, connects to the Orchestrator, receives the task to execute the script, and the script itself stored in the orchestrator.

During script execution, the Sherpa Unattended Robot can send the orchestrator the current status, tasks, logs, values of global variables and credentials, or receive tasks, values of global variables, and credentials, commands for "soft" or "hard" termination of the script.

After completing the script execution, the Sherpa Unattended Robot logs off from its account.

In simple business processes, the use of the Orchestrator is not mandatory, as Attended versions of Robots can be used autonomously. The potential of the Orchestrator is revealed in business processes that require the use of multiple robots, as well as the organization of centralized management and interaction among them.

## **Failover Deployment of the Orchestrator**

The Orchestrator supports failover deployment, as demonstrated in the diagram below. To achieve this, it uses two synchronized databases and load balancing.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfq-RqhBZYI6vhD-0LWcD2FDL2mYyC0bDLzYPNGGVQtQnGEtLuSTVHp159VYEkH1PeANIIdx_W59uAuPwdB1D34RcQD6fu03HuG6LgJa9nW4AyGaxsrpcNJctDDx7wgsAzqnRruV-S3JpIGdD-nAseUJ9Q?key=o3vhWvY1mrn1hFPgJMEISQ" alt=""><figcaption></figcaption></figure>

To implement this deployment scheme, two additional virtual machines with database administration will be needed, and all system settings for the databases (DB) must be configured, as well as three IPs from the same subnet (two for the database servers and one free). Then, the following settings need to be specified in `docker-compose.yml`:

1. For the orchestrator container, modify DB\_HOST in environment

   `- "DB_HOST= IP address of the database load balancer"`
2. For the orchestrator container, comment out the following lines:

`# depends_on:`

`# - orchestrator-db`

Specify the address of the database load balancer in the configs:

`/opt/SherpaOrchestrator/backend/config/config.ini`

and

`/opt/SherpaOrchestrator/backend/config/phinx.php`


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sherparpa.ru/en/sherpa-rpa/sherpa-orchestrator/razvertyvanie-platformy-pod-upravleniem-orkestratora.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.