Version 5.9.4#

18.08.2026

A new release of Sherpa Orchestrator is available: Version 5.9.4.

1. Secure and correct connection to Sherpa VNC#

A protected RA2ne connection scheme has been added to Sherpa VNC with mandatory SHA-256 server key verification. Credentials are transmitted only after the previously saved fingerprint matches. Attempts to switch to a less secure protocol are rejected, and the login and password are no longer added to the new tab URL or left in browser history or request logs.

A separate key fingerprint for the current Account is stored in the Robot card. A single length limit is applied to the password, and whitespace characters are forbidden. This reduces the risk of connecting to a spoofed server and sending credentials to a third party.

Color rendering during Sherpa VNC connections has also been fixed. BGR image data is now converted before rendering, so the remote Robot desktop is displayed with the correct colors.

2. Improvements on the Resources and Resource Groups screens#

On the Resources screen, sorting Resource Groups by the Description column has been fixed. The selected sort direction is applied to the entire list, making it easier to find the required group.

Each Account now gets its own protected All Assets group. A new or imported Resource is linked either to the selected Resource Group or to All Assets if no group is specified. Groups with the same name from different Accounts are no longer mixed.

Resource-to-Resource Group relationships have been fixed. The list, the card, and exports use the actually saved relationships. Additional groups are assigned only by explicit add action, and ordinary Resource editing no longer creates extra links.

The API now includes a dedicated route for retrieving the Resources of a selected Resource Group:

GET /api/v1/asset_groups/{asset_group_guid}/assets

The response does not contain passwords or internal numeric identifiers. This makes it easier for external integrations to load a group safely.

3. Trigger management#

On the Triggers table, the display of related Robots, Robot Groups, and Processes has been fixed. Saved relationships are visible again directly in the list and are not lost when data is loaded.

A Trigger enabled column has been added to the table. A user with permission to modify Triggers can enable or disable a Trigger directly in the row. If an error occurs, the switch returns to its previous state and a notification is shown. A user without the required permission sees the current state but cannot change it.

Bulk enabling and disabling of Triggers has been fixed. An error when processing one Trigger no longer cancels changes for the others. After the operation completes, the table is refreshed and the notification shows how many state changes could not be saved. If no rows are selected, the interface asks the user to select Triggers first.

Trigger Tags are now displayed correctly in the Trigger card. Previously, a Task Tag without a GUID could cause the entire Task Tags list and the Triggers table to fail. Existing Task Tags now receive GUIDs, and a single invalid relationship no longer blocks the card from opening.

Robot remote debugging and local run settings, as well as Trigger email checks, have been moved to working API methods. When saving, the Robot type, Account ownership, Object Folder access, and User permissions are checked. The email check uses only the saved Trigger and requires permission to modify Triggers.

Filtering Object Folders by creation and modification dates has been fixed. The selected range is passed to the API and applied to the entire data set, not just the page that is already loaded in the table.

Filtering the Processes list by the creation date of the latest Job has been fixed. The filter is applied on the server and works correctly regardless of the number of Processes.

Jobs related to the Robot or Process from the selected Object Folder are once again shown in the Jobs table. The user can apply the Object Folder filter without losing access to available Jobs.

On the Robot Messages screen, messages are sorted by creation date by default: newest entries are shown at the top. This ordering is preserved when paging through large logs.

The Created column on the Robot Messages screen has been fixed. Date and time are displayed for stored values with time zones, microseconds, and different valid separators.

The Job column now shows the GUID of the Job used for filtering. When navigating to the Jobs screen, the active filter is shown as a separate tag and can be cleared with the X button.

Navigation from Audit and Robot Messages to the related Job has been fixed. The required record opens by GUID regardless of the current table page or the number of loaded Jobs.

Pages with tables no longer accumulate repeated data refresh subscriptions. After several visits to the same screen, a websocket event now triggers a single table refresh instead of a series of identical requests. This makes the interface more responsive and reduces unnecessary reloads.

5. Jobs, Tasks, Processes, and Robots#

Editing a Process Version has been fixed. Changes to the name, description, and file are now actually saved when the form is submitted. Previously, the server could return a success response without changing the data.

In the Actions section, saving the current Task before moving to the next one has been fixed. Filled-in parameters are saved before the transition and no longer depend on the translated status name.

