- Démarrage
- Meilleures pratiques
- Modélisation de l'organisation dans Orchestrator
- Meilleures pratiques d'automatisation
- Optimisation de l'infrastructure Unattended à l'aide de modèles de machine
- Organisation des ressources avec des balises
- Exportation des grilles dans l'arrière-plan
- Appliquer la gouvernance de la connexion Integration Service au niveau de l'utilisateur
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe de l’Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d’identification de l’Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Configurer les capacités d’automatisation
- Gestion des machines
- Agents and Functions on Local Robots
- Affectation d'objets machine à des dossiers
- Configuration des mappages compte-machine.
- Statut de protection EDR
- Solutions
- Audit
- Paramètres
- Registre
- Cloud Robots
- Vue d'ensemble des robots Cloud
- Exécution d'automatisations Unattended à l'aide de Cloud Robots - VM
- Téléchargement de votre propre image
- Réutilisation des images de machines personnalisées (pour les pools manuels)
- Réinitialisation des informations d'identification d'une machine (pour les pools manuels)
- Surveillance
- Mises à jour de sécurité
- Demander un essai
- Questions fréquemment posées
- Configuration du VPN pour les robots du cloud
- Configurer une connexion ExpressRoute
- Diffusion en direct et contrôle à distance
- Robots Automation Suite
- Contexte des dossiers
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Index
- Files d'attente (Queues)
- Actifs
- À propos des actifs
- Gestion des actifs dans Orchestrator
- Gestion des actifs dans Studio
- Stockage des ressources dans Azure Key Vault (lecture seule)
- Stockage des ressources dans HashiCorp Vault (lecture seule)
- Stockage des ressources dans AWS Secrets Manager (lecture seule)
- Stocker des ressources dans Google Secret Manager (lecture seule)
- Connexions
- Règles métier
- Compartiments de stockage
- Serveurs MCP
- Tests d'Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes
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:
| Types de processus | 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.
Licences et consommation
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.