- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Exportieren von Rastern im Hintergrund
- Durchsetzung der Governance der Integration Service-Verbindung auf Benutzerebene
- Mandant
- Über den Kontext „Mandant“
- Suche nach Ressourcen in einem Mandanten
- Verwaltung von Robotern
- Verbindung von Robotern mit Orchestrator
- Speicherung von Roboterzugangsdaten in CyberArk
- Speichern der Kennwörter von Unattended-Robotern im Azure Key Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im HashiCorp Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im AWS Secrets Manager (schreibgeschützt)
- Löschen von getrennten und nicht reagierenden Unattended-Sitzungen
- Roboter-Authentifizierung
- Roboter-Authentifizierung mit Client-Anmeldeinformationen
- Konfigurieren von Automatisierungsfunktionen
- Computer verwalten
- Agents and Functions on Local Robots
- Zuweisen von Maschinenobjekten zu Ordnern
- Konfigurieren Sie Konto-Maschine-Zuordnungen.
- EDR-Schutzstatus
- Solutions (Lösungen)
- Audit
- Einstellungen
- Registrierung
- Cloud Robots
- Übersicht über Cloud Robots
- Ausführen von Unattended-Automatisierungen mit Cloud Robot – VM
- Hochladen Ihres eigenen Image
- Wiederverwenden von benutzerdefinierten Maschinen-Images (für manuelle Pools)
- Zurücksetzen der Anmeldeinformationen für eine Maschine (für manuelle Pools)
- Überwachung
- Sicherheitsupdates
- Testversion anfordern
- Häufig gestellte Fragen
- Konfigurieren einer VPN für Cloud-Roboter
- Konfigurieren einer ExpressRoute-Verbindung
- Live-Streaming und Remotesteuerung
- Events
- Anzeigen und Zugreifen auf Benachrichtigungen
- Anzeigen und Zugreifen auf E-Mail-Benachrichtigungen
- Es werden nur ungelesene Benachrichtigungen angezeigt
- Alle Benachrichtigungen als gelesen markieren
- Alle Benachrichtigungen löschen
- Löschen von Benachrichtigungen
- Abonnieren von Ereignissen
- Abbestellen von Ereignissen
- Automation Suite-Roboter
- Ordnerkontext
- Prozesse
- Jobs
- Apps
- Auslöser
- Protokolle
- Überwachung
- Indizes
- Warteschlangen
- Assets
- Über Assets
- Verwalten von Assets in Orchestrator
- Verwalten von Assets in Studio
- Speichern von Assets im Azure Key Vault (schreibgeschützt)
- Speichern von Assets im HashiCorp Vault (schreibgeschützt)
- Speichern von Assets im AWS Secrets Manager (schreibgeschützt)
- Speichern von Assets in Google Secret Manager (schreibgeschützt)
- Verbindungen
- Geschäftsregeln
- Speicher-Buckets
- MCP-Server
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Agents on local robots: run Agent, Function, and API jobs on your own unattended robots using the Local runtime type, instead of only Cloud - Serverless.
Agents on local robots lets you execute Agent, Function, and API process types on unattended robots that you host yourself, instead of only on UiPath-hosted Cloud - Serverless robots. Low-code agents and coded agents run through the same underlying execution runtime, referred to as Unified Runtime, whether they execute on a local robot or on Cloud - Serverless.
Local runtime type
When you start a job for an Agent, Function, or API process, the Runtime type drop-down on the Start Job page includes Local alongside Cloud - Serverless. Selecting Local runs the job on one of your own connected unattended robots instead of a UiPath-hosted machine.
Each process type draws from a specific capacity pool on the Local runtime:
| Prozesstyp | Runs on Local runtime using |
|---|---|
| Agent (low-code or coded) | Agent capacity |
| Function | Function capacity |
| API | Function capacity |
Unlike Production (Unattended) or Testing runtimes, which map one runtime to one concurrent job regardless of process type, the Local runtime type covers multiple process types through separate capacity pools on the same machine template.
Configuring Agent and Function runtimes
Machine templates include an Agents and Functions runtimes section, separate from the existing RPA runtime configuration. It has two fields:
- Agent slots: the number of Agent jobs that can run in parallel on each connected host machine using this template.
- Function slots: the number of Function and API jobs that can run in parallel on each connected host machine using this template.
Agents and functions consume units and don't require additional licenses. If no units are available for your tenant, executions don't start even when slots are configured.
Unlike RPA runtime licenses, Agent slots and Function slots are not capped by a per-type license allowance. They reserve concurrent execution capacity directly on the host machine, independent of tenant licensing. You configure them from the same Machine template window used for RPA runtimes. For steps, see Adding a Machine Template.
How Orchestrator routes jobs to local robots
Connected robots report which process types and runtimes they support. Orchestrator only dispatches a job to a robot that supports the job's process type and runtime.
If no connected robot currently supports the required process type, the job stays in a Pending state until a capable robot connects, rather than failing to start. This differs from RPA runtime types, which prevent you from starting a job when no matching runtime is available.
Lizenzierung und Verbrauch
Running Agent and Function jobs on local robots is consumption-based, similar to Cloud - Serverless licensing. Unlike Cloud - Serverless, consumption doesn't factor in machine size, since the machine belongs to you rather than to UiPath.