In the Edit Task block, it is once again possible to set the Delayed status without specifying the delayed start date. This keeps compatibility with scenarios where the date is assigned later.

In the Job creation dialog, Robot and Process selection has been fixed. The list no longer opens because of automatic focus, does not cover neighboring fields, and lets the user choose a value with a single click.

Creating a Coordinator from the Robot dialog has been fixed. Empty values of hidden remote debugging parameters are treated as disabled settings and no longer cause a validation error.

Atomic linking between Jobs and Tasks has been fixed. Creating, editing, and cloning a Job now update both sides of the relationship consistently. A parallel attempt to modify an already occupied Task returns a conflict without partially saved data.

Re-saving a Job with the same Task in MariaDB no longer returns a false conflict. When a Job is partially updated, the saved Trigger and compatibility of the new Process, Robot, Robot Group, and Task are additionally checked.

Reapplying a final Job status no longer overwrites the completion time. Stopping or canceling a Job that has not started correctly records the completion time.

Fetching the next Task now allows only a transition from the initial state to the running state. Due delayed Tasks are first moved to the initial state by the scheduler. This prevents premature Task assignment to a Robot.

6. Users, Accounts, and Licenses#

The User and Account forms now show a clear reason for rejection received from the API instead of an HTTP status message or untranslated key. For example, when a password is reused, the message "Password already used" is shown; when the Login is already taken, "Login already in use" is shown.

Saving a User or Account without changing the current Login has been fixed. Uniqueness is checked only when the Login actually changes, so it is possible to update the password or other fields without the false "Login already in use" error.

Login lookup and uniqueness checks have been unified across all Sherpa Orchestrator interfaces. Case sensitivity behaves as in the previous scenarios, which avoids different results when using the old and new API.

Robot license assignment has been fixed. The request code is again built from the selected Robot data, and License type handling works the same in MariaDB and PostgreSQL.

Support for activating a pending Attended License for a Robot has been fixed. The Robot's service information is preserved until the response code is received and is no longer blocked prematurely by the License check.

7. Expanded and secure Audit#

Protection of sensitive data in Audit has been strengthened. API tokens, passwords, Resource contents, and sensitive values inside Trigger and Job parameters are stored in masked form, including nested data structures. If a parameter string cannot be parsed safely but contains a password, its contents are hidden entirely.

The list of actions recorded in Audit has been expanded. Trigger enabling and disabling, switching the production Process Version, removing the owner from an Object Folder, claiming Tasks, cloning and importing, clearing Logs, changing notification subscriptions, assigning Roles, and Sherpa Autopilot preparation operations are now logged.

For bulk operations, the number of modified records is preserved. The administrator can understand the scale of the action without opening each entity individually.

Detailed failed sign-in events have been added. Password and OAuth login rejections, request rate limiting, and login form validation errors are now recorded. Protection against frequent repeats prevents the log from growing uncontrollably.

The Login failed and Session expired messages for API v1 requests have been fixed. The wording is again compatible with the previous Audit filters, so existing monitoring rules continue to find sign-in and session-expiration events.

When an object is deleted, its name or title is preserved. The administrator can see exactly which object was removed, even if only the deletion flag was included in the change set.

Event binding to the User has been fixed when working in parallel through the interface, an API token, and a Robot GUID. The record no longer receives a User name from another active session. Actions performed by the authenticated User are again shown correctly in the corresponding column.

The Account Login and User Login display has been fixed in the record card. The card now returns the same related data as the main list.

Record accuracy has been improved: saving without actual changes no longer creates an event, identical date values are no longer considered changed, arrays are displayed without re-encoding, and new objects now show a name in the message instead of unknown.

An empty password value is no longer replaced with a masked secret marker. The administrator can distinguish a missing value from a masked password.

Audit archiving has been added during scheduled cleanup. Records are moved to the archive using the same rules as Logs, and an Audit archiving error no longer interrupts cleanup of Logs, Tasks, and Jobs.

The client address is determined taking trusted proxies into account. Proxy headers are used only for requests from explicitly allowed addresses and subnets; otherwise the direct connection address is preserved. This prevents spoofing the client address through arbitrary HTTP headers.

8. Sherpa Orchestrator installation with external PostgreSQL#

Sherpa Orchestrator installation with external PostgreSQL has been added. No new screen appears in the interface: the changes are intended for administrators who install and maintain the system.

The installer detects the use of an external server, checks its availability, and verifies the role and database. If administrative credentials are provided, missing objects are created automatically. If automatic creation is not possible, installation stops and displays a list of manual steps.

A separate instruction for installation with external PostgreSQL has been added to the documentation. This helps detect a connection error before the system starts and avoid a non-working interface with a gateway error.

9. Reliable Sherpa Orchestrator update#

Before the system is stopped, the update checks package completeness, version consistency across all archives, checksums, free disk space, the Docker Compose version, the availability of the external database, and the state of the migration to new volumes. Problems are detected before the running version is stopped.

Before new Docker images are loaded, backup tags are assigned to the current images. If a later failure occurs and the database structure has not changed yet, the previous version starts automatically.

The update script finds its own current copy in the new release and hands control to it. The new update checks and steps are executed by the current release script, not by a copy from the previous version.

After the update, the interface shows the version of the actually installed release. The version value is updated in the configuration and no longer remains equal to the first-install version.

The results of unpacking, stopping and starting containers, database migrations, and the web interface response are checked. If a step does not complete, the administrator receives a specific reason and a non-zero exit code instead of a success message.

If migration fails, the update does not try to start the previous version automatically on an already changed database structure. The administrator is given a safe recovery order from backup.

Stopping and restarting take enabled VNC and Vault profiles into account. A disabled service does not keep running after the update, and a required service is not skipped during startup.

The Docker Compose file is included in the backup, old backups are rotated automatically, and user certificates are not overwritten by certificates from the distribution.

The release loader checks that all Docker images belong to the same version and loads the Vault image together with the other components. This prevents startup from an incompatible set of components.

The result of migrations during container startup has been fixed. Success is determined by the real exit code of all stages, so the administrator no longer sees the Migration successful! message after a failed migration.

10. Automatic Vault preparation and unlock#

During installation, Sherpa Orchestrator automatically initializes Vault, enables the required secret storage mode, and saves the working token in the configuration. If existing data is detected, reinitialization is blocked so saved secrets are not lost.

During an update, Vault is automatically unlocked using previously saved keys. If the storage remains locked, the update ends with a clear error instead of a false success message.

No new screen appears in the interface. This change simplifies administrator work and reduces the risk of secret unavailability after installation or a system restart.

11. OAuth, OIDC, and LDAP protection#

For OAuth and OIDC sign-in, a one-time state parameter, PKCE S256, verification of trusted provider addresses, response size limits, redirect blocking, and request rate limiting have been added. This lowers the risk of sign-in spoofing and reuse of authorization data.

The OAuth return URL must be a fixed HTTPS address with the /api/v1/system/oauth_hook path. If a separate address is not specified, it is built from the Sherpa Orchestrator domain name.

The immutable sub identifier is used by default to link a User with a provider account. The installation supports a single configured provider. If the provider or the link field changes, the administrator must migrate the saved OAuth User logins.

LDAP now includes server certificate verification and network and operational timeouts, plus safe handling of names and directory filters. An ambiguous search result causes sign-in to be denied, and the invalid password error is distinct from LDAP server unavailability.

The tls value enables StartTLS, ssl is used for LDAPS, and the server certificate must be trusted. The configured search filter is always applied. This makes the configuration behavior unambiguous and helps avoid unnoticed bypassing of directory restrictions.

After sign-in and sign-out, the user session identifier and security token are refreshed. Data-changing requests are checked for cross-site request forgery, and the session in the cookie is isolated from API token authorization.

Desktop client sign-in has been fixed through:

POST /api/v1/session/login

The first authorization request no longer requires a security token to be obtained in advance. Protection remains in place for sign-out, OAuth, and later data operations.

When the session expires, the user session is fully destroyed. A new session and a new security token are then created, which prevents reuse of stale state.

13. Access separation between Accounts and Object Folders#

Checks that related entities belong to the current Account and an accessible Object Folder have been strengthened. The checks apply to Robots, Robot Groups, Processes, Queues, Tasks, Resources, Task Tags, and Roles, including partial updates.

When an Object Folder is created through API v1 on behalf of a User, the current User is automatically assigned as the owner. The new Object Folder appears immediately among the objects available to that User.

Removal of the Object Folder owner has been fixed. The operation now changes the actual owner field and no longer returns a success response without changing data.

For updating and deleting individual objects, Account and Object Folder checks are performed directly inside the database operation. A request for another account's or inaccessible object now returns the same 404 response without revealing whether it exists.

A Robot is not assigned a Job if the Accounts of the Robot, the Job, the Process Version, or the related Task do not match. This prevents another Account's data from being processed even if the relationship is damaged or manually edited.

When a Process Version is imported, access to the source Process and its Object Folder is verified. A Version cannot be moved from a hidden or чужого Process.

14. Safe Task acquisition by Robots#

For each request for the next Task, Robot activity, Account and Object Folder membership, the active License, and the available license slot are checked.

The license slot is reserved before the Task is issued. Parallel requests from two disabled Robots can no longer consume the single available slot at the same time.

The Robot GUID is allowed only for retrieving the next Task and does not grant access to other API v1 routes. The assigned License is checked before each issue.

The status filter used when retrieving a Task accepts both a single value and a list of values. Start and modification times are stored in UTC, and a delayed Task is compared with the current time regardless of the database connection time zone settings.

15. API v1 changes for external integrations#

API v1 now distinguishes invalid credentials from insufficient permissions with the standard 401 and 403 responses. The API token, Account key, user session, and Robot GUID each have separate scopes. This lets integrations handle rejection reasons more precisely.

Routes for special Robot settings, email checks, and Audit filter values have been updated:

PATCH /api/v1/robots/{robot_guid}/remote_debugging

PATCH /api/v1/robots/{robot_guid}/local_run

POST /api/v1/schedules/{schedule_guid}/email_tests

GET /api/v1/audit/filter_values

Old broken routes have been removed. Integrations that used the previous addresses must switch to the new methods.

Request formats for modifying Accounts, Object Folders, Resources, Tasks, Jobs, Logs, and Files have become strict. Unknown fields are rejected with a validation error. The parent Object Folder is set through parent_guid, and the main Dashboard is selected through a separate API method. This helps spot malformed requests faster.

The shared GET /api/v1/tasks route has been removed. Tasks are retrieved through the selected Queue route:

GET /api/v1/queues/{queue_guid}/tasks

The list supports filtering and sorting by comment, start date, due date, and other table fields.

The API v1 transition for Resources, Jobs, and Logs to GUID-based relations has been completed. Related entities are looked up only within the current Account and accessible Object Folder. Cross-account GUID collisions during Resource import are rejected.

GUIDs of related Tasks, Jobs, Object Folders, and Files are normalized to a consistent case. PostgreSQL no longer returns a false 404 for a valid identifier with uppercase letters.

When creating a Log, compatibility of the specified Robot with the related Job is checked. Either the Job's direct Robot or a member of the assigned Robot Group is allowed. An unrelated Robot cannot be specified.

Task Tag names remain case-sensitive: for example, "Report" and "report" are considered different Task Tags. Saving Task Tags and their relationships is performed consistently, and re-adding does not cause an error with parallel requests.

16. Files, export, and Logs#

Loading, replacing, and downloading Files and Process Versions has been improved. Large data is transferred in a streaming manner, and if a database error occurs, file-storage changes are rolled back. This reduces memory usage and prevents the database record from diverging from the actual file.

Names of downloaded Files are stripped of control characters and dangerous path segments before being added to the response header or ZIP archive. This protects integrations and user workstations from header spoofing and writing files outside the chosen folder.

Exporting Resources, Object Folders, Jobs, and Logs now requires an explicit GUID of the selected record or a list of GUIDs. An empty request no longer starts an export of all data, including sensitive Resource credentials.

Response handling when downloading Files and Process Versions has been fixed. The binary stream is no longer treated as JSON, so a valid download no longer fails OpenAPI validation.

When creating a File, the server uses the canonical Object Folder GUID from the database. A different letter case in the request path no longer causes the content to be saved in the wrong directory.

Writing Logs through API v1 has been fixed. Additional fields and a PNG screenshot in Base64 with type and size validation are supported. The binary contents of the screenshot are not stored in Audit changes.

The parameter string and request body are no longer written to the web server access log. This reduces the risk of tokens, passwords, and other sensitive data ending up in service files.

17. Built-in document viewer#

The built-in document viewer once again opens files in the Sherpa Orchestrator client package. The server returns viewer modules with the correct content type, so the browser no longer blocks them from loading.

No new buttons or screens have been added. The user still opens a document in the usual way, but viewing now works without additional browser or server configuration